Re: Free Fromat Standards

[Hans Boldt <boldt@xxxxxxxxxx>]

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