Changes between Version 25 and Version 26 of DeveloperGuidelines/CodeConventions


Ignore:
Timestamp:
11/25/11 04:14:44 (13 years ago)
Author:
Michael Howden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeveloperGuidelines/CodeConventions

    v25 v26  
    99=== Code Style ===
    1010
    11  * http://code.google.com/p/soc/wiki/PythonStyleGuide
    12   * Limit line length to 80 characters
    13  * Use " " for strings, UNLESS the string contains a ", in which case use '
     11* http://code.google.com/p/soc/wiki/PythonStyleGuide
     12 * Limit line length to 80 characters
     13* Use " " for strings, UNLESS the string contains a ", in which case use '
     14* Global variables should be avoided - use response.s3 to store them.
    1415
    1516==== PEP8 Script ====
     
    2324=== Naming conventions ===
    2425
    25  * All functions outside of classes should have the prefix shn_<Model Name>_
    26  * All classes which over-ride existing classed should have the suffix "S3"
    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 }}}
     26* Function names for the global namespace should start with an "s3_" prefix (if they are not module-specific) or with the module prefix plus underscore.
     27* Names for Eden-specific methods in subclasses of web2py classes also start with "s3_".
     28* should have the suffix "S3"
     29* Names for Eden-specific subclasses of web2py classes and all classes which over-ride existing classes start with "S3",
     30* All other classes defined in Eden end with "S3" (e.g. AuthS3 vs. S3Resource).
     31* CamelCase is for class names only
     32* Constant names are all-uppercase and with underscores as word separator
     33* everything else (including table names and field names) should be all-lowercase with underscores as word separator
     34* 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 }}}
    2835
    2936=== Comments and Docstrings ===