Skip to main content
Jump to: navigation, search

PTP/policy/developer guidelines

< PTP‎ | policy
Revision as of 20:22, 19 May 2010 by (Talk | contribs) (Additional requirements for Java source)

PTP adheres to the Eclipse Foundation development conventions and guidelines. Please make sure you read through these before committing code (if you're a committer) or submitting code contributions (if not).

The following practices should also be observed:

Additional requirements for Java source

  • Use interfaces as much as possible
  • All interfaces and methods must include a Javadoc comment
  • Interface implementations must include a non-Javadoc comment (using Generate Element Comment)
  • All classes, methods and fields should have an access modifier (public, protected, private)
  • Use the following class, method and field modifier order:
    1. Access modifier
    2. abstract
    3. static
    4. final
    5. transient
    6. volatile
  • All source should be formatted using the "Eclipse" built-in code formatter
  • All members should be sorted

Additional requirements for C source

  • All functions must be commented
  • Only include header files that are explicitly used
  • Always initialize variables before use (including static)
  • Always test explicitly for NULL
  • Always use NULL for pointers, not 0
  • Always test for an explicit value from strcmp

C source formatting guidelines:

  • Function body '{' and '}' on their own line
  • Function type on its own line (including static qualifier)
  • Function arguments separated by one space
  • Functions local to a file should be declared static
  • One variable declaration per line
  • Variable declarations should be followed by a blank line
  • No spaces before or after '(' and ')' in functions
  • Opening brace on same line as last ')' in an if statement expression
  • Space separating 'if' and '('
  • No spaces after '(' or before ')' in if statements
  • No braces around return values
  • Opening brace on same line as 'else'
  • 'else' on same line as '}'
  • Only use '/*' and '*/' for comments
  • Put '/*' and '*/' on their own line for multiline comments
  • Start each line of a multiline comment with an '*' aligned with the '*' in the '/*'

Naming conventions for global objects:

  • Capitalize the first letter of each word (e.g.MIBreakpointGetBreakInsertInfo)
  • Do not use '_' or '-'
  • Use descriptive names

Naming conventions for local/utility objects:

  • All lowercase
  • Separate words with '_'
  • Do not use '-'

Back to the top