PAMP:Development Rules and Guidelines
From OpenSource
If you intend to work on the PAMP components and contribute patches, please adhere to the following rules and guidelines.
Contents |
Rules
In Rome do as the Romans do
In each component of PAMP, follow the conventions of that component.
Rationale
The single most important issue when it comes to coding styles and coding conventions is consistency. You can pretty much pick any style you want and you're fine, as long as the style is applied consistently.
Thus, even if you are aware of the one true style, in the name of consistency, when editing existing components, stick to the used style.
79 Characters
No line must be longer than 79 characters.
Rationale
Even today you may occasionally want to view the code from a command-line prompt or even print it. If there are lines longer than 79 characters, the lines will wrap or be cut, which makes reading difficult. Furthermore, if the indentation forces you to exceed 79 characters, it is very likely that your code is in urgent need of some refactoring.
No Tabs
No tabs in source code. Configure your editor so that it always uses spaces.
Rationale
Nobody can ever agree exactly how many spaces a tab should be equal to, which means that depending on who views the code and using which editor the code looks different. Just use spaces.
No Authors in Files
No names regarding who has done what must be added to files. Each component has a component/symbian/CREDITS file for that purpose.
Rationale
Authorship implies ownership, which may make you reluctant to fix things that need fixing, or to refactor things that need refactoring. Furthermore, at which point are you eligible to add your name to the list of authors? When you have fixed a typo in a comment? When you have fixed a minor bug? When you have fixed a major bug? When you have refactored the whole thing so that there is no original line of code left? Should you in that case remove the name of the original author?
The CREDITS file handles the big picture, and the version control history the details.
No Warnings
There must be absolutely no compiler warnings for any new code.
Rationale
No rationale should be needed, but if there are lots of warnings that you ignore, you may miss a warning that should not ignore.
