More on this book
Community
Kindle Notes & Highlights
The programming practices described here will help you keep big projects under control and help you maintain and modify software successfully as the demands of your projects change.
Because this book focuses on construction, the most familiar part of the software life cycle, it makes powerful software development techniques understandable to self-taught programmers as well as to programmers
with formal training.
Many technical leads have used Code Complete to educate less-experienced programmers on their teams.
If you've already done all that, you can still benefit from this book's collecting the information in one place for easy reference.
This book will give you a chance to rise above the fray of day-to-day fire fighting and figure out what works and what doesn't.
The research and realworld experience gathered into this handbook will inform and stimulate your thinking about your projects, enabling you to take strategic action so that you don't have to fight the same battles
watershed
Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity.
You don't need to understand every nuance of the code fragments to understand the points they're making.
To access information related to Code Complete, 2d ed., enter cc2e.com/ followed by a four-digit code, an example of which is shown here in the left margin. These website references appear throughout the book.
Code construction typically makes up about 65 percent of the effort on small projects and 50 percent on medium projects. Construction accounts for about 75 percent of the errors on small projects and 50 to 75 percent on medium and large projects. Any activity that accounts for 50 to 75 percent of the errors presents a clear opportunity for improvement. (Chapter 27 contains more details on these statistics.)
The claim that construction errors cost less to fix is true but misleading because the cost of not fixing them can be incredibly high.
Researchers have found that small-scale coding errors account for some of the most expensive software errors of all time, with costs running into hundreds of millions of dollars (Weinberg 1983, SEN 1990).
When art critics get together they talk about Form and Structure and Meaning. When artists get together they talk about where you can buy cheap turpentine. — Pablo Picasso
Steve McConnell is Chief Software Engineer at Construx Software where he oversees Construx's software engineering practices. Steve is the lead for the Construction Knowledge Area of the Software Engineering Body of Knowledge (SWEBOK) project. Steve has worked on software projects at Microsoft, Boeing, and other Seattle-area companies.
The construction process might include some aspects of planning, designing, and checking your work, but mostly "construction" refers to the hands-on part of creating something.
Putting construction in its context with other activities helps keep the focus on the right tasks during construction and appropriately emphasizes important nonconstruction activities.
As the figure indicates, construction is mostly coding and debugging but also involves detailed design, construction planning, unit testing, integration, integration testing, and other activities.
Throughout the book, I use "programming" interchangeably with "construction."
Here are some of the specific tasks involved in construction: Verifying that the groundwork has been laid so that construction can proceed successfully Determining how your code will be tested Designing and writing classes and routines Creating and naming variables and named constants Selecting control structures and organizing blocks of statements
Unit testing, integration testing, and debugging your own code Reviewing other team members' low-level designs and code and having them review yours Polishing code by carefully formatting and commenting it Integrating software components that were created separately Tuning code to make it faster and use fewer resources
Important nonconstruction activities include management, requirements development, software architecture, user-interface design, system testing, and maintenance.
Why is construction an important focus? Here's why: Construction is a large part of software development. Depending on the size of the project, construction typically takes 30 to 80 percent of the total time spent on a project. Anything that takes up that much project time is bound to affect the success of the project.
With a focus on construction, the individual programmer's productivity can improve enormously. A
Construction is the only activity that's guaranteed to be done. The ideal software project goes through careful requirements development and architectural design before construction begins. The ideal project undergoes comprehensive, statistically controlled system testing after construction. Imperfect, real-world projects, however, often skip requirements and design to jump into construction. They drop testing because they have too many errors to fix and they've run out of time. But no matter how rushed or poorly planned a project is, you can't drop construction; it's where the rubber meets
...more
If you like to read books cover to cover, you might simply dive into Chapter 2. If you want to get to specific programming tips, you might begin with Chapter 6, and then follow the cross references to other topics you find interesting. If you're not sure whether any of this applies to you, begin with Determine the Kind of Software You're Working On
Key Points Software construction is the central activity in software development; construction is the only activity that's guaranteed to happen on every project. The main activities in construction are detailed design, coding, debugging, integration, and developer testing (unit testing and integration testing). Other common terms for construction are "coding" and "programming." The quality of the construction substantially affects the quality of the software. In the final analysis, your understanding of how to do construction determines how good a programmer you are, and that's the subject of
...more
By comparing a topic you understand poorly to something similar you understand better, you can come up with insights that result in a better understanding of the less-familiar topic. This use of metaphor is called "modeling."
This use of metaphor is called "modeling."
A good metaphor is simple, relates well to other relevant metaphors, and explains much of the experimental evidence and other observed phenomena.
a heavy stone swinging
pendulum.
When Bachman made the comparison in 1973, data processing was changing from a computer-centered view of information systems to a database-centered view.
A software metaphor is more like a searchlight than a road map. It doesn't tell you where to find the answer; it tells you how to look for it. A metaphor serves more as a heuristic than it does as an algorithm.
A metaphor serves more as a heuristic than it does as an algorithm.
predictable,
A heuristic is a technique that helps you look for an answer. Its
In effect, a heuristic is an algorithm in a clown suit. It's less predictable, it's more fun, and it comes without a 30-day, money-back guarantee.
heuristics
Phuong phap giai quyet van de bang cach danh gia kinh nghiem, va tim giai phap qua thu nghiem va rut tia khuyet diem.
The difference between an algorithm and a heuristic is subtle, and the two terms overlap somewhat.
An algorithm gives you the instructions directly. A heuristic tells you how to discover the instructions for yourself, or at least where to look for them.
The most challenging part of programming is conceptualizing the problem, and many errors in programming are conceptual errors.
knowing how to approach problems in general is at least as valuable as knowing specific solutions for specific problems.
How do you use software metaphors? Use them to give you insight into your programming problems and processes.
Over time, though, the person who uses metaphors to illuminate the software-development process will be perceived as someone who has a better understanding of programming and produces better code faster than people who don't use them.
You design a piece, code a piece, test a piece, and add it to the system a little bit at a time. By taking small steps, you minimize the trouble you can get into at any one time.
In this case, the incremental technique is valuable, but the farming metaphor is terrible.
the farming metaphor
"Accretion,"
