Changes between Version 24 and Version 25 of DeveloperGuidelines/CodeConventions
- Timestamp:
- 08/04/11 09:50:24 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DeveloperGuidelines/CodeConventions
v24 v25 6 6 NOTE: These coding conventions are mandatory for code to be accepted for the [wiki:ucore Stable] series! 7 7 8 == Code Style == 8 == Python == 9 === Code Style === 9 10 10 11 * http://code.google.com/p/soc/wiki/PythonStyleGuide … … 12 13 * Use " " for strings, UNLESS the string contains a ", in which case use ' 13 14 14 === PEP8 Script===15 ==== PEP8 Script ==== 15 16 Use static/scripts/tools/pep8.py to check for PEP8 compliance. 16 17 … … 20 21 }}} 21 22 22 == Naming conventions==23 === Naming conventions === 23 24 24 25 * All functions outside of classes should have the prefix shn_<Model Name>_ … … 26 27 * Names should be obvious and explicit, but not overly verbose (i.e. as long as they need to be to not make people think). They shouldn't require someone to look in another file or solve a puzzle to figure out what they mean, but shouldn't take too long to write. Avoid inventing new acronyms. e.g. bad: {{{ shn_prm_lkp, method_that_allows_us_to_create_a_gis_layer }}}, good: {{{ shn_personnel_search, create_gis_layer }}} 27 28 28 == Comments and Docstrings==29 === Comments and Docstrings === 29 30 30 31 * All files, classes and functions should have docstrings which allow to auto-generate API documentation using [http://epydoc.sourceforge.net epydoc] … … 37 38 }}} 38 39 39 == Internationalisation==40 === Internationalisation === 40 41 41 42 * All user-visible strings should be Internationalised: {{{T("My string")}}} … … 44 45 * DeveloperGuidelinesInternationalisation 45 46 46 == Tools==47 === Tools === 47 48 48 49 * Some automated bug analysis / code quality checking tools - … … 54 55 55 56 56 == Exceptions==57 === Exceptions === 57 58 58 59 * Do not use naked excepts. Yes there are lots already in the code base. Do not make the situation worse. They are being gradually fixed. … … 115 116 116 117 117 == Nulls==118 === Nulls === 118 119 Nulls make code much more complicated by introducing special cases that require special null-checking logic in every client, making code harder to understand and maintain. They often and easily cause hard-to-diagnose errors. 119 120 … … 124 125 * Database fields should generally be non-nullable. If there is the chance of unknown data in certain fields, it indicates that the table may be too big, and those fields may need splitting out into separate tables. It may seem reasonable to allow unknown data, but it places the burden of null-checking on every client of the table. If any client doesn't don't do it (the default), then there is a risk of undefined behaviour. By making them non-nullable, we get a level of code validation from the database layer. 125 126 127 == !JavaScript == 128 129 * http://javascript.crockford.com/code.html 130 126 131 ---- 127 132 DeveloperGuidelines
