Enough rope to shoot yourself in the foot: rules for C and C++ programming

Description

Contents Acknowledgments xiii Introduction xv Part 1 The Design Process 1 1 The essentials of programming: No surprises, minimize coupling, and maximize cohesion 3 2 Stamp out the demons of complexity (Part 1)3 2.1 Don’t solve problems that don’t exst 4 2.2 Solve the specific problem, not the general case 4 3 A user interface should not look like a computer program (the transparency principle) 5 4 Don’t confuse ease of learning with ease of usa 6 5 Productivity can be measured in the number of keystrokes 6 6 If you can’t say it in English, you can’t say itin C/C++ 7 6.1 Do the comments first 8 7 Read code 8 7.1 There’s no room for prima donnas in a contemporary programming shop 8 8 Decompose complex problems into smaller tasks 8 9 Use the whole language 9 Use the appropriate tool for the job 9 10 A problem must be thought through before it can be solved 9 11 Computer programming is a service industry 10 12 Involve users in the development process 10 13 The customer is always right 10 14 Small is Beautiful. (Big = slow) 11 Part 2 General Development Issues 13 15 Firstdonoharm 14 16 Edit your code 14 17 A program must be written at least twice 14 18 You cant measure productivity by volume 14 19 You can’t ogram in isolation 14 20 Goof off 15 21 Write code with maintenance in mind—the maintenance programmer is you 15 21.1 Efficiency is often a bugaboo 16 Part 3 Formatting and Documentation 17 22 Uncommented code has no value 18 23 Put the code and the documentation in the same place 18 24 Comments should be sentences 18 25 Run your code through a spelling checker 19 26 A comment shouldn’t restate the obvious 19 27 A comment should provide only information needed for maintenance 19 28 Comments should be in blocks 21 29 Comments should align vertically 21 30 Use neat columns as much as possible 22 31 Don’t put comments between the function name and the open brace 23 32 Mark the ends of long compound statements with something reasonable 24 33 Put only one statement per line 25 34 Put argument names in function prototypes 25 35 Use a “predicate” form to split up long expressions 25 36 A subroutine should fit on a screen 26 37 All code should be printable 26 38 Use lines of dashes for visual separation between subroutines 26 39 White space is one of the most effective comments 27 40 Use four-space indents 28 41 Indent statements associated with a flow-control statement 28 41.1 .Comments should be at the same indent level as the surrounding code 30 42 Align braces vertically at the outer level 30 43 Use braces when more than one line is present under a flow-control statement 31 Part 4 Names and Identifiers 33 44 Names should be common English words, descriptiie of what the function, argument, or variable does 34 44.1.Do not clutter names with gibberish 34 45 Macro names should beENrILY_cAPITALIzED 35 45.1 Do not capitalize members of anenum 35 45.2 Do not capitalize type names created with atypedef 36 46 Avoid the ANSI C name space 36 47 Avoid the Microsoft name space 36 48 Avoid unnecessary symbols 37 49 Symbolic constants for Boolean values are rarely necessary 37 Part 5 Rules for General Programming 41 50 Don’t confuse familianty with readability 42 51 Afunctionshoulddoonlyonething 43 52 Too many levels of abstraction or encapsulation are as bad as too few 44 53 A function should be called more than once, but 44 53.1 Code used more than once should be put into a function 45 54 A function should have only one exit point 45 54.1 Always put a return at the outer level 46 55 Avoid duplication of effort 47 56 Don’t corrupt the global name space 47 56.1 Avoid global symbols 47 56.2 Never require initiization of a global variable to call a function 48 56.2.1 Make locals static in recursive functions if the value doesn’t span a recursive call 49 56.3 Use instance counts in place of initialization functions 50 56.4 If an if ends in return, don’t use else 51 57 Put the shortest clause of an if/else on top 52 58 Try to move errors from run time to compile time 53 59 Use C function pointers as selectors 54 60 Avoiddo/while loops 55 60.1 Never use a do/while for a forever loop 56 61 Counting loops should count down if possible 56 62 Don’t do the same thing in two ways at the same time 56 63 Use for if any two of an initialization, test, or increment are present 57 64 If it doesn’t appear in the test, it shouldn’t appear in the other parts otor statement 58 65 Assume that things will go wrong 59 66 Computers do not know mathematics 59 66.1 Expect the impossible 60 66.2 Always check error-return codes 60 67 Avoid explicit temporary variables 61 68 No magic numbers 61 69 Make no assumptions about sizes 61 70 Beware of casts (C issues) 63 71 Handle special cases directly 64 72 Don’t try to make lint happy 66 73 Put memory allocation and deallocation code in the same place 66 74 Heap memory is expensive 67 75 Test routines should not be interactive 69 76 An error message should tell the user what’s right 69 77 Don’t print error messages if an error is recoverable 70 78 Don’t use system-dependent functions for error messages 70 Part6 The Preprocessor 73 79 Everything in a .h file should be used in at least two.c files 74 80 Use nested #includes 74 81 You should always be able to replace a macro with a function 74 81.1?: isnotthesameasif/else 79 81.2 Parenthesize macro bodies and arguments 79 82 enum and const are better than a macro 80 83 A parameterized-macro argument should not appear more than once on the right-hand side 81 83.1 Never use macros for character constants 81 84 When all else fails, use the preprocessor 82 Part 7 C-Related Rules 85 85 Stamp out the demons of complexity (Part 2) 86 85.1 Eliminate clutter 86 85.2 Avoid bitwise masks; use bit fields 86 85.3 Don’t use done flags 88 85.4 Assume that your reader knows C 89 85.5 Don’t pretend that C supports a Boolean type #d.fin. TRUE) 89 86 1-bit bit fields should beunsign.d 90 87 Pointers must be above the base address of an array 90 88 Use pointers instead of array indexes 91 89 Avoid goto except... 92 Part 8 Rules for C++ Programming 95 Part B.A Design and Implementation Issues 96 90 Object-oriented and “structured designs dont mix 96 90.1 If its not object-oriented, use C 96 91 Expect to spend more time in design and less in development 97 92 C++ class libraries usually cant be used in a naive way 97 93 Use checkhsts 98 94 Messages should exercise capabilities, not request information 99 95 You usually cannot convert an existing structured program to object-oriented 100 96 A derived class object isa base-class object 101 97 Derivation is the process of adding member data and methoda 101 98 Design the objects first 103 99 Design the hierarchy next, from the bottom up 103 99.1 Base classes should have more than one derived class 103 100 The capabilities defined in the base class should be used byall derived classes 104 101 C++ is not Smalltalk—avoid a common obj ect class 104 102 Mix-ins shouldn’t derive from anything 108 103 Mix-ins should be virtual base classes 108 104 Initialize virtual base classes with the default constructor 108 105 Derivation is not appropriate if you never send a base-class message to a derived-class object 108 106 choose containment over derivation whenever possible 108 107 Use private base classes only when you must provide virtual overrides 108 108 Design the data structures last 109 109 All data in a class definition must beprivate 110 110 Never provide public access to private data 110 110.1 Donotusegetlsetfunctions 113 111 Give up on C idioms when coding in C++ 115 112 Design with derivation in mind 115 112.1 A member function should usually use theprivate data of a class 116 113 Use const 117 114 Use struct only if everythings public and there are no member functions 117 115 Dont put function bodies into class definitions 118 116 Avoid function overloads and default arguments 122 Part B.B Coupling Issues 124 117 Avoid friend dasses 124 118 Inheritance is a form of coupling 125 119 Don’t corrupt the global nane space: c++ issues 125 Part B.C References 128 120 Reference arguments should always beconst 128 121 Never use references as outputs, use pointers 128 122 Do not return references (or pointers) to local variables 130 123 Do not return references to memory that came fromnew 131 Part B.D Constructors, Destructors, and operator= () 133