Changes between Version 31 and Version 32 of Developer/Coding/Conventions


Ignore:
Timestamp:
May 30, 2014, 12:21:07 AM (5 years ago)
Author:
Gedare
Comment:

/* Formatting */ new section to consolidate some rules.

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Coding/Conventions

    v31 v32  
    1212 *  Use English and strive for good grammar, spelling, and punctuation.
    1313 *  Use TODO: with a comment to indicate code that needs improvement. Make it clear what there is to do.
    14  *  Use XXX to indicate an error, bug, or other problem that should be fixed.
     14 *  Use XXX or FIXME to indicate an error/bug/broken code.
    1515= Licenses =
    1616
     
    2525 *  Do not use compiler extensions.
    2626 *  Pay attention to warnings. Strive to eliminate them.
     27= Formatting =
     28
     29 *  Use spaces instead of tabs.
     30 *  Use two spaces for indentation, four spaces for hanging indentation.
     31 *  Adhere to a limit of 80 characters per line.
     32 *  Check all return statuses.
     33 *  Do not mix variable declarations and code.
     34 *  Avoid deep nesting by using early returns
     35  *  Parameter checking should be done first with early error returns.
     36  *  Avoid allocation and critical sections until error checking is done.
     37  *  For error checks that require locking, do the checks early after acquiring locks.
     38  *  Use of 'goto' requires good reason and justification.
     39 *  Test and action should stay close together.
     40 *  Avoid complex logical expressions in ifs, fors, and whiles
     41 *  Avoid inlining methods with complicated logic and decision points
     42 *  Use debug assertions.
     43
    2744= Miscellaneous =
    2845
     
    3653
    3754This section applies primarily to code residing under cpukit, especially cpukit/score.
    38 = Whitespace, alignment, indentation, and line length =
    3955
    40 
    41  *  Use spaces instead of tabs.
    42  *  Use two spaces for indentation, four spaces for hanging indentation.
    43  *  Adhere to a limit of 80 characters per line.
    44  *  Check all return statuses.
    45  *  Do not mix variable declarations and code.
    46 
    47 When in doubt, use the source code in ''cpukit/rtems'' as a style reference.
    48 = Readability =
    49 
    50  *  Avoid deep nesting by using early returns
    51   *  Parameter checking should be done first with early error returns.
    52   *  Avoid allocation and critical sections until error checking is done.
    53   *  For error checks that require locking, do the checks early after acquiring locks.
    54   *  Use of 'goto' requires good reason and justification.
    55  *  Test and action should stay close together.
    56  *  Avoid complex logical expressions in ifs, fors, and whiles
    57  *  Avoid inlining methods with complicated logic and decision points
    58  *  Use debug assertions.
    5956= Naming =
    6057