Coding Standards

This is of course, work in progress: if you see an error here, or would like to add something, please email us at dmsd-support@jet.efda.org

General IDL code

• Use forward_function to declare functions used by the current module to prevent compilation order problems
• use [ ] to reference array elements and subarrays instead of ()
• I recommend 1-tab indents for nesting - this works OK with IDLDE, but may require reconfiguring of other editors
• keep comments on the left hand side or inline
• IDL tests every condition in an if-clause, so take care that all of your if statements in a line can be tested at runtime. E.g., if obj_valid(oA) and (obj_class(oA) eq 'OPTIONS') will crash if oA is not a valid object
• use 'if/then/else' statements to test for and handle frequently occurring conditions.
  only use 'message' (i.e., throw an exception) for exceptional conditions
  e.g., with file I/O:
  - end of file on read is an expected condition that should be handled in the main function body.
  - being unable to write to an open file is an exceptional condition that you should use message for
  
• use !error_state structure members - !err_string is now deprecated
• When tested alone by an IF statement, an integer or byte will be treated as FALSE if it is even and TRUE if odd.
• Don't use global variables.

Specific to JETDSP

• Use the template code (see here) where it is appropriate
• Use functions rather than procedures, with a return value of 1B (success) or 0B (failure). Pass any extra variables, both input and output, using keywords and arguments.
• Variable naming. Use the following if appropriate
  • begin object reference variable names with lower case o, e.g., oOptions
  • begin pointer variable names with lower case p, e.g., pData