Difference between revisions of "PTP/policy/developer guidelines"

From Eclipsepedia

< PTP‎ | policy
Jump to: navigation, search
Line 6: Line 6:
 
* All plugins must include an [http://www.eclipse.org/legal/epl/about.php about.html file]
 
* All plugins must include an [http://www.eclipse.org/legal/epl/about.php about.html file]
  
Additional requirements for Java source:
+
== Additional requirements for Java source ==
  
 +
* Use interfaces as much as possible
 
* All interfaces and methods must include a Javadoc comment
 
* All interfaces and methods must include a Javadoc comment
* Interface implementations must include a non-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
  
Additional requirements for C source:
+
Java source formatting guidelines:
 +
 
 +
* 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
 
* All functions must be commented

Revision as of 19:06, 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:

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

Java source formatting guidelines:

  • 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 '-'