Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
RTP/coding-conventions
< RTP
Revision as of 17:35, 9 February 2011 by Unnamed Poltroon (Talk) (New page: '''Coding Conventions''' This document describes the basic Coding Conventions used by the RTP development team. '''Note''': These conventions affect only newly created code. Follow the...)
Coding Conventions
This document describes the basic Coding Conventions used by the RTP development team.
Note: These conventions affect only newly created code.
Follow the Sun conventions for the Java language: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html (Note that this includes braces around if, while and for constructs even if their 'then'-clause or body has only one line; see section 7.4 of the conventions.) Apart from that, the following rules are mandatory:
General rules for text files
- Text files must use Unix line delimiters (\n)
- If files contain non-ASCII characters, they have to be UTF-8 encoded
- TAB characters are forbidden
- 100 characters per line is maximum
Java code
- Method parameters (with the exception of abstract methods) are never assigned to.
- Initialize fields in the constructor, not in the declaration statement.
- In general, do one thing in one line (e.g. don't write
int a, b;
) - There must be at most one return statement in each method
- Do not use continue, break or return statements in loops
- Use for loops if there is a known number of iterations in the loop, else use while loops (i.e.: don't use for loops with a list iterator)
- Do not use variable names with only one letter (except loop variables in loops)
- Insert a space after opening braces and before closing braces(i.e.:
if( someMethod( arg1, arg2 ) == array [ i ] ) { ...
) - If lines are broken at an operator, the operator must be on the next line, and the next line is indented once. (No naked operators at the end of a line)
- All public API must be marked with a
@since
tag at the class/interface level. Only methods, fields etc. that are added in a later release cycle must carry their own@since
tag. The version number denotes the *release* version in which the element was/will be published the first time.
Formatter and Code Template Settings
TBD