- 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
Related Topics
Version-control tools: in Configuration Management
Debugging tools: Debugging Tools—Obvious and Not-So-Obvious
Test-support tools: Test-Support Tools
Modern programming tools decrease the amount of time required for construction. Use of a leading-edge tool set—and familiarity with the tools used—can increase productivity by 50 percent or more (Jones 2000; Boehm et al. 2000). Programming tools can also reduce the amount of tedious detail work that programming requires.
A dog might be man's best friend, but a few good tools are a programmer's best friends. As Barry Boehm discovered long ago, 20 percent of the tools tend to account for 80 percent of the tool usage (1987b). If you're missing one of the more helpful tools, you're missing something that you could use a lot.
This chapter is focused in two ways. First, it covers only construction tools. Requirements-specification, management, and end-to-end-development tools are outside the scope of the book. Refer to the "Additional Resources" section at the end of the chapter for more information on tools for those aspects of software development. Second, this chapter covers kinds of tools rather than specific brands. A few tools are so common that they're discussed by name, but specific versions, products, and companies change so quickly that information about most of them would be out of date before the ink on these pages was dry.
A programmer can work for many years without discovering some of the most valuable tools available. The mission of this chapter is to survey available tools and help you determine whether you've overlooked any tools that might be useful. If you're a tool expert, you won't find much new information in this chapter. You might skim the earlier parts of the chapter, read Tool Fantasyland on "Tool Fantasyland," and then move on to the next chapter.
Current design tools consist mainly of graphical tools that create design diagrams. Design tools are sometimes embedded in a computer-aided software engineering (CASE) tool with broader functions; some vendors advertise standalone design tools as CASE tools. Graphical design tools generally allow you to express a design in common graphical notations: UML, architecture block diagrams, hierarchy charts, entity relationship diagrams, or class diagrams. Some graphical design tools support only one notation. Others support a variety.
In one sense, these design tools are just fancy drawing packages. Using a simple graphics package or pencil and paper, you can draw everything that the tool can draw. But the tools offer valuable capabilities that a simple graphics package can't. If you've drawn a bubble chart and you delete a bubble, a graphical design tool will automatically rearrange the other bubbles, including connecting arrows and lower-level bubbles connected to the bubble. The tool takes care of the housekeeping when you add a bubble, too. A design tool can enable you to move between higher and lower levels of abstraction. A design tool will check the consistency of your design, and some tools can create code directly from your design.
-
No Comment