Skip to main content

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.

Jump to: navigation, search

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

< PTP‎ | policy
(New page: PTP adheres to the [http://wiki.eclipse.org/Development_Conventions_and_Guidelines Eclipse Foundation development conventions and guidelines]. Please make sure you read through these befor...)
 
Line 19: Line 19:
 
* Always use NULL for pointers, not 0
 
* Always use NULL for pointers, not 0
 
* Always test for an explicit value from strcmp
 
* Always test for an explicit value from strcmp
 +
 +
C source formatting guidelines:
 +
 +
* Function body '{' and '}' on their own line
 +
* Function type on it's 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 '-'

Revision as of 13:29, 30 October 2007

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:

  • All interfaces and methods must include a Javadoc comment
  • Interface implementations must include a non-Javadoc comment

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 it's 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