PTP/policy/developer guidelines

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:

• All source files must start with an approved license and copyright declaration
• All plugins must include an about.html file

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)
• Don't add @Override to abstract method implementations
• 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 '-'