- 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
This section contains resources releated to performance improvement in general. For additional resources that discuss specific code-tuning techniques, see the "Additional Resources" section at the end of Chapter 26.
Smith, Connie U. and Lloyd G. Williams. Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software. Boston, MA: Addison-Wesley, 2002. This book covers software performance engineering, an approach for building performance into software systems at all stages of development. It makes extensive use of examples and case studies for several kinds of programs. It includes specific recommendations for Web applications and pays special attention to scalability.
Newcomer, Joseph M. "Optimization: Your Worst Enemy." May 2000, http://www.flounder.com/optimization.htm. Newcomer is an experienced systems programmer who describes the various pitfalls of ineffective optimization strategies in graphic detail.
Knuth, Donald. The Art of Computer Programming, vol. 1, Fundamental Algorithms, 3d ed. Reading, MA: Addison-Wesley, 1997.
Knuth, Donald. The Art of Computer Programming, vol. 2, Seminumerical Algorithms, 3d ed. Reading, MA: Addison-Wesley, 1997.
Knuth, Donald. The Art of Computer Programming, vol. 3, Sorting and Searching, 2d ed. Reading, MA: Addison-Wesley, 1998.
These are the first three volumes of a series that was originally intended to grow to seven volumes. They can be somewhat intimidating. In addition to the English description of the algorithms, they're described in mathematical notation or MIX, an assembly language for the imaginary MIX computer. The books contain exhaustive details on a huge number of topics, and if you have an intense interest in a particular algorithm, you won't find a better reference.
Sedgewick, Robert. Algorithms in Java, Parts I-IV, 3d ed. Boston, MA: Addison-Wesley, 2002. This book's four parts contain a survey of the best methods of solving a wide variety of problems. Its subject areas include fundamentals, sorting, searching, abstract data type implementation, and advanced topics. Sedgewick's Algorithms in Java, Part V, 3d ed. (2003) covers graph algorithms. Sedgewick's Algorithms in C++, Parts I-IV, 3d ed. (1998), Algorithms in C++, Part V, 3d ed. (2002), Algorithms in C, Parts I-IV, 3d ed. (1997), and Algorithms in C, Part V, 3d ed. (2001) are similarly organized. Sedgewick was a Ph.D. student of Knuth's.
Code-Tuning Strategies
Overall Program Performance
Have you considered improving performance by changing the program requirements?
Have you considered improving performance by modifying the program's design?
Have you considered improving performance by modifying the class design?
Have you considered improving performance by avoiding operating system interactions?
Have you considered improving performance by avoiding I/O?
Have you considered improving performance by using a compiled language instead of an interpreted language?
Have you considered improving performance by using compiler optimizations?
Have you considered improving performance by switching to different hardware?
Have you considered code tuning only as a last resort?
Code-Tuning Approach
Is your program fully correct before you begin code tuning?
Have you measured performance bottlenecks before beginning code tuning?
Have you measured the effect of each code-tuning change?
Have you backed out the code-tuning changes that didn't produce the intended improvement?
Have you tried more than one change to improve performance of each bottleneck—that is, iterated?
-
No Comment