Changes between Version 24 and Version 25 of DeveloperGuidelines/CodeConventions


Ignore:
Timestamp:
08/04/11 09:50:24 (10 years ago)
Author:
Fran Boon
Comment:

Add JS

Legend:

Unmodified
Added
Removed
Modified
  • DeveloperGuidelines/CodeConventions

    v24 v25  
    66NOTE: These coding conventions are mandatory for code to be accepted for the [wiki:ucore Stable] series!
    77
    8 == Code Style ==
     8== Python ==
     9=== Code Style ===
    910
    1011 * http://code.google.com/p/soc/wiki/PythonStyleGuide
     
    1213 * Use " " for strings, UNLESS the string contains a ", in which case use '
    1314
    14 === PEP8 Script ===
     15==== PEP8 Script ====
    1516Use static/scripts/tools/pep8.py to check for PEP8 compliance.
    1617
     
    2021}}}
    2122
    22 == Naming conventions ==
     23=== Naming conventions ===
    2324
    2425 * All functions outside of classes should have the prefix shn_<Model Name>_
     
    2627 * 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 }}}
    2728
    28 == Comments and Docstrings ==
     29=== Comments and Docstrings ===
    2930
    3031 * All files, classes and functions should have docstrings which allow to auto-generate API documentation using [http://epydoc.sourceforge.net epydoc]
     
    3738}}}
    3839
    39 == Internationalisation ==
     40=== Internationalisation ===
    4041
    4142 * All user-visible strings should be Internationalised: {{{T("My string")}}}
     
    4445 * DeveloperGuidelinesInternationalisation
    4546
    46 == Tools ==
     47=== Tools ===
    4748
    4849 * Some automated bug analysis / code quality checking tools -
     
    5455
    5556
    56 == Exceptions ==
     57=== Exceptions ===
    5758
    5859* 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.
     
    115116 
    116117
    117 == Nulls ==
     118=== Nulls ===
    118119Nulls 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.
    119120
     
    124125* 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.
    125126
     127== !JavaScript ==
     128
     129 * http://javascript.crockford.com/code.html
     130
    126131----
    127132DeveloperGuidelines