Changes between Version 10 and Version 11 of CodingConventions


Ignore:
Timestamp:
May 27, 2010, 7:24:02 PM (14 years ago)
Author:
Gavin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • CodingConventions

    v10 v11  
    55'''Files'''
    66
    7  * Although Grails can handle both dos (\r\n) and *nix (\r) line ends *nix is preferred.
     7 * Although Grails can handle both dos (\r\n) and *nix (\n) line ends only (\n) should be used, please configure your IDE or editor.
    88 * It is project policy not to include developer's names in the source files, recognition will be given in better and more visible ways.
    99
    1010'''Format'''
    1111
    12  * Please set-up your IDE or editor to use a indent of 4 spaces, with no tabs.
    13  * Follow the generally used formatting of code you see in Grails and the project.
     12 * Please configure your IDE or editor to use an indent of 4 spaces, with no tabs.
     13 * Follow the generally used formatting of code you see in Grails and this project.
    1414
    1515'''Grails'''
    … …  
    2222  * Then detail to your hearts content.
    2323
    24 This way the original views are available as direct access to the data for administration. If the domain changes enough a "grails generate-all" can be performed on most domains without losing the customisations.
     24This way the original views are available as direct access to the data for administration. If the domain changes a "grails generate-all" can be performed on most domains without losing the customisations.
    2525
    26 Proposed suffix 'Detailed as in detailing a car, customised or air-brushed, unless a better suffix is suggested.
     26The 'Detailed suffix was chosen as in detailing a car, customised or air-brushed.
    2727
    2828A notable exception to this is '''Person''' and '''Authority''' use 'svn revert' if you accidentally regenerate these.
    … …  
    3030'''Documentation'''
    3131
    32 The documentation is along side the source for good reason they need to be kept in sync. Document and code simultaneously. If you code a feature, document it as you go or better still design the feature by using the documentation then code and document as you go. This way the two are really not that different. Use self documenting code, don't abbreviate: ''!LinIntDist'' could mean a lot of things ''!LinthianInternalDistortion'' is a lot more clear.
     32Use self documenting code:
     33 * A few extra lines of clear, commented and readable code has more value than 100 lines of API documentation explaining why the code is so complicated.
     34 * Coders are better off reading code and no-one else reads API documentation.
     35 * Don't abbreviate: ''!LinIntDist'' could mean a wide range of things, ''!LinthianInternalDistortion'' is a lot more clear and probably would not have been your first guess.
     36
     37The documentation is along side the source for good reason they need to be kept in sync. Document and code simultaneously. If you code a feature, document it as you go or better still design the feature by using the documentation then code and document as you go. This way the two are really not that different.