c++-checklist

ears-0.32, linux下有用的语音信号处理工具包

From: [e-mail] (Peter Murray)
Newsgroups: comp.lang.c++.moderated
Subject: Evil C++ Techniques: A Listing
Date: 26 Mar 1996 09:16:21 -0000

I need feedback...

As part of a C++ style guide for my group I am putting together a 
list of things you can do in C++ but *really* shouldn't.  I would 
appreciate any comments, criticisms, additions to the list, 
additional references, etc...  

Where there is a reference(s) available I don't provide any detailed 
descriptions.  I leave it to the reader to to investigate the 
reasoning behind each point in the listed references (this is meant 
to be a relatively *short* guide).

Thanks,
- Peter

---------------------------------------------------------------------
Contents:
(a) Techniques to Avoid
(b) Outdated/Superseded Language Constructs
(c) References
---------------------------------------------------------------------

---------------------------------------------------------------------
(a) Techniques to Avoid
---------------------------------------------------------------------

1)   Never redefine an inherited nonvirtual function.  In derived 
     classes, only redefine the virtual functions of the base class.
  Exceptions: None
  Ref: [2] Item 37

2)   Never redefine default parameter values defined in virtual base
     class functions.
  Exceptions: None
  Ref: [2] Item 38
       [8] FAQ 144

3)   Never overload &&, ||, or ,(comma operator)
  Exceptions: None
  Ref: [3] Item 7

4)   Avoid the use of interface specifications.
  Exceptions: Rarely
  Ref: [4] p.76
       [10] Section 9.6, p.317

5)   Always define at least one constructor.
  Exceptions: None
  Ref: [4] p.11
       [3] Item 4

6)   Do not allow the compiler to generate a default destructor.  For
     each class, always define a destructor.
  Exceptions: None
  Ref: [4] p.11
       [8] FAQ 196

7)   Avoid using the compiler generated assignment operator. 

  Exceptions: If you don't dynamically allocate any data (e.g. via new) 
              on the heap you don't need to declare an assignment 
              operator.  If you want to use the compiler generated
              assignment operator insert a commented declaration to 
              show that this is your intention;
               // TObject& operator=(const TObject&);  // Use default.

  Ref: [4] p.11
       [8] FAQ 198
       [2] Item 11

8)   Avoid using the compiler generate copy constructor.  

  Exceptions: Same as for compiler generated assignment operator.  If 
              you don't dynamically allocate any memory you may be safe
              with the compiler generated version.  If you want to use 
              the compiler generated copy constructor insert a
              commented declaration to show that this is your 
              intention;
               // TObject(const TObject&) ;  // Use default.

  Ref: [4] p.11
       [8] FAQ 197

9)   Avoid member assignment within the constructor.  Use member 
     initialisation lists with constructors rather than assignment 
     inside the constructors.   Note that initialisation list members 
     should be listed in the same order as they are declared in the 
     class definition.

  Exceptions: When you have a large number of data members of built-in
              types, that are initialised the same way in each 
              constructor, in which case you would use a common 
              initialisation routine. 

  Ref: [2] Item 12
       [2] Item 13
       [8] FAQ 133
       [8] FAQ 188
       [8] FAQ 191

10)  Public member functions should not return references or pointers 
     to protected or private members.

  Exceptions: For performance reasons it is sometimes acceptable to
              return a reference or pointer to a const object.

  Ref: [2] Item 30
       [2] Item 21

11)  Data members must not be public.
  Exceptions: None
  Ref: [2] Item 20

12)  Never return a reference or pointer to a local object.
  Exceptions: None
  Ref: [2] Item 23
       [2] Item 31

13)  Do not ignore compiler warnings.
  Exceptions: Rarely
  Ref: [2] Item 48
     
14)  Never hide a public member function of a publicly derived base 
     class.
  Exceptions: None
  Ref: [8] FAQ 122

15)  Do not use Hungarian Notation. Due to the intellectual inertia 
     of C programmers moving to C++, it may pay to list some of the 
     problems with Hungarian Notation when applied to C++;
      - Ignores the use of abstract data types as base types.
      - Forces programmers to worry about manual type checking 
        instead of letting the C++ compiler check the types more 
        rapidly and accuratley.
      - Combines purpose with type.  If you change a variable's type 
        you should not have to change its name throughout the 
        program.  Variables can quickly become out-of-date when their 
        type changes but their name is not changed (through laziness 
        or mistakes or overlooked).
      - Encourages lazy, uninformative variable names.
      - With C++ there is no need to know the exact representation of 
        a variable in order to manipulate it.
      - No need in a strongly typed language such as C++.  Hungarian 
        Notation was designed for weakly typed languages such as C.
      - Does not mix well with polymorphism.

      For an alternative naming convention, see [4] p.33

  Exceptions: When programming at a low-level in a C-like manner (or 
              using embedded assembly code) and interfacing with 
              hardware that requires the programmer to know the exact 
              representation of a variable or data structure in order 
              to manipulate it.  Such code should probably reside in
              seperate C specific modules.

  Ref:  [5] p.206
        [4] p.33


---------------------------------------------------------------------
(b) Outdated/Superseded Language Constructs
---------------------------------------------------------------------

1)    #define values
      Alt:  const values.
      Ref:  [2], Item 1
            [8], FAQ 332

2)    #define macros
      Alt:  inline functions or templates.
      Ref:  [2] Item 1
            [2] Item 33
            [8] FAQ 349

3)    malloc
      Alt:  new
      Ref:  [2] Item 3
            [8] FAQ 301

      4)    free
      Alt:  delete
      Ref:  [2] Item 3

5)    stdio.h
      Alt:  iostream.h
      Ref:  [2] Item 2
            [8] FAQ 373

6)    printf
      Alt:  operator<<
      Ref:  [2] Item 2

7)    scanf
      Alt:  operator>>
      Ref:  [2] Item 2

8)    /* ... */  (C-style comments)
      Alt:  //   (C++ style comments)
      Ref:  [2] Item 4

10)   raw C pointers
      Alt:  STL auto_ptr
      Ref: 

11)   raw C char strings
      Alt:  STL string
      Ref: 

12)   raw C casts
      Alt:  static_cast
            const_cast
            dynamic_cast
            reinterpret_cast
      Ref:  [3] Item 2

13)   unspecified arguments e.g. printf (char*, ...)
      Alt:  default arguments or function overloading
      Ref:  [4] p.45

14)   Error return codes
      Alt:  exceptions 
            (I'm not sure about this.  Exceptions can be real buggers to
            work with.) 
            (How does exception handling affect size/performance?)
      Ref:  [8], FAQ 244

15)   Local variables declared at the top of a function.
      Alt:  Local variables declared near first usage.
      Ref:  [8] FAQ 424


---------------------------------------------------------------------
(c) References
---------------------------------------------------------------------
[1] Style and Syntax, Dan Saks, C/C++ Users Journal, Vol. 13, No. 10, 
    October 1995
[2] Effective C++, Scott Meyers, Addison-Wesley, 1992
[3] More Effective C++, Scott Meyers, Addison-Wesley, 1996
[4] Taligent's Guide to Designing Programs, Addison-Wesley, 1994
[5] Code Complete, Steve McConnell, Microsoft Press, 1993
[6] Debugging the Development Process, Steve Maguire, Microsoft 
    Press, 1994
[8] C++ FAQs, Cline/Lomow, Addison-Wesley, 1995
[9] C++ Programming Style, Tom Cargill, Addison-Wesley, 1992
[10] The C++ Programming Language, 2nd Edition, Bjarne Stroustrup, 
     Addison-Wesley, 1991



+-----------------------------------------------------------------------+
| Peter C. Murray  ([e-mail])                  |
|                                                                       |
| class Disclaimer : public StdDisclaimer { /* It was all my fault */ };|
|                                                                       |
| - Emergency Services Systems Development                              |
| - Information Technology Group,  Telecom (Telstra) Australia          |
+-----------------------------------------------------------------------+


      [ Articles to moderate: mailto:[e-mail] ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:[e-mail]       ]