Code Complete 2nd Edition (Notes)

[puddlejumper26]

Normally, this book requires a lot of practical experiences. However,

Reference

[1] https://github.com/xianshenglu/document/blob/master/Code%20Complete%202nd%20Edition.pdf

Guideline

Chapter 1 || Chapter 2-Metaphors for a Richer Understanding of Software Development || Chapter 3-Measure Twice, Cut Once: Upstream Prerequisites || Chapter 4-Key Construction Decisions || Chapter 5-Design in Construction || Chapter 6-Working Classes || Chapter 7-High-Quality Routines || Chapter 8-Defensive Programming || Chapter 9-The Pseudocode Programming Process || Chapter 10-General Issues in Using Variables || ..... || Chapter 22-Developer Testing || Chapter 23-Debugging || Chapter 24-Refactoring || ..... ||

[puddlejumper26]

Chapter 1

[puddlejumper26]

Chapter 2 Metaphors for a Richer Understanding of Software Development

[puddlejumper26]

Chapter 3 Measure Twice, Cut Once: Upstream Prerequisites

[puddlejumper26]

Chapter 4 Key Construction Decisions

[puddlejumper26]

Chapter 5 Design in Construction

## 5.1 Design Challenges - A good top-level design provides a structure that can safely contain multiple lower-level designs. - useful on small projects and indispensable on large projects - making mistakes is the point of design—it’s cheaper to make mistakes and correct designs than it would be to make the same mistakes, recognize them after coding, and have to correct full-blown code - hard to know when your design is “good enough.” - - Tradeoffs and Priorities - Restrictions - partly to create possibilities and partly to restrict possibilities - Nondeterministic - there are usually dozens of ways to design a computer program - Heuristic Process - trial and error - Emergent- evolve and improve through design reviews, informal discussions, experience writing the code itself, and experience revising the code. ## 5.2 Key Design Concepts ### Managing complexity - Accidental and Essential Difficulties - essential ( things must have ), accidental ( things happen to have) ### Importance of Managing Complexity - focus on one part of it at a time - minimize the amount of a program at any time - dividing into subsystems - keeps routine short - Writing programs in terms of the problem domain ### How to Attack Complexity - ineffective designs (NO) - - Minimize the amount of essential complexity - Keep accidental complexity from needlessly proliferating ### Desirable Characteristics of a Design - Minimal complexity - Ease of maintenance - Loose coupling - Extensibility - Reusability - High fan-in - having a high number of classes that use a given class. a system has been designed to make good use of utility classes at the lower levels in the system - Low-to-medium fan-out - a class uses a large number of other classes and may therefore be overly complex - Portability - easily to move to other environment - Leanness - no extra parts - Stratification - keep the levels of decomposition stratified, view the system at any single level and get a consistent view - Standard techniques ### Levels of Design  - Level 2: Division into Subsystems or Packages ( subsystems can be big: database, user interface, business rules, command interpreter,report engine, and so on. how to partition the program into major subsystems and defining how each subsystem is allowed to use each other subsystem) - - Common Subsystems ( Business rules, User interface, Database access, System dependencies) - Level 3: Division into Classes ( Classes vs. Objects, An object is any specific entity that exists in your program at run time. A class is the static thing you look at in the program listing. An object is the dynamic thing with specific values and attributes you see when you run the program. Class Person, Object Mr X ) - Level 4: Division into Routines - at least needs to be done mentally. - Level 5: Internal Routine Design - detailed functionality of the individual routines ## 5.3 Design Building Blocks: Heuristics ### Find Real-World Objects ■ Identify the objects and their attributes (methods and data). - Computer programs are usually based on real-world entities ■ Determine what can be done to each object. ■ Determine what each object is allowed to do to other objects. ■ Determine the parts of each object that will be visible to other objects—which parts will be public and which will be private. ■ Define each object’s public interface. ### Form Consistent Abstractions ### Encapsulate Implementation Details - you can look at the outside of the house but you can’t get close enough to make out the door’s details ### Inherit—When Inheritance Simplifies the Design - works synergistically with the notion of abstraction ### Hide Secrets (Information Hiding) - black boxes - Secrets and the Right to Privacy (deciding which features should be known outside the class and which should remain secret. ) - Two Categories of Secrets (1. Hiding complexity so that your brain doesn’t have to deal with it unless you’re specifically concerned with it 2. Hiding sources of change so that when change occurs, the effects are localized) - Barriers to Information Hiding ( Excessive distribution of information, Circular dependencies, Class data mistaken for global data, Perceived performance penalties) - Value of Information Hiding (ability to inspire effective design solutions) ### Identify Areas Likely to Change - ability to anticipate change, Accommodating changes, (Identify, Separate and Isolate items that are likely to change) - Business rules - Hardware dependencies - Input and output - Nonstandard language features - Difficult design and construction areas - Status variables ( 1. don't use boolean, 2. use access routines rather than checking the variable directly) - Data-size constraints - Anticipating Different Degrees of Change (identify the minimal subset of the program) ### Keep Coupling Loose - create classes and routines with small, direct, visible, and flexible relations to other classes and routines, - one module can easily be used by other modules - create modules that depend little on other modules. Make them detached - - Coupling Criteria ( Size, Visibility, Flexibility) - Kinds of Coupling ( Simple-data-parameter coupling, Simple -object coupling, Object-parameter coupling, Semantic coupling), Semantic coupling is dangerous because changing code in the used module can break code ### Look for Common Design Patterns - Common patterns include Adapter, Bridge, Decorator, Facade, Factory Method, Observor, Singleton, Strategy, and Template Method - Patterns reduce complexity by providing ready-made abstractions - Patterns reduce errors by institutionalizing details of common solutions - Patterns provide heuristic value by suggesting design alternatives - Patterns streamline communication by moving the design dialog to a higher level  ### Other Heuristics - Aim for Strong Cohesion - Build Hierarchies - Formalize Class Contracts - Assign Responsibilities - Design for Test - Avoid Failure - Choose Binding Time Consciously - Make Central Points of Control - Consider Using Brute Force - Draw a Diagram - Keep Your Design Modular ### Summary of Design Heuristics Here’s a summary of major design heuristics: ■ Find Real-World Objects ■ Form Consistent Abstractions ■ Encapsulate Implementation Details ■ Inherit When Possible ■ Hide Secrets (Information Hiding) ■ Identify Areas Likely to Change ■ Keep Coupling Loose ■ Look for Common Design Patterns The following heuristics are sometimes useful too: ■ Aim for Strong Cohesion ■ Build Hierarchies ■ Formalize Class Contracts ■ Assign Responsibilities ■ Design for Test ■ Avoid Failure ■ Choose Binding Time Consciously ■ Make Central Points of Control ■ Consider Using Brute Force ■ Draw a Diagram ■ Keep Your Design Modular ### Guidelines for Using Heuristics - 1. Understanding the Problem - 2. Devising a Plan - 3. Carrying out the Plan - 4. Looking Back. ## 5.4 Design Practices - Iterate - Divide and Conquer - Top-Down and Bottom-Up Design Approaches ( top down tends to start simple, but sometimes low-level complexity ripples back to the top, and those ripples can make things more complex than they really needed to be. Bottom up tends to start complex, but identifying that complexity early on leads to better design of the higher-level classes—if the complexity doesn’t torpedo the whole system first) - Experimental Prototyping - Collaborative Design ( two heads are often better than one, discuss and listen) - How Much Design Is Enough?  - Capturing Your Design Work ( Insert design documentation into the code itself, Capture design discussions and decisions on a Wiki, Write e-mail summaries, Use a digital camera, Save design flip charts, Use CRC (Class, Responsibility, Collaborator) cards , Create UML diagrams at appropriate levels of detail ## CHECKLIST: Design in Construction ### Design Practices ❑ Have you iterated, selecting the best of several attempts rather than the first attempt? ❑ Have you tried decomposing the system in several different ways to see which way will work best? ❑ Have you approached the design problem both from the top down and from the bottom up? ❑ Have you prototyped risky or unfamiliar parts of the system, creating the absolute minimum amount of throwaway code needed to answer specific questions? ❑ Has your design been reviewed, formally or informally, by others? ❑ Have you driven the design to the point that its implementation seems obvious? ❑ Have you captured your design work using an appropriate technique such as a Wiki, e-mail, flip charts, digital photography, UML, CRC cards, or comments in the code itself? ### Design Goals ❑ Does the design adequately address issues that were identified and deferred at the architectural level? ❑ Is the design stratified into layers? ❑ Are you satisfied with the way the program has been decomposed into subsystems, packages, and classes? ❑ Are you satisfied with the way the classes have been decomposed into routines? ❑ Are classes designed for minimal interaction with each other? ❑ Are classes and subsystems designed so that you can use them in other systems? ❑ Will the program be easy to maintain? ❑ Is the design lean? Are all of its parts strictly necessary? ❑ Does the design use standard techniques and avoid exotic, hard-to-understand elements? ❑ Overall, does the design help minimize both accidental and essential complexity? ## Key Points ■ Software’s Primary Technical Imperative is managing complexity. This is greatly aided by a design focus on simplicity. ■ Simplicity is achieved in two general ways: minimizing the amount of essential complexity that anyone’s brain has to deal with at any one time, and keeping accidental complexity from proliferating needlessly. ■ Design is heuristic. Dogmatic adherence to any single methodology hurts creativity and hurts your programs. ■ Good design is iterative; the more design possibilities you try, the better your final design will be. ■ Information hiding is a particularly valuable concept. Asking “What should I hide?” settles many difficult design issues. ■ Lots of useful, interesting information on design is available outside this book. The perspectives presented here are just the tip of the iceberg. --

Guideline

[puddlejumper26]

Chapter 6 Working Classes

6.1 Class Foundations: Abstract Data Types (ADTs)

• a collection of data and operations that work on that data

Example of the Need for an ADT

currentFont.sizeInPixels = PointsToPixels( 12 )
currentFont.SetSizeInPoints( sizeInPoints )
currentFont.SetSizeInPixels( sizeInPixels )
currentFont.SetBoldOn()
currentFont.SetBoldOff()
currentFont.SetItalicOn()
currentFont.SetItalicOff()
currentFont.SetTypeFace( faceName )

Benefits of Using ADTs

• hide implementation details
• Changes don’t affect the whole program
• make the interface more informative
• improve performance
• more obviously correct
• more self-documenting
• don’t have to pass data all over your program
• work with real-world entities rather than with low-level implementation structures

Guidelines of ADT

• Build or use typical low-level data types as ADTs, not as low-level data types
• Treat common objects such as files as ADTs
• Treat even simple items as ADTs
• Refer to an ADT independently of the medium it’s stored on

Handling Multiple Instances of Data with ADTs in Non-ObjectOriented Environments

ADTs and Classes

• ADT form the foundation for the concept of classes
• implement each ADT as its own class
• Classes usually involve the additional concepts of inheritance and polymorphism

6.2 Good Class Interfaces

• creating a good interface

Good Abstraction

• A class interface provides an abstraction of the implementation that’s hidden behind the interface
• The class’s interface should offer a group of routines that clearly belong together
• this class might have additional routines and data to support these services
• -
• Present a consistent level of abstraction in the class interface
• Be sure you understand what abstraction the class is implementing
• Provide services in pairs with their opposites
• Move unrelated information to another class
• Make interfaces programmatic rather than semantic when possible
• Beware of erosion of the interface’s abstraction under modification （As a class is modified and extended, you often discover additional functionality that’s needed, that doesn’t quite fit with the original class interface, but that seems too hard to implement any other way.）
• Don’t add public members that are inconsistent with the interface abstraction
• Consider abstraction and cohesion together （ a class interface that presents a good abstraction usually has strong cohesion. Classes with strong cohesion tend to present good abstractions, although that relationship is not as strong）

Good Encapsulation

• Abstraction helps to manage complexity by providing models that allow you to ignore implementation details
• Encapsulation is the enforcer that prevents you from looking at the details even if you want to.
• without encapsulation, abstraction tends to break down
• -
• Minimize accessibility of classes and members
• Don’t expose member data in public
• Avoid putting private implementation details into a class’s interface
• Don’t make assumptions about the class’s users
• Avoid friend classes
• Don’t put a routine into the public interface just because it uses only public routines
• Favor read-time convenience to write-time convenience
• Be very, very wary of semantic violations of encapsulation
• Watch for coupling that’s too tight

6.3 Design and Implementation Issues

Containment (“has a” Relationships)

• Containment is the simple idea that a class contains a primitive data element or object.
• -
• Implement “has a” through containment （For example, an employee “has a” name, “has a” phone number, “has a” tax ID, and so on. ）
• Implement “has a” through private inheritance as a last resort
• Be critical of classes that contain more than about seven data members （If a class contains more than about seven data， members, consider whether the class should be decomposed into multiple smaller classes）

Inheritance (“is a” Relationships)

• Inheritance is the idea that one class is a specialization of another class.

• to create simpler code by defining a base class that specifies common elements of two or more derived classes

• Implement “is a” through public inheritance

• Design and document for inheritance or prohibit it

• Adhere to the Liskov Substitution Principle (LSP) （ you shouldn’t inherit from a base class unless the derived class truly “is a” more specific version of the base class）

• Be sure to inherit only what you want to inherit

• inherited routines come in three basic flavors: ■ An abstract overridable routine means that the derived class inherits the routine’s interface but not its implementation. ■ An overridable routine means that the derived class inherits the routine’s interface and a default implementation and it is allowed to override the default implementation. ■ A non-overridable routine means that the derived class inherits the routine’s interface and its default implementation and it is not allowed to override the routine’s implementation.

• Don’t “override” a non-overridable member function （Don’t reuse names of non-overridable base-class routines in derived classes）

• Move common interfaces, data, and behavior as high as possible in the inheritance tree （The higher you move interfaces, data, and behavior, the more easily derived classes can use them）

• Be suspicious of classes of which there is only one instance （The Singleton pattern is one notable exception to this guideline）

• Be suspicious of base classes of which there is only one derived class

• Be suspicious of classes that override a routine and do nothing inside the derived routine

• Avoid deep inheritance trees （Deep inheritance trees increase complexity）

• Prefer polymorphism to extensive type checking （Frequently repeated case statements）

• Make all data private, not protected

• -

• Multiple Inheritance

• multiple inheritance is useful primarily for defining “mixins,”

When to use inheritance and when to use containment:

■ If multiple classes share common data but not behavior, create a common object that those classes can contain. ■ If multiple classes share common behavior but not data, derive them from a common base class that defines the common routines. ■ If multiple classes share common data and behavior, inherit from a common base class that defines the common data and routines. ■ Inherit when you want the base class to control your interface; contain when you want to control your interface

Member Functions and Data

• Keep the number of routines in a class as small as possible
• Disallow implicitly generated member functions and operators you don’t want
• Minimize the number of different routines called by a class （ the more classes a class used, the higher its fault rate tended to be. These concepts are sometimes called “fan out.）
• Minimize indirect routine calls to other classes
• In general, minimize the extent to which a class collaborates with other classes

Constructors

• Initialize all member data in all constructors, if possible
• Enforce the singleton property by using a private constructor
• Prefer deep copies to shallow copies until proven otherwise

6.4 Reasons to Create a Class

• Model real-world objects
• Model abstract objects
• Reduce complexity
• Isolate complexity
• Hide implementation details
• Limit effects of changes
• Hide global data
• Streamline parameter passing
• Make central points of control （control each task in one place）
• Facilitate reusable code
• Plan for a family of programs
• Package related operations
• Accomplish a specific refactoring

Classes to Avoid

• Avoid creating god classes
• Eliminate irrelevant classes
• Avoid classes named after verbs

6.5 Language-Specific Issues

6.6 Beyond Classes: Packages

■ Naming conventions that differentiate which classes are public and which are for the package’s private use ■ Naming conventions, code-organization conventions (project structure), or both that identify which package each class belongs to ■ Rules that define which packages are allowed to use which other packages, including whether the usage can be inheritance, containment, or both

CHECKLIST: Class Quality

Abstract Data Types

❑ Have you thought of the classes in your program as abstract data types and evaluated their interfaces from that point of view?

Abstraction

❑ Does the class have a central purpose? ❑ Is the class well named, and does its name describe its central purpose? ❑ Does the class’s interface present a consistent abstraction? ❑ Does the class’s interface make obvious how you should use the class? ❑ Is the class’s interface abstract enough that you don’t have to think about how its services are implemented? Can you treat the class as a black box? ❑ Are the class’s services complete enough that other classes don’t have to meddle with its internal data? ❑ Has unrelated information been moved out of the class? ❑ Have you thought about subdividing the class into component classes, and have you subdivided it as much as you can? ❑ Are you preserving the integrity of the class’s interface as you modify the class?

Encapsulation

❑ Does the class minimize accessibility to its members? ❑ Does the class avoid exposing member data? ❑ Does the class hide its implementation details from other classes as much as the programming language permits? ❑ Does the class avoid making assumptions about its users, including its derived classes? ❑ Is the class independent of other classes? Is it loosely coupled?

Inheritance

❑ Is inheritance used only to model “is a” relationships—that is, do derived classes adhere to the Liskov Substitution Principle? ❑ Does the class documentation describe the inheritance strategy? ❑ Do derived classes avoid “overriding” non-overridable routines? ❑ Are common interfaces, data, and behavior as high as possible in the inheritance tree? ❑ Are inheritance trees fairly shallow? ❑ Are all data members in the base class private rather than protected?

Other Implementation Issues

❑ Does the class contain about seven data members or fewer? ❑ Does the class minimize direct and indirect routine calls to other classes? ❑ Does the class collaborate with other classes only to the extent absolutely necessary? ❑ Is all member data initialized in the constructor? ❑ Is the class designed to be used as deep copies rather than shallow copies unless there’s a measured reason to create shallow copies?

Language-Specific Issues

❑ Have you investigated the language-specific issues for classes in your specific programming language?

--

Guideline

[puddlejumper26]

Chapter 7 High Quality Routines

• A routine is an individual method or procedure invocable for a single purpose
• e.g. A function in C++, a method in Java, a function or sub procedure in Microsoft Visual Basic
• A low-quality routine ■ The routine has a bad name. HandleStuff() tells you nothing about what the routine does. ■ The routine isn’t documented. ■ The routine has a bad layout. (Layout is discussed in Chapter 31,“Layout and Style.”) ■ The routine’s input variable, inputRec, is changed. If it’s an input variable, its value should not be modified (and in C++ it should be declared const). If the value of the variable is supposed to be modified, the variable should not be called inputRec. ■ The routine reads and writes global variables. It should communicate with other routines more directly than by reading and writing global variables. ■ The routine doesn’t have a single purpose. It initializes some variables, writes to a database, does some calculations—none of which seem to be related to each other in any way. A routine should have a single, clearly defined purpose. ■ The routine doesn’t defend itself against bad data. ■ The routine uses several magic numbers: 100, 4.0, 12, 2, and 3. Magic numbers are discussed in Section 12.1, “Numbers in General.” ■ Some of the routine’s parameters are unused ■ The routine has too many parameters. The upper limit for an understandable number of parameters is about 7; ■ The routine’s parameters are poorly ordered and are not documented.

--

• invented for saving space and improving performance

7.1 Valid Reasons to Create a Routine

• Reduce complexity (single most important reason)
• Introduce an intermediate, understandable abstraction (one of the best ways to document its purpose)
• Avoid duplicate code (You need less new code to override a short, well-factored routine than a long, poorly factored routine)
• Support subclassing
• Hide sequences
• Hide pointer operations (Pointer operations tend to be hard to read and error prone.)
• Improve portability
• Simplify complicated boolean tests
• Improve performance

Operations That Seem Too Simple to Put Into Routines

• a reluctance to create a simple routine for a simple purpose

■ Isolate complexity ■ Hide implementation details ■ Limit effects of changes ■ Hide global data ■ Make central points of control ■ Facilitate reusable code ■ Accomplish a specific refactoring

7.2 Design at the Routine Level

• Class Level ( encapsulation, abstraction )
• Routine Level (cohesion )

--

• Sequential cohesion (a routine contains operations that must be performed in a specific order, that share data from step to step, and that don’t make up a complete function when done together )
• Communicational cohesion ( operations in a routine make use of the same data and aren’t related in any other way)
• Temporal cohesion (operations are combined into a routine because they are all done at the same time.)
• Procedural cohesion(operations in a routine are done in a specified order)
• Logical cohesion (several operations are stuffed into the same routine and one of the operations is selected by a control flag that’s passed in)
• Coincidental cohesion (operations in a routine have no discernible relationship to each other)

7.3 Good Routine Names

• Describe everything the routine does
• Avoid meaningless, vague, or wishy-washy verbs (Routine names like HandleCalculation(), PerformServices(), OutputUser(), ProcessInput(), and DealWithOutput() don’t tell you what the routines do)
• Don’t differentiate routine names solely by number
• Make names of routines as long as necessary ( the optimum average length for a variable name is 9 to 15 characters)
• To name a function, use a description of the return value ( e.g. cos(), customerId.Next(), printer.IsReady(), and pen.CurrentColor())
• To name a procedure, use a strong verb followed by an object ( e.g. PrintDocument(), CalcMonthlyRevenues(), CheckOrderlnfo(), and RepaginateDocument() )
• Use opposites precisely ( e.g. add/remove, begin/end, first/last)
• Establish conventions for common operations

7.4 How Long Can a Routine Be?

• The theoretical best maximum length - 50 to 150 lines
• A large percentage of routines in object-oriented programs will be accessor routines, which will be very short

7.5 How to Use Routine Parameters

• Put parameters in input-modify-output order
• Consider creating your own in and out keywords
• If several routines use similar parameters, put the similar parameters in a consistent order
• Use all the parameters
• Put status or error variables last
• Don’t use routine parameters as working variables
• Document interface assumptions about parameters
• Limit the number of a routine’s parameters to about 7
• Consider an input, modify, and output naming convention for parameters
• Pass the variables or objects that the routine needs to maintain its interface abstraction
• Use named parameters
• Make sure actual parameters match formal parameters (A common mistake is to put the wrong type of variable in a routine call)

7.6 Special Considerations in the Use of Functions

• A function is a routine that returns a value;
• A procedure is a routine that does not.

When to Use a Function and When to Use a Procedure

• A function would take only input parameters and return its only value through the function itself. The function would always be named for the value it returned, as sin(), CustomerID(), and ScreenHeight() are
• A procedure, on the other hand, could take input, modify, and output parameters—as many of each as it wanted to.

Setting the Function’s Return Value

• Check all possible return paths
• Don’t return references or pointers to local data

7.7 Macro Routines and Inline Routines

• Fully parenthesize macro expressions
• Surround multiple-statement macros with curly braces
• Name macros that expand to code like routines so that they can be replaced by routines if necessary

Limitations on the Use of Macro Routines

■ const for declaring constant values ■ inline for defining functions that will be compiled as inline code ■ template for defining standard operations like min, max, and so on in a type-safe way ■ enum for defining enumerated types ■ typedef for defining simple type substitutions

Inline Routines

• Use inline routines sparingly

CHECKLIST: High-Quality Routines

Big-Picture Issues

❑ Is the reason for creating the routine sufficient? ❑ Have all parts of the routine that would benefit from being put into routines of their own been put into routines of their own? ❑ Is the routine’s name a strong, clear verb-plus-object name for a procedure or a description of the return value for a function? ❑ Does the routine’s name describe everything the routine does? ❑ Have you established naming conventions for common operations? ❑ Does the routine have strong, functional cohesion—doing one and only one thing and doing it well? ❑ Do the routines have loose coupling—are the routine’s connections to other routines small, intimate, visible, and flexible? ❑ Is the length of the routine determined naturally by its function and logic, rather than by an artificial coding standard?

Parameter-Passing Issues

❑ Does the routine’s parameter list, taken as a whole, present a consistent interface abstraction? ❑ Are the routine’s parameters in a sensible order, including matching the order of parameters in similar routines? ❑ Are interface assumptions documented? ❑ Does the routine have seven or fewer parameters? ❑ Is each input parameter used? ❑ Is each output parameter used? ❑ Does the routine avoid using input parameters as working variables? ❑ If the routine is a function, does it return a valid value under all possible circumstances?

Key Points

■ The most important reason for creating a routine is to improve the intellectual manageability of a program, and you can create a routine for many other good reasons. Saving space is a minor reason; improved readability, reliability, and modifiability are better reasons. ■ Sometimes the operation that most benefits from being put into a routine of its own is a simple one. ■ You can classify routines into various kinds of cohesion, but you can make most routines functionally cohesive, which is best. ■ The name of a routine is an indication of its quality. If the name is bad and it’s accurate, the routine might be poorly designed. If the name is bad and it’s inaccurate, it’s not telling you what the program does. Either way, a bad name means that the program needs to be changed. ■ Functions should be used only when the primary purpose of the function is to return the specific value described by the function’s name. ■ Careful programmers use macro routines with care and only as a last resort.

--

Guideline

[puddlejumper26]

Chapter 8 Defensive Programming

• how to protect yourself from the cold, cruel world of invalid data, events that can “never” happen, and other programmers’ mistakes

8.1 Protecting Your Program from Invalid Inputs

• Check the values of all data from external sources
• Check the values of all routine input parameters
• Decide how to handle bad inputs The best form of defensive coding is not inserting errors in the first place. Using iterative design, writing pseudocode before code, writing test cases before writing the code, and having low-level design inspections are all activities that help to prevent inserting defects

8.2 Assertions

• An assertion is code that’s used during development—usually a routine or macro—that allows a program to check itself as it runs.

Building Your Own Assertion Mechanism

Guidelines for Using Assertions

• Use error-handling code for conditions you expect to occur; use assertions for conditions that should never occur
• Avoid putting executable code into assertions
• Use assertions to document and verify preconditions and postconditions
• For highly robust code, assert and then handle the error anyway

8.3 Error-Handling Techniques

• Return a neutral value
• Substitute the next piece of valid data
• Return the same answer as the previous time
• Substitute the closest legal value
• Log a warning message to a file (console.log)
• Return an error code
• Call an error-processing routine/object
• Display an error message wherever the error is encountered
• Handle the error in whatever way works best locally
• Shut down

Robustness vs. Correctness

• Correctness means never returning an inaccurate result; returning no result is better than returning an inaccurate result.
• Robustness means always trying to do something that will allow the software to keep operating, even if that leads to results that are inaccurate sometimes.

High-Level Design Implications of Error Processing

8.4 Exceptions

• Exceptions are a specific means by which code can pass along errors or exceptional events to the code that called it
• Use exceptions to notify other parts of the program about errors that should not be ignored
• only for conditions that are truly exceptional
• Don’t use an exception to pass the buck (If an error condition can be handled locally, handle it locally)
• Avoid throwing exceptions in constructors and destructors unless you catch them in the same place
• Throw exceptions at the right level of abstraction
• Include in the exception message all information that led to the exception
• Avoid empty catch blocks
• Know the exceptions your library code throws
• Consider building a centralized exception reporter
• Standardize your project’s use of exceptions
• Consider alternatives to exceptions

8.5 Barricade Your Program to Contain the Damage Caused by Errors

• Barricades are a damage-containment strategy (similar to having isolated compartments in the hull of a ship)
• One way to barricade for defensive programming purposes is to designate certain interfaces as boundaries to “safe” areas.

• operating-room technique (Data is sterilized before it’s allowed to enter the operating room)
• Convert input data to the proper type at input time
• Relationship Between Barricades and Assertions (Routines that are outside the barricade should use error handling because it isn’t safe to make any assumptions about the data. - Routines inside the barricade should use assertions, because the data passed to them is supposed to be sanitized before it’s passed across the barricade)

8.6 Debugging Aids

Don’t Automatically Apply Production Constraints to the Development Version

Introduce Debugging Aids Early

Use Offensive Programming

• Exceptional cases should be obvious and recoverable
• Ways of programming offensively ■ Make sure asserts abort the program. Don’t allow programmers to get into the habit of just hitting the Enter key to bypass a known problem. Make the problem painful enough that it will be fixed. ■ Completely fill any memory allocated so that you can detect memory allocation errors. ■ Completely fill any files or streams allocated to flush out any file-format errors. ■ Be sure the code in each case statement’s default or else clause fails hard (aborts the program) or is otherwise impossible to overlook. ■ Fill an object with junk data just before it’s deleted. ■ Set up the program to e-mail error log files to yourself so that you can see the kinds of errors that are occurring in the released software, if that’s appropriate for the kind of software you’re developing

Plan to Remove Debugging Aids

• Use version-control tools and build tools like ant and make
• Use a built-in preprocessor
• Write your own preprocessor
• Use debugging stubs

8.7 Determining How Much Defensive Programming to Leave in Production Code

• Leave in code that checks for important errors
• Remove code that checks for trivial errors
• Remove code that results in hard crashes
• Leave in code that helps the program crash gracefully
• Log errors for your technical support personnel
• Make sure that the error messages you leave in are friendly

8.8 Being Defensive About Defensive Programming

8.9 CHECKLIST: Defensive Programming

General

❑ Does the routine protect itself from bad input data? ❑ Have you used assertions to document assumptions, including preconditions and postconditions? ❑ Have assertions been used only to document conditions that should never occur? ❑ Does the architecture or high-level design specify a specific set of errorhandling techniques? ❑ Does the architecture or high-level design specify whether error handling should favor robustness or correctness? ❑ Have barricades been created to contain the damaging effect of errors and reduce the amount of code that has to be concerned about error processing? ❑ Have debugging aids been used in the code? ❑ Have debugging aids been installed in such a way that they can be activated or deactivated without a great deal of fuss? ❑ Is the amount of defensive programming code appropriate—neither too much nor too little? ❑ Have you used offensive-programming techniques to make errors difficult to overlook during development?

Exceptions

❑ Has your project defined a standardized approach to exception handling? ❑ Have you considered alternatives to using an exception? ❑ Is the error handled locally rather than throwing a nonlocal exception, if possible? ❑ Does the code avoid throwing exceptions in constructors and destructors? ❑ Are all exceptions at the appropriate levels of abstraction for the routines that throw them? ❑ Does each exception include all relevant exception background information? ❑ Is the code free of empty catch blocks? (Or if an empty catch block truly is appropriate, is it documented?)

Security Issues

❑ Does the code that checks for bad input data check for attempted buffer overflows, SQL injection, HTML injection, integer overflows, and other malicious inputs? ❑ Are all error-return codes checked? ❑ Are all exceptions caught? ❑ Do error messages avoid providing information that would help an attacker break into the systems?

--

Guideline

[puddlejumper26]

Chapter 9 The Pseudocode Programing Process

• Pseudocode Programming Process (PPP) - reduces the work required during design and documentation and improves the quality of both.

9.1 Summary of Steps in Building Classes and Routines

Steps in Creating a Class

• Create a general design for the class
• Construct each routine within the class
• Review and test the class as a whole

Steps in Building a Routine

9.2 Pseudocode for Pros

• “pseudocode” refers to an informal

• guidelines for using pseudocode effectively: ■ Use English-like statements that precisely describe specific operations. ■ Avoid syntactic elements from the target programming language. ■ Write pseudocode at the level of intent. Describe the meaning of the approach rather than how the approach will be implemented in the target language. ■ Write pseudocode at a low enough level that generating code from it will be nearly automatic. If the pseudocode is at too high a level, it can gloss over problematic details in the code. Refine the pseudocode in more and more detail until it seems as if it would be easier to simply write the code.

9.3 Constructing Routines by Using the PPP

Design the Routine

• Check the prerequisites
• Define the problem the routine will solve -- high-level design should at least indicate ■ The information the routine will hide ■ Inputs to the routine ■ Outputs from the routine ■ Preconditions that are guaranteed to be true before the routine is called (input values within certain ranges, streams initialized, files opened or closed, buffers filled or flushed, etc.) ■ Postconditions that the routine guarantees will be true before it passes control back to the caller (output values within specified ranges, streams initialized, files opened or closed, buffers filled or flushed, etc.)
• Name the routine
• Decide how to test the routine
• Research functionality available in the standard libraries
• Think about error handling
• Think about efficiency
• Research the algorithms and data types
• Write the pseudocode
• Think about the data
• Check the pseudocode
• Try a few ideas in pseudocode, and keep the best (iterate)

Code the Routine

• Write the routine declaration
• Turn the pseudocode into high-level comments
• Fill in the code below each comment
• Check whether code should be further factored

Check the Code

• Mentally check the routine for errors
• Compile the routine -- guidelines for getting the most out of compiling your routine: ■ Set the compiler’s warning level to the pickiest level possible. You can catch an amazing number of subtle errors simply by allowing the compiler to detect them. ■ Use validators. The compiler checking performed by languages like C can be supplemented by use of tools like lint. Even code that isn’t compiled, such as HTML and JavaScript, can be checked by validation tools. ■ Eliminate the causes of all error messages and warnings.
• Step through the code in the debugger
• Test the code
• Remove errors from the routine

Clean Up Leftovers

■ Check the routine’s interface. ■ Check for general design quality. ■ Check the routine’s variables. ■ Check the routine’s statements and logic. ■ Check the routine’s layout. ■ Check the routine’s documentation. ■ Remove redundant comments.

9.4 Alternatives to the PPP

• Test-first development
• Refactoring
• Design by contract

--

Guideline

[puddlejumper26]

Chapter 10 General Issues in Using Variables

10.1 Data Literacy

• knowing which kind of data to create

10.2 Making Variable Declarations Easy

Implicit Declarations

• Turn off implicit declarations
• Declare all variables
• Use naming conventions
• Check variable names

10.3 Guidelines for Initializing Variables

• avoiding initialization problems ■ The variable has never been assigned a value. ■ The value in the variable is outdated. ■ Part of the variable has been assigned a value and part has not. -- Initialize each variable as it’s declared -- Initialize each variable close to where it’s first used -- Ideally, declare and define each variable close to where it’s first used -- Use final or const when possible -- Pay special attention to counters and accumulators -- Initialize a class’s member data in its constructor -- Check the need for reinitialization -- Initialize named constants once; initialize variables with executable code -- Use the compiler setting that automatically initializes all variables -- Take advantage of your compiler’s warning messages -- Check input parameters for validity -- Use a memory-access checker to check for bad pointers -- Initialize working memory at the beginning of your program

10.4 Scope

• a variable’s celebrity status
• Different languages handle scope in different ways

Localize References to Variables

Keep Variables “Live” for as Short a Time as Possible

• “live time,” the total number of statements over which a variable is live
• A variable’s life begins at the first statement in which it’s referenced; its life ends at the last statement in which it’s referenced.
• it gives you an accurate picture of your code
• reduces the chance of initialization errors
• makes your code more readable

Measuring the Live Time of a Variable

General Guidelines for Minimizing Scope

• Initialize variables used in a loop immediately before the loop rather than back at the beginning of the routine containing the loop
• Don’t assign a value to a variable until just before the value is used
• Group related statements
• Break groups of related statements into separate routines
• Begin with most restricted visibility, and expand the variable’s scope only if necessary

10.5 Persistence

• life span of a piece of data

• Persistence takes several forms ■ for the life of a particular block of code or routine. ■ as long as you allow them to. ■ for the life of a program. ■ forever.

• few steps you can take to avoid this kind of problem ■ Use debug code or assertions in your program to check critical variables for reasonable values. ■ Set variables to “unreasonable values” when you’re through with them. ■ Write code that assumes data isn’t persistent. ■ Develop the habit of declaring and initializing all data right before it’s used.

10.6 Binding Time

• the time at which the variable and its value are bound together
• the later you make the binding time, the more flexibility you build into your code

10.7 Relationship Between Data Types and Control Structures

• Sequential data translates to sequential statements in a program (data that’s handled in a defined order.)
• Selective data translates to if and case statements in a program( use one piece or the other, but not both)
• Iterative data translates to for, repeat, and while looping structures in a program( repeated)

10.8 Using Each Variable for Exactly One Purpose

• Use each variable for one purpose only
• Avoid variables with hidden meanings

• Make sure that all declared variables are used

Guideline

[puddlejumper26]

Chapter 11 The Power of Variable Names

[puddlejumper26]

Chapter 12 Fundamental Data Types

[puddlejumper26]

Chapter 13 Unusual Data Types

[puddlejumper26]

Chapter 14 Organizing Straight-Line Code

[puddlejumper26]

Chapter 15 Using Conditionals

[puddlejumper26]

Chapter 16 Controlling Loops

[puddlejumper26]

Chapter 17 Unusual Control Structures

[puddlejumper26]

Chapter 18 Table-Driven Methods

[puddlejumper26]

Chapter 19 General Control Issues

[puddlejumper26]

Chapter 20 The Software-Quality Landscape

[puddlejumper26]

Chapter 21 Collaborative Construction

[puddlejumper26]

Chapter 22 Developer Testing

■ Unit testing is the execution of a complete class, routine, or small program that has been written by a single programmer or team of programmers, which is tested in isolation from the more complete system.

■ Component testing is the execution of a class, package, small program, or other program element that involves the work of multiple programmers or programming teams, which is tested in isolation from the more complete system.

■ Integration testing is the combined execution of two or more classes, packages, components, or subsystems that have been created by multiple programmers or programming teams.

■ Regression testing is the repetition of previously executed test cases for the purpose of finding defects in software that previously passed the same set of tests.

■ System testing is the execution of the software in its final configuration, including integration with other software and hardware systems. It tests for security, performance, resource loss, timing problems, and other issues that can’t be tested at lower levels of integration.

• “testing” refers to testing by the developer, which typically consists of unit tests, component tests, and integration tests but can sometimes include regression tests and system tests.

• Testing is usually broken into two broad categories: black-box testing and white-box (or glass-box) testing. -- Black box testing - refers to tests in which the tester cannot see the inner workings of the item being tested -- White box testing - refers to tests in which the tester is aware of the inner workings of the item being tested.

• Testing is a means of detecting errors.

• Debugging is a means of diagnosing and correcting the root causes of errors that have already been detected

22.1 Role of Developer Testing in Software Quality

Testing is hard

■ Testing’s goal runs counter to the goals of other development activities. ■ Testing can never completely prove the absence of errors. ■ Testing by itself does not improve software quality. ■ Testing requires you to assume that you’ll find errors in your code.

How much time would be enough

Testing During Construction

• During construction, Regardless of your integration or system-testing strategy, you should test each unit thoroughly before you combine it with any others.

22.2 Recommended Approach to Developer Testing

■ Test for each relevant requirement to make sure that the requirements have been implemented. ■ Test for each relevant design concern to make sure that the design has been implemented. ■ Use “basis testing” to add detailed test cases to those that test the requirements and the design. ■ Use a checklist of the kinds of errors you’ve made on the project to date or have made on previous projects.

Test First or Test Last?

• Test First

  ■ doesn’t take any more effort than writing test cases after the code ■ detect defects earlier and can correct them more easily ■ think at least a little bit about the requirements and design before writing code ■ exposes requirements problems sooner ■

Limitations of Developer Testing

• Developer tests tend to be “clean tests”
• Developer testing tends to have an optimistic view of test coverage
• Developer testing tends to skip more sophisticated kinds of test coverage

22.3 Bag of Testing Tricks

Incomplete Testing

• the art of testing is that of picking the test cases most likely to find errors

Structured Basis Testing

• test each statement in a program at least once
• “code coverage” testing & “logic coverage” testing - test all the paths through a program
  1. Start with 1 for the straight path through the routine.
  2. Add 1 for each of the following keywords, or their equivalents: if, while, repeat, for, and, and or.
  3. Add 1 for each case in a case statement. If the case statement doesn’t have a default case, add 1 more.

Data-Flow Testing

• based on the idea that data usage is at least as error-prone as control flow
• Combinations of Data States

Equivalence Partitioning

• A good test case covers a large part of the possible input data
• reduce the number of test cases required

Error Guessing

• creating test cases based upon guesses about where the program might have errors, although it implies a certain amount of sophistication in the guessing.

Boundary Analysis

• write test cases that exercise the boundary conditions

Classes of Bad Data

■ Too little data (or no data) ■ Too much data ■ The wrong kind of data (invalid data) ■ The wrong size of data ■ Uninitialized data

Classes of Good Data

■ Nominal cases—middle-of-the-road, expected values ■ Minimum normal configuration ■ Maximum normal configuration ■ Compatibility with old data

22.4 Typical Errors

Which Classes Contain the Most Errors?

• tend to be concentrated in a few highly defective routines ■ Eighty percent of the errors are found in 20 percent of a project’s classes or routines ■ Fifty percent of the errors are found in 5 percent of a project’s classes
• highly defective routines are extremely expensive
• the implication of expensive routines for development is clear
• the implication of avoiding troublesome routines for maintenance is equally clear

Errors by Classification

• The scope of most errors is fairly limited
• Many errors are outside the domain of construction
• Most construction errors are the programmers’ fault
• Clerical errors (typos) are a surprisingly common source of problems
• Misunderstanding the design is a recurring theme in studies of programmer errors
• Most errors are easy to fix
• measure your own organization’s experiences with errors

Proportion of Errors Resulting from Faulty Construction

Errors in Testing Itself

• Check your work
• Plan test cases as you develop your software
• Keep your test cases
• Plug unit tests into a test framework

22.5 Test-Support Tools

Building Scaffolding to Test Individual Classes

• built for the sole purpose of making it easy to exercise code.

Coverage Monitors

Data Recorder/Logging

Symbolic Debuggers

• a technological supplement to code walk-throughs and inspections.

System Perturbers

Error Databases

22.6 Improving Your Testing

Planning to Test

Retesting (Regression Testing)

Automated Testing

22.7 Keeping Test Records

■ Administrative description of the defect (the date reported, the person who reported it, a title or description, the build number, the date fixed) ■ Full description of the problem ■ Steps to take to repeat the problem ■ Suggested workaround for the problem ■ Related defects ■ Severity of the problem—for example, fatal, bothersome, or cosmetic ■ Origin of the defect: requirements, design, coding, or testing ■ Subclassification of a coding defect: off-by-one, bad assignment, bad array index, bad routine call, and so on ■ Classes and routines changed by the fix ■ Number of lines of code affected by the defect ■ Hours to find the defect ■ Hours to fix the defect Number of defects in each class, sorted from worst class to best, possibly normalized by class size ■ Number of defects in each routine, sorted from worst routine to best, possibly normalized by routine size ■ Average number of testing hours per defect found ■ Average number of defects found per test case ■ Average number of programming hours per defect fixed ■ Percentage of code covered by test cases ■ Number of outstanding defects in each severity classification

--

Guideline

[puddlejumper26]

Chapter 23 Debugging

• process of identifying the root cause of an error and correcting it

23.1 Overview of Debugging Issues

Defects as Opportunities

• the program you’re working on
• the kinds of mistakes you make
• the quality of your code from the point of view of someone who has to read it
• how you solve problems
• how you fix defects

An Ineffective Approach

• Find the defect by guessing (who would do that??)
• Don’t waste time trying to understand the problem
• Fix the error with the most obvious fix
• by Superstition ( yes , I always do)

23.2 Finding a Defect

The Scientific Method of Debugging

1. Gather data through repeatable experiments.
2. Form a hypothesis that accounts for the relevant data.
3. Design an experiment to prove or disprove the hypothesis.
4. Prove or disprove the hypothesis.
5. Repeat as needed.

• An effective approach for finding a defect

1. Stabilize the error. (narrowing the test case to the simplest one that still produces the error. The goal of simplifying the test case is to make it so simple that changing any aspect of it changes the behavior of the error)
2. Locate the source of the error (the “fault”). --a. Gather the data that produces the defect. --b. Analyze the data that has been gathered, and form a hypothesis about the defect. --c. Determine how to prove or disprove the hypothesis, either by testing the program or by examining the code. d. Prove or disprove the hypothesis by using the procedure identified in 2(c).
3. Fix the defect.
4. Test the fix.
5. Look for similar errors.

Tips for Finding Defects

• Use all the data available to make your hypothesis
• Refine the test cases that produce the error
• Exercise the code in your unit test suite
• Use available tools
• Reproduce the error several different ways
• Generate more data to generate more hypotheses
• Use the results of negative tests
• Brainstorm for possible hypotheses
• Keep a notepad by your desk, and make a list of things to try
• Narrow the suspicious region of the code
• Be suspicious of classes and routines that have had defects before
• Check code that’s changed recently
• Expand the suspicious region of the code
• Integrate incrementally
• Check for common defects
• Talk to someone else about the problem
• Take a break from the problem

Brute-Force Debugging

• often-overlooked approach to debugging software problems

• Set a maximum time for quick and dirty debugging
• Make a list of brute-force techniques

Syntax Errors

• Don’t trust line numbers in compiler messages
• Don’t trust compiler messages
• Don’t trust the compiler’s second message
• Divide and conquer
• Find misplaced comments and quotation marks

23.3 Fixing a Defect

• Understand the problem before you fix it
• Understand the program, not just the problem
• Confirm the defect diagnosis
• Save the original source code
• Fix the problem, not the symptom
• Change the code only for good reason
• Make one change at a time
• Check your fix
• Add a unit test that exposes the defect
• Look for similar defects

23.4 Psychological Considerations in Debugging

23.5 Debugging Tools—Obvious and Not-So-Obvious

• Set your compiler’s warning level to the highest, pickiest level possible, and fix the errors it reports
• Treat warnings as errors
• Initiate projectwide standards for compile-time settings

--

Guideline

[puddlejumper26]

Chapter 24 Refactoring

24.1 Kinds of Software Evolution

• like biological evolution in that some mutations are beneficial and many mutations are not
• whether the program’s quality improves or degrades under modification
• one between changes made during construction and those made during maintenance

Philosophy of Software Evolution

• an unselfconscious process

24.2 Introduction to Refactoring

• The Cardinal Rule of Software Evolution is that evolution should improve the internal quality of the program

Reasons to Refactor

• Code is duplicated
• A routine is too long
• A loop is too long or too deeply nested
• A class has poor cohesion
• A class interface does not provide a consistent level of abstraction
• A parameter list has too many parameters
• Changes within a class tend to be compartmentalized
• Changes require parallel modifications to multiple classes
• Inheritance hierarchies have to be modified in parallel
• case statements have to be modified in parallel
• Related data items that are used together are not organized into classes
• A routine uses more features of another class than of its own class
• A primitive data type is overloaded
• A class doesn’t do very much
• A chain of routines passes tramp data
• A middleman object isn’t doing anything
• One class is overly intimate with another
• A routine has a poor name
• Data members are public
• A subclass uses only a small percentage of its parents’ routines
• Comments are used to explain difficult code
• Global variables are used
• A routine uses setup code before a routine call or takedown code after a routine call
• A program contains code that seems like it might be needed someday

24.3 Specific Refactorings

Data-Level Refactorings

• Replace a magic number with a named constant
• Rename a variable with a clearer or more informative name
• Move an expression inline
• Replace an expression with a routine
• Introduce an intermediate variable
• Convert a multiuse variable to multiple single-use variables
• Use a local variable for local purposes rather than a parameter
• Convert a data primitive to a class
• Convert a set of type codes to a class or an enumeration
• Convert a set of type codes to a class with subclasses
• Change an array to an object
• Encapsulate a collection
• Replace a traditional record with a data class

Statement-Level Refactorings

• Decompose a boolean expression
• Move a complex boolean expression into a well-named boolean function
• Consolidate fragments that are duplicated within different parts of a conditional
• Use break or return instead of a loop control variable
• Return as soon as you know the answer instead of assigning a return value within nested if-then-else statements
• Replace conditionals (especially repeated case statements) with polymorphism
• Create and use null objects instead of testing for null values

Routine-Level Refactorings

• Extract routine/extract method
• Move a routine’s code inline
• Convert a long routine to a class
• Substitute a simple algorithm for a complex algorithm
• Add a parameter
• Remove a parameter
• Separate query operations from modification operations
• Combine similar routines by parameterizing them
• Separate routines whose behavior depends on parameters passed in
• Pass a whole object rather than specific fields
• Pass specific fields rather than a whole object
• Encapsulate downcasting

Class Implementation Refactorings

• Change value objects to reference objects
• Change reference objects to value objects
• Replace virtual routines with data initialization
• Change member routine or data placement

Class Interface Refactorings

• Move a routine to another class
• Convert one class to two
• Eliminate a class
• Hide a delegate
• Remove a middleman
• Replace inheritance with delegation
• Replace delegation with inheritance
• Introduce a foreign routine
• Introduce an extension class
• Encapsulate an exposed member variable
• Remove Set() routines for fields that cannot be changed (initialize that field in the object’s constructor rather than providing a misleading Set() routine )
• Hide routines that are not intended to be used outside the class
• Encapsulate unused routines
• Collapse a superclass and subclass if their implementations are very similar

System-Level Refactorings

• Create a definitive reference source for data you can’t control
• Change unidirectional class association to bidirectional class association
• Change bidirectional class association to unidirectional class association
• Provide a factory method rather than a simple constructor

24.4 Refactoring Safely

• Save the code you start with
• Keep refactorings small
• Do refactorings one at a time
• Make a list of steps you intend to take
• Make a parking lot ( a list of the changes that you’d like to make at some point but that don’t need to be made right now)
• Make frequent checkpoints
• Use your compiler warnings
• Retest
• Add test cases
• Review the changes
• Adjust your approach depending on the risk level of the refactoring

Bad Times to Refactor

• Don’t use refactoring as a cover for code and fix
• Avoid refactoring instead of rewriting

24.5 Refactoring Strategies

• Refactor when you add a routine
• Refactor when you add a class
• Refactor when you fix a defect
• Target error-prone modules
• Target high-complexity modules
• In a maintenance environment, improve the parts you touch
• Define an interface between clean code and ugly code, and then move code across the interface

--

Guideline

[puddlejumper26]

Chapter 25 Code-Tuning Strategies

[puddlejumper26]

Chapter 26 Code-Tuning Techniques

[puddlejumper26]

Chapter 27 How Program Size Affects Construction

[puddlejumper26]

Chapter 28 Managing Construction

[puddlejumper26]

Chapter 29 Integration

[puddlejumper26]

Chapter 30 Programming Tools

[puddlejumper26]

Chapter 31 Layout and Style

[puddlejumper26]

Chapter 32 Self-Documenting Code

[puddlejumper26]

Chapter 33 Personal Character

[puddlejumper26]

Chapter 34 Themes in Software Craftsmanship

[puddlejumper26]

Chapter 35 Where to Find More Information