Re: Free Fromat Standards -- RPG400-L

Joel Cochran wrote:

I agree with Scott that not that much changes.  Everything below except
for the spacing, could be applied to fixed as well as /free.

That being said, I based our style on our Java style, which I got here:
http://www.javaranch.com/style.jsp

Obviously not everything translates, but mixed case naming and
semi-colon placement are the same.  My documentation even resembles
JavaDoc.

Here are some other standards/guidelines we employ:
- Indent 2 spaces per level starting under the 'r' in /free.
- If you have to wrap a line of code more than once you are either
nested too far or the line is too complicated.
- All database files are prefixed.
- File field names are in ALLCAPS.
- Qualified datastructures are recommended but not required.
- Only use named indicators.
- No compile time tables/arrays, inz DS subfields instead.

Naturally this all applies to new code...

Joel
http://www.rpgnext.com

Just to add to the very good points already listed:

For structured statements, the ENDxx should be aligned with the corresponding IF, DOU, DOW, etc. The statements between are the ones indented. (My own preference is 3 spaces.) For example:

      if found;
         limit = previous - 4;
         for i = 1 to limit;
            process_item (i);
         endfor;
      endif;

For continued statements, the continuation should also be indented some additional amount, and each continued line should be indented the same amount. Unlike Joel, I don't see any problem with continuing for more than two lines. Indeed, if a procedure has several parameters, and each can be an expression, it may make sense to code each parameter on a separate line.

For compound logical expressions, my preference is to code each sub-condition on a separate line with the logical operator at the beginning of the new line. And to contradict my previous rule on continued statements, I prefer *not* indenting in this case. For example:

      if  found
      and item_found <> 'junk'
      and item_found <> 'garbage';
          // Process valid item
          process_item
                (item_found:
                 search_code:
                 library_name + '/' + file_name);
      endif;

Getting further into a coding standard, you get into things that are more personal preference. But you might want to consider the following:

- Whitespace around operators and punctuation. For example, some programmers prefer one space before '(' and one space after ')' and ':'. Many prefer a space before and after most operators. Or at least, consistency - that is, if you have a space before an operator, also code one after. Thus, either "a+1" or "a + 1" are acceptable, but not "a +1".

- How are block comments handled? Do you have a standard prolog for modules, /copy members, procedures, and subroutines?

- Where do you code blank lines? And how many blank lines between major things like procedures? And how many around block comments and between smaller blocks of code?

- Do you want an end-of-line comment on each ENDxx opcode to document the condition on the corresponding opcode? Personally, I'm not a fan of that style since it already suggests that the block is perhaps too big already, but some people like doing that.

- Do you set a maximum limit on nesting of structured blocks?

- Do you prefix global variables with a specific prefix, like "G_"?

- One common convention in many languages is to name constants in all caps.

Cheers! Hans