More Books
C++ Gotchas: Avoiding Common Problems in Coding and Design
Main Page
Table of content
Copyright
Addison-Wesley Professional Computing Series
Preface
Acknowledgments
Chapter 1. Basics
Gotcha #1: Excessive Commenting
Gotcha #2: Magic Numbers
Gotcha #3: Global Variables
Gotcha #4: Failure to Distinguish Overloading from Default Initialization
Gotcha #5: Misunderstanding References
Gotcha #6: Misunderstanding Const
Gotcha #7: Ignorance of Base Language Subtleties
Gotcha #8: Failure to Distinguish Access and Visibility
Gotcha #9: Using Bad Language
Gotcha #10: Ignorance of Idiom
Gotcha #11: Unnecessary Cleverness
Gotcha #12: Adolescent Behavior
Chapter 2. Syntax
Gotcha #13: Array/Initializer Confusion
Gotcha #14: Evaluation Order Indecision
Gotcha #15: Precedence Problems
Gotcha #16: 'for' Statement Debacle
Gotcha #17: Maximal Munch Problems
Gotcha #18: Creative Declaration-Specifier Ordering
Gotcha #19: Function/Object Ambiguity
Gotcha #20: Migrating Type-Qualifiers
Gotcha #21: Self-Initialization
Gotcha #22: Static and Extern Types
Gotcha #23: Operator Function Lookup Anomaly
Gotcha #24: Operator '->' Subtleties
Chapter 3. The Preprocessor
Gotcha #25: '#define' Literals
Gotcha #26: '#define' Pseudofunctions
Gotcha #27: Overuse of '#if'
Gotcha #28: Side Effects in Assertions
Chapter 4. Conversions
Gotcha #29: Converting through 'void *'
Gotcha #30: Slicing
Gotcha #31: Misunderstanding Pointer-to-Const Conversion
Gotcha #32: Misunderstanding Pointer-to-Pointer-to-Const Conversion
Gotcha #33: Misunderstanding Pointer-to-Pointer-to-Base Conversion
Gotcha #34: Pointer-to-Multidimensional-Array Problems
Gotcha #35: Unchecked Downcasting
Gotcha #36: Misusing Conversion Operators
Gotcha #37: Unintended Constructor Conversion
Gotcha #38: Casting under Multiple Inheritance
Gotcha #39: Casting Incomplete Types
Gotcha #40: Old-Style Casts
Gotcha #41: Static Casts
Gotcha #42: Temporary Initialization of Formal Arguments
Gotcha #43: Temporary Lifetime
Gotcha #44: References and Temporaries
Gotcha #45: Ambiguity Failure of 'dynamic_cast'
Gotcha #46: Misunderstanding Contravariance
Chapter 5. Initialization
Gotcha #47: Assignment/Initialization Confusion
Gotcha #48: Improperly Scoped Variables
Gotcha #49: Failure to Appreciate C++'s Fixation on Copy Operations
Gotcha #50: Bitwise Copy of Class Objects
Gotcha #51: Confusing Initialization and Assignment in Constructors
Gotcha #52: Inconsistent Ordering of the Member Initialization List
Gotcha #53: Virtual Base Default Initialization
Gotcha #54: Copy Constructor Base Initialization
Gotcha #55: Runtime Static Initialization Order
Gotcha #56: Direct versus Copy Initialization
Gotcha #57: Direct Argument Initialization
Gotcha #58: Ignorance of the Return Value Optimizations
Gotcha #59: Initializing a Static Member in a Constructor
Chapter 6. Memory and Resource Management
Gotcha #60: Failure to Distinguish Scalar and Array Allocation
Gotcha #61: Checking for Allocation Failure
Gotcha #62: Replacing Global New and Delete
Gotcha #63: Confusing Scope and Activation of Member 'new' and 'delete'
Gotcha #64: Throwing String Literals
Gotcha #65: Improper Exception Mechanics
Gotcha #66: Abusing Local Addresses
Gotcha #67: Failure to Employ Resource Acquisition Is Initialization
Gotcha #68: Improper Use of 'auto_ptr'
Chapter 7. Polymorphism
Gotcha #69: Type Codes
Gotcha #70: Nonvirtual Base Class Destructor
Gotcha #71: Hiding Nonvirtual Functions
Gotcha #72: Making Template Methods Too Flexible
Gotcha #73: Overloading Virtual Functions
Gotcha #74: Virtual Functions with Default Argument Initializers
Gotcha #75: Calling Virtual Functions in Constructors and Destructors
Gotcha #76: Virtual Assignment
Gotcha #77: Failure to Distinguish among Overloading, Overriding, and Hiding
Gotcha #78: Failure to Grok Virtual Functions and Overriding
Gotcha #79: Dominance Issues
Chapter 8. Class Design
Gotcha #80: Get/Set Interfaces
Gotcha #81: Const and Reference Data Members
Gotcha #82: Not Understanding the Meaning of Const Member Functions
Gotcha #83: Failure to Distinguish Aggregation and Acquaintance
Gotcha #84: Improper Operator Overloading
Gotcha #85: Precedence and Overloading
Gotcha #86: Friend versus Member Operators
Gotcha #87: Problems with Increment and Decrement
Gotcha #88: Misunderstanding Templated Copy Operations
Chapter 9. Hierarchy Design
Gotcha #89: Arrays of Class Objects
Gotcha #90: Improper Container Substitutability
Gotcha #91: Failure to Understand Protected Access
Gotcha #92: Public Inheritance for Code Reuse
Gotcha #93: Concrete Public Base Classes
Gotcha #94: Failure to Employ Degenerate Hierarchies
Gotcha #95: Overuse of Inheritance
Gotcha #96: Type-Based Control Structures
Gotcha #97: Cosmic Hierarchies
Gotcha #98: Asking Personal Questions of an Object
Gotcha #99: Capability Queries
Bibliography

Gotcha #12: Adolescent Behavior

We programmers are good at dispensing advice but often have a hard time following it. We preach against global variables, poor variable names, magic numbers and the like, but often insert them into our own code. This phenomenon confounded me for many years, until I read a magazine article that described the same phenomenon in adolescents. It's apparently common for adolescents to criticize risky behavior in others but, through a "personal fantasy," come to believe that they themselves are immune from any negative effects of engaging in that same behavior. As a class, then, programmers seem to suffer from arrested emotional development.

I've worked on projects where some programmers not only refused to follow coding standards but threatened to quit if they were required to indent four spaces instead of two. I've been in situations where one clique refused to attend meetings if the other clique was attending. I've seen programmers deliberately write undocumented and impenetrable code so no one else could maintain it. I've seen otherwise capable programmers refuse to accept advice from an older/younger/too straight/excessively pierced coworker, and head for disaster as a result.

Emotionally adolescent or not, as professional programmers we all have a number of adult, or at least professional, responsibilities. (See also the Association for Computing Machinery's positions on these issues, in the ACM Code of Ethics and Professional Conduct and Software Engineering Code of Ethics and Professional Practice.)

First, we have a duty to our chosen profession to do quality work to the best standards of which we are capable.

Second, we have a duty to the society in which we live and the planet on which we live. Our chosen profession is equal parts science and practical service. If our work does not contribute to making the world a better place to live, it is a waste of our talent, time, and, ultimately, our lives.

Third, we have the duty to our community to share our expertise in ways that affect governmental policy. In our increasingly technological society, most important decisions are made by persons schooled in the law or in politics but who are technologically illiterate and innumerate. For example, for a time one of the states had a law decreeing that the value of p was 3. That's funny (though wheeled transport was bumpy until the law was repealed), but a lot of the uninformed policy decisions we see are not. We have a duty to inform political debate with rational technical and numerate interpretation of policy.

Fourth, we have a duty to our colleagues to be collegial. This involves following local coding and design standards (if they're no good, we should change them, not ignore them), writing code that can be maintained, and listening to others while sharing our own perspectives.

This is in no way an exhortation to pick up pom-poms and be a "team player" or to encourage the adoption of the prevailing corporate uniform or social outlook. Some of my most satisfying professional collaborations have been with oddly dressed loners with unusual political positions and unique personal habits. But each of these cherished colleagues respected both me and my ideas (to the extent of telling me off when I deserved it, and letting me know I was wrong when I was), and worked with me to accomplish what we had together agreed to accomplish.

Fifth, we have a duty to others in our profession to share our knowledge and experience.

Sixth, we have a duty to ourselves. Our work and our thoughts should satisfy us and speak to the reasons for which we entered this profession. If we're passionate about what we do, if what we do is an essential part of what we are, the duties above will not be a burden; they will be a joy.