Copying & Pasting these conventions
Copies of these standards can be found within the Standards.fp7 file on this wiki.
- C style comments (/* */) and standard C++ comments (//) are both fine, though the former is discouraged within functions (even for multiple lines, repeat the // single-line comment).
Single comment steps within scripts
Use one or more spaces before any text is added to a script comment step. This increases the readability of the step by creating a white space margin while reviewing scripts.
Reading what a script does, what it affects, and how the script has changed is critical to understanding where it fits into the solution. The following guidelines can be used for commenting your scripts.
The Revision field within the comment is one single script step which contains the latest change date and a date or date/timestamp line for each change documented. Within the comment step it looks like the following.
The utility of the history field is being able to use the return key to open the comment dialog for review and close the dialog easily using the escape key.
Shortcuts for inserting date/time values
Using a string expansion program for inserting dates and times into your comments is very helpful. For example, typing dts can be expanded to the current Date time short equivalent. Find a list of these tools in Keyword expansion tools in Developer Tools
Custom function commenting
Custom functions should use, at minimum, the following header. Because the header of a custom function is multiple lines of text within the calculation dialog box, you can use spaces for indenting, instead of the proposed tabs. This makes the calculation header easier to read. Tip: many editors have a convert spaces to tabs and inverse functionality.
Wrapping lines within the header comment
Using an external editor will make it easier to wrap individual lines to a fixed length.
Commenting conventions to borrow from
The above standards are adapted from the following sources