Changes between Version 1 and Version 2 of TCTCodingStandardsChangesAddons


Ignore:
Timestamp:
02/03/2010 06:31:42 PM (9 years ago)
Author:
robyn
Comment:

Update based on TCT 3 Feb 10 meeting

Legend:

Unmodified
Added
Removed
Modified
  • TCTCodingStandardsChangesAddons

    v1 v2  
    77 * [wiki:C++Standard C++ Coding Standards] - statement of LSST DM C++ Coding Standards. 
    88 
    9 === Yet Another New Rule 1 (Unused exception classes must be unnamed) === 
    10 Unused exception classes must be unnamed. 
    11   
     9=== Yet Another New Rule 1 (Unused exception variables must be unnamed) === 
     10Unused exception variables must be unnamed. 
     11{{{  
    1212    try { 
    1313    } catch (ExceptionClass &) {      // OK 
    1414    }; 
    15   
    16 C++ allows omission of the variable name; best practice and the desire to minimize compiler warnings suggest that we should do so. 
     15}}}  
     16Although C++ allows omission of the variable name, some compilers generate warnings if a named variable is not accessed. This Rule will reduce unnecessary compiler warnings. 
    1717 
    1818 
     
    4141---- 
    4242 
    43 === Yet Another New Rule 2 (Unused method and fuction arguments must be unnamed) === 
     43=== Yet Another New Rule 2 (Unused method and function arguments must be unnamed) === 
    4444 
    4545Unused method and function arguments must be unnamed. 
    46   
     46{{{  
    4747    void MyDerivedClass::foo( double /* scalefactor */ ) { // OK 
    4848    }; 
     
    5050    void MyDerivedClass::foo( double ) { // OK 
    5151    }; 
    52   
     52}}} 
    5353This is common in template specializations and derived methods, where a variable is needed for some cases but not all. In order to remind the  developer of the significance of the missing parameter, an in-line C comment may be used. 
     54 
     55Although C++ allows omission of an unused argument's name, some compilers generate warnings if a named argument is not accessed. This Rule will reduce unnecessary compiler warnings. 
    5456 
    5557 
     
    8082=== Yet Another New Rule 3 (A class or struct definition must explicitly declare the privacy qualifier of its base classes) === 
    8183A class or struct definition must explicitly declare the privacy qualifier of its base classes. 
    82   
     84{{{  
    8385   struct derived : public base {}; 
    8486   class d : private b {}; 
     87}}} 
    8588  
    86 Although C++ provides the above definitions as defaults, best practises and the desire to minimize compiler warnings require developers to be specific 
     89Although C++ provides the above definitions as defaults, some compilers generate warnings if explicit privacy qualifiers are not specified. This Rule will reduce unnecessary compiler warnings. 
    8790 
    8891 
     
    119122 
    120123==== REQUIRED ==== 
    121  * '''REQUIRED''' means that the Rule is an absolute requirement of the specification. The developer needs to petition the DM TCT to acquire explicit approval to contravene the Rule. 
     124 * '''REQUIRED''' means that the Rule is an absolute requirement of the specification. The developer needs to petition the DM TCT to acquire explicit approval to contravene the Rule.  
     125 * '''PROHIBITED''' is the opposite of '''REQUIRED'''. 
    122126 
    123127==== MUST or SHALL ==== 
    124  * '''MUST''' or  '''SHALL'''  mean that there may exist valid reasons in particular circumstances to ignore a particular Rule, but the full implications must be understood and carefully weighed before choosing a different course. The developer needs to petition the lead developer to acquire explicit approval to contravene the Rule. 
    125  * '''MUST NOT''' or  '''SHALL NOT''' mean that there may be valid reasons in particular circumstances when the particular behavior described by the Rule is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing that behavior.  The developer needs to petition the lead developer to acquire explicit approval to contravene the Rule. 
     128 * '''MUST''' and  '''SHALL'''  mean that there may exist valid reasons in particular circumstances to ignore a particular Rule, but the full implications must be understood and carefully weighed before choosing a different course. The developer needs to petition the lead developer to acquire explicit approval to contravene the Rule. 
     129 * '''MUST NOT''' and  '''SHALL NOT''' are their opposites. 
    126130 
    127131==== SHOULD or RECOMMENDED  or MAY ==== 
    128  * '''SHOULD''' or  '''RECOMMENDED''' or '''MAY'''  mean that there are valid reasons in particular circumstances to ignore a particular Rule. The developer is expected to personally consider the full implications  before choosing a different course. 
    129  * '''SHOULD NOT''' or  '''NOT RECOMMENDED''' or '''MAY NOT''' mean that there are valid reasons in particular circumstances when the particular behavior described by the Rule is acceptable or even useful. The developer is expected to personally consider the full implications before implementing that behavior. 
     132 * '''SHOULD''',  '''RECOMMENDED''' and '''MAY'''  mean that there are valid reasons in particular circumstances to ignore a particular Rule. The developer is expected to personally consider the full implications  before choosing a different course. 
     133 * '''SHOULD NOT''',  '''NOT RECOMMENDED''' and '''MAY NOT''' are their opposites. 
    130134