Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "PTP/policy/developer guidelines"
(→Additional requirements for Java source) |
|||
Line 20: | Line 20: | ||
*# transient | *# transient | ||
*# volatile | *# volatile | ||
− | |||
− | |||
− | |||
* All source should be formatted using the Eclipse built-in code formatter | * All source should be formatted using the Eclipse built-in code formatter | ||
* All members should be sorted | * All members should be sorted |
Revision as of 19:07, 16 April 2010
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:
- Access modifier
- abstract
- static
- final
- transient
- 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 '-'