- Code Complete, Second Edition
- Preface
- Acknowledgments
- About the Author
- I. Laying the Foundation
- 1. Welcome to Software Construction
- 2. Metaphors for a Richer Understanding of Software Development
- 3. Measure Twice, Cut Once: Upstream Prerequisites
- 3.1. Importance of Prerequisites
- 3.2. Determine the Kind of Software You're Working On
- 3.3. Problem-Definition Prerequisite
- 3.4. Requirements Prerequisite
- 3.5. Architecture Prerequisite
- Typical Architectural Components
- Program Organization
- Major Classes
- Data Design
- Business Rules
- User Interface Design
- Resource Management
- Security
- Performance
- Scalability
- Interoperability
- Internationalization/Localization
- Input/Output
- Error Processing
- Fault Tolerance
- Architectural Feasibility
- Overengineering
- Buy-vs.-Build Decisions
- Reuse Decisions
- Change Strategy
- General Architectural Quality
- Typical Architectural Components
- 3.6. Amount of Time to Spend on Upstream Prerequisites
- Additional Resources
- Key Points
- 4. Key Construction Decisions
- II. Creating High-Quality Code
- 5. Design in Construction
- 5.1. Design Challenges
- 5.2. Key Design Concepts
- 5.3. Design Building Blocks: Heuristics
- Find Real-World Objects
- Form Consistent Abstractions
- Encapsulate Implementation Details
- Inherit—When Inheritance Simplifies the Design
- Hide Secrets (Information Hiding)
- Identify Areas Likely to Change
- Keep Coupling Loose
- Look for Common Design Patterns
- Other Heuristics
- Summary of Design Heuristics
- Guidelines for Using Heuristics
- 5.4. Design Practices
- 5.5. Comments on Popular Methodologies
- Additional Resources
- Key Points
- 6. Working Classes
- 7. High-Quality Routines
- 8. Defensive Programming
- 8.1. Protecting Your Program from Invalid Inputs
- 8.2. Assertions
- 8.3. Error-Handling Techniques
- 8.4. Exceptions
- 8.5. Barricade Your Program to Contain the Damage Caused by Errors
- 8.6. Debugging Aids
- 8.7. Determining How Much Defensive Programming to Leave in Production Code
- 8.8. Being Defensive About Defensive Programming
- Additional Resources
- Key Points
- 9. The Pseudocode Programming Process
- 5. Design in Construction
- III. Variables
- 10. General Issues in Using Variables
- 11. The Power of Variable Names
- 12. Fundamental Data Types
- 13. Unusual Data Types
- IV. Statements
- 14. Organizing Straight-Line Code
- 15. Using Conditionals
- 16. Controlling Loops
- 17. Unusual Control Structures
- 18. Table-Driven Methods
- 19. General Control Issues
- 19.1. Boolean Expressions
- Using true and false for Boolean Tests
- Making Complicated Expressions Simple
- Forming Boolean Expressions Positively
- Using Parentheses to Clarify Boolean Expressions
- Knowing How Boolean Expressions Are Evaluated
- Writing Numeric Expressions in Number-Line Order
- Guidelines for Comparisons to 0
- Common Problems with Boolean Expressions
- 19.2. Compound Statements (Blocks)
- 19.3. Null Statements
- 19.4. Taming Dangerously Deep Nesting
- 19.5. A Programming Foundation: Structured Programming
- 19.6. Control Structures and Complexity
- Key Points
- 19.1. Boolean Expressions
- V. Code Improvements
- 20. The Software-Quality Landscape
- 21. Collaborative Construction
- 22. Developer Testing
- 23. Debugging
- 24. Refactoring
- 25. Code-Tuning Strategies
- 26. Code-Tuning Techniques
- VI. System Considerations
- 27. How Program Size Affects Construction
- 28. Managing Construction
- 29. Integration
- 30. Programming Tools
- VII. Software Craftsmanship
- 31. Layout and Style
- 32. Self-Documenting Code
- 32.1. External Documentation
- 32.2. Programming Style as Documentation
- 32.3. To Comment or Not to Comment
- 32.4. Keys to Effective Comments
- 32.5. Commenting Techniques
- 32.6. IEEE Standards
- Additional Resources
- Key Points
- 33. Personal Character
- 33.1. Isn't Personal Character Off the Topic?
- 33.2. Intelligence and Humility
- 33.3. Curiosity
- 33.4. Intellectual Honesty
- 33.5. Communication and Cooperation
- 33.6. Creativity and Discipline
- 33.7. Laziness
- 33.8. Characteristics That Don't Matter As Much As You Might Think
- 33.9. Habits
- Additional Resources
- Key Points
- 34. Themes in Software Craftsmanship
- 34.1. Conquer Complexity
- 34.2. Pick Your Process
- 34.3. Write Programs for People First, Computers Second
- 34.4. Program into Your Language, Not in It
- 34.5. Focus Your Attention with the Help of Conventions
- 34.6. Program in Terms of the Problem Domain
- 34.7. Watch for Falling Rocks
- 34.8. Iterate, Repeatedly, Again and Again
- 34.9. Thou Shalt Rend Software and Religion Asunder
- Key Points
- 35. Where to Find More Information
- Bibliography
- Index
- About the Author
Classes are currently the best way for programmers to achieve modularity. But modularity is a big topic, and it extends beyond classes. Over the past several decades, software development has advanced in large part by increasing the granularity of the aggregations that we have to work with. The first aggregation we had was the statement, which at the time seemed like a big step up from machine instructions. Then came subroutines, and later came classes.
Cross-Reference
For more on the distinction between classes and packages, see "Levels of Design" in Key Design Concepts.
It's evident that we could better support the goals of abstraction and encapsulation if we had good tools for aggregating groups of objects. Ada supported the notion of packages more than a decade ago, and Java supports packages today. If you're programming in a language that doesn't support packages directly, you can create your own poor-programmer's version of a package and enforce it through programming standards that include the following:
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
These workarounds are good examples of the distinction between programming in a language vs. programming into a language. For more on this distinction, see Program into Your Language, Not in It.
Cross-Reference
This is a checklist of considerations about the quality of the class. For a list of the steps used to build a class, see the checklist in "Chapter 9".
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?
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?
-
No Comment