Best Practices

[Kent Searight]

Comments galore: in field definitions, scripts, calcs.

Taking advantage of the commenting capabilities is, in my experience, the most often overlooked best practice out there. When is the last time anyone downloaded a demo file that accompanies a plug-in and encountered a field called something like "x_typeFinal" and you don't have a clue about what its purpose is? This happens all too often to me.

I've found that as much as I'm in a hurry to get the job done, it's always worthwhile to take the extra few seconds and comment on a field whose purpose is anything but blatantly obvious. This will save time and reduce errors in the long run. I've collaborated on projects with other developers that "don't have the time" to do this, and without fail I come out ahead of them in the long run when they can't remember later where, when or why a field gets its value from.

Just my

-Kent

[Fenton]

I just wish we had a similar "Relationship comments" box, in the little relationship dialog.

[LaRetta]

And I wish we had a way to place our cursor over a field in our graph, or scripts or import/export or anywhere ... and display the field comment on it. Field comments are great but only when you are IN your field definitions. They could be much more powerful if available elsewhere also. :smile2:

[Mandu]

I tend to think of "Best Practices" as being words of wisdom about common, small, specific issues that come up repeatedly, for which there are a variety of alternate solutions, with one solution being much preferable to the rest. In fact, some "best practices" I've read are frequently framed "Prefer to ."

For example,

When a script puts up a window and pauses execution, and the window has a button attached to a script and flagged "Resume", put as little as possible in the button script (e.g. set global variable to identify button that was pressed) and leave the remaining work to the main script.

Disclaimer - I'm not proposing that this particular example is anything other people grapple with, or even whether it's generally correct or not! It's just meant as an example of the size and scope of what I think of as something a "best practice" might address. I know that I'm not advanced enough to recommend best practices of this sort.

Others might be about making List layouts work properly.

Naming and commenting conventions don't strike me as the subject of best practices. But I don't know what the OP had in mind.

[Kent Searight]

I tend to think of "Best Practices" as being words of wisdom about common, small, specific issues that come up repeatedly, for which there are a variety of alternate solutions, with one solution being much preferable to the rest. In fact, some "best practices" I've read are frequently framed "Prefer to ."

That rightly sums up a part of what I consider best practices.

Naming and commenting conventions don't strike me as the subject of best practices...

The realm of best practices is hard to define, as evidenced by this Wikipedia article. My definition of a best practice is any routine that's employed that provides the most efficient way of achieving an end result. One of those end results I strive for in my solutions is the ability for me or another developer to spend the minimum amount of time required to perform any future development. Since naming conventions and commenting plays a significant role in achieving this, I include them in my realm of best practices. I'd even go so far as to say that my realm of best practices extends to the generalization "be consistent".