Widely considered one of the best practical guides to programming, Steve McConnell’s original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices—and hundreds of new code samples—illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking—and help you build the highest quality code.
Discover the timeless techniques and strategies that help you:
- Design for minimum complexity and maximum creativity
- Reap the benefits of collaborative development
- Apply defensive programming techniques to reduce and flush out errors
- Exploit opportunities to refactor—or evolve—code, and do it safely
- Use construction practices that are right-weight for your project
- Debug problems quickly and effectively
- Resolve critical construction issues early and correctly
- Build quality into the beginning, middle, and end of your project
About the Author
Steve McConnell is recognized as one of the premier authors and voices in the development community. He is Chief Software Engineer of Construx Software and was the lead developer of Construx Estimate and of SPC Estimate Professional, winner of Software Development magazine's Productivity Award. He is the author of several books, including Code Complete and Rapid Development, both honored with Software Development magazine's Jolt Award.
Read an Excerpt
From Chapter 20: Programming Tools
...20.6 Ideal Programming Environment
This section's description of an ideal programming environment is an excursion into programming fantasyland. Although such a vision is not immediately practical, this book about construction has a responsibility to define where construction tools should be going. All of the capabilities described in this section are easily within the reach of today's technology. Perhaps the description will serve as inspiration for an ambitious toolsmith who will create a programming environment that towers above the ones currently available.
For this discussion, the fantasy environment is called "Cobbler." The name is inspired by the old saying that the cobbler's children are the last to have new shoes, which is true of today's programmers and programming tools.
The Cobbler environment integrates the programming activities of detailed design, coding, and debugging. When source-code control is needed, Cobbler integrates source-code version control too. If the detailed-design practices suggested in this book are followed, the primary detailed-design tool required is PDL, which can be handled easily, even in text environments.
During code construction, Cobbler provides ready access to cross-referenced help on the programming language. Help discusses nuances of the language as well as the basics and mentions common problems in using features of the language. For error messages, Help lists the common problems that might give rise to each message.
The environment provides templates for language constructs so that youdon't need to remember the precise syntax for a case statement, a for loop, or a more unusual construct. The help systems provides a well-organized list of all available routines, and you can paste the template for a routine into your code.
Cobbler enables you to generate a list of all the places in which a variable is used or receives a value. You can get help on a variable declaration the same way you's get help on any other topic, with ready access to the variable definition and comments about it.
You can retrieve information on routines just as easily. You can follow a chain of calls to routines up and down--pointing at the name of the routine you want to view in more detail. You can check variable types in a call to a routine with the touch of key.
Interactive views of program organization
The Cobbler environment radically changes the way you view program source text. Compilers read source files from beginning to end, and traditional development environments force you to view a program the same way. This is sequential and flat--far from what you need for a meaningful view of a program.
In Cobbler, you can view a tangle of routine names, graphically presented, and zoom in on any routine. You can choose the model that organizes the tangle of routines: hierarchy, network, modules, objects, or an alphabetical listing. Your high-level view isn't cluttered by a routine's details until you want to zoom in on them.
When looking at the guts of a routine, you can view them at any of several levels of detail. You can view only the routine's definition or only the comment prolog. You can view code only or comments only. You can view control structures with or without a display of the code they control. In languages with macro commands, you can view a program with the macros expanded or contracted. If they're contracted, you can expend an individual macro with the touch of a key.
In writing this book, I've used a word processor with a powerful outline view. Without the outline view and the ability to study an outline and then zoom in on its detailed contents, I'd have a weak sense of each chapter's structure. The only view I'd see of each chapter would be flat, and the only sense of structure I'd have would come from scrolling from beginning to end. The ability to zoom between low-level and high-level views gives me a sense of the topology of each chapter, and that's critical to organizing my writing.
Organizing source code is as difficult as organizing writing. It's hard to believe that I lack any capability whatsoever to view the topology of my programs, especially when I've had a similar capability in my writing tools for more than five years.
The kinds of components that make up a program can also be improved. The semantics of source files are hazy, and the concept is better replaced by the ideas of modules, packages, or objects. The concept of source files is obsolete. You should be able to think about the semantics of your programs without worrying about how the code is physically stored.
Cobbler provides more active formatting aids than existing environments do. For example, it's graphical user interface makes outer parentheses larger than inner parentheses, as they have been displayed in mathematical texts for a hundred years.
The environment formats code according to user-specified parameters without resorting to a separate pretty-primer program. Any environment that knows about your program already knows where all your logical structures and variable declarations are. In Cobbler, you don't need to resort to a separate program to format your code. Some current environments provide feeble support for automatic indentation of control structures as you enter them. But when they're modified and 45 lines need to be shifted out six columns each, you're on your own. In the ideal programming environment, the environment formats the code according to the code's logical structure. If you change the logical structure, the environment reformats the code accordingly...
Table of Contents
|List of Checklists||xxix|
|List of Tables||xxxi|
|List of Figures||xxxiii|
|Part I||Laying the Foundation|
|1||Welcome to Software Construction||3|
|1.1||What Is Software Construction?||3|
|1.2||Why Is Software Construction Important?||6|
|1.3||How to Read This Book||8|
|2||Metaphors for a Richer Understanding of Software Development||9|
|2.1||The Importance of Metaphors||9|
|2.2||How to Use Software Metaphors||11|
|2.3||Common Software Metaphors||13|
|3||Measure Twice, Cut Once: Upstream Prerequisites||23|
|3.1||Importance of Prerequisites||24|
|3.2||Determine the Kind of Software You're Working On||31|
|3.6||Amount of Time to Spend on Upstream Prerequisites||55|
|4||Key Construction Decisions||61|
|4.1||Choice of Programming Language||61|
|4.3||Your Location on the Technology Wave||66|
|4.4||Selection of Major Construction Practices||69|
|Part II||Creating High-Quality Code|
|5||Design in Construction||73|
|5.2||Key Design Concepts||77|
|5.3||Design Building Blocks: Heuristics||87|
|5.5||Comments on Popular Methodologies||118|
|6.1||Class Foundations: Abstract Data Types (ADTs)||126|
|6.2||Good Class Interfaces||133|
|6.3||Design and Implementation Issues||143|
|6.4||Reasons to Create a Class||152|
|6.6||Beyond Classes: Packages||156|
|7.1||Valid Reasons to Create a Routine||164|
|7.2||Design at the Routine Level||168|
|7.3||Good Routine Names||171|
|7.4||How Long Can a Routine Be?||173|
|7.5||How to Use Routine Parameters||174|
|7.6||Special Considerations in the Use of Functions||181|
|7.7||Macro Routines and Inline Routines||182|
|8.1||Protecting Your Program from Invalid Inputs||188|
|8.5||Barricade Your Program to Contain the Damage Caused by Errors||203|
|8.7||Determining How Much Defensive Programming to Leave in Production Code||209|
|8.8||Being Defensive About Defensive Programming||210|
|9||The Pseudocode Programming Process||215|
|9.1||Summary of Steps in Building Classes and Routines||216|
|9.2||Pseudocode for Pros||218|
|9.3||Constructing Routines by Using the PPP||220|
|9.4||Alternatives to the PPP||232|
|10||General Issues in Using Variables||237|
|10.2||Making Variable Declarations Easy||239|
|10.3||Guidelines for Initializing Variables||240|
|10.7||Relationship Between Data Types and Control Structures||254|
|10.8||Using Each Variable for Exactly One Purpose||255|
|11||The Power of Variable Names||259|
|11.1||Considerations in Choosing Good Names||259|
|11.2||Naming Specific Types of Data||264|
|11.3||The Power of Naming Conventions||270|
|11.4||Informal Naming Conventions||272|
|11.6||Creating Short Names That Are Readable||282|
|11.7||Kinds of Names to Avoid||285|
|12||Fundamental Data Types||291|
|12.1||Numbers in General||292|
|12.4||Characters and Strings||297|
|12.9||Creating Your Own Types (Type Aliasing)||311|
|13||Unusual Data Types||319|
|14||Organizing Straight-Line Code||347|
|14.1||Statements That Must Be in a Specific Order||347|
|14.2||Statements Whose Order Doesn't Matter||351|
|16.1||Selecting the Kind of Loop||367|
|16.2||Controlling the Loop||373|
|16.3||Creating Loops Easily--From the Inside Out||385|
|16.4||Correspondence Between Loops and Arrays||387|
|17||Unusual Control Structures||391|
|17.1||Multiple Returns from a Routine||391|
|17.4||Perspective on Unusual Control Structures||408|
|18.1||General Considerations in Using Table-Driven Methods||411|
|18.2||Direct Access Tables||413|
|18.3||Indexed Access Tables||425|
|18.4||Stair-Step Access Tables||426|
|18.5||Other Examples of Table Lookups||429|
|19||General Control Issues||431|
|19.2||Compound Statements (Blocks)||443|
|19.4||Taming Dangerously Deep Nesting||445|
|19.5||A Programming Foundation: Structured Programming||454|
|19.6||Control Structures and Complexity||456|
|Part V||Code Improvements|
|20||The Software-Quality Landscape||463|
|20.1||Characteristics of Software Quality||463|
|20.2||Techniques for Improving Software Quality||466|
|20.3||Relative Effectiveness of Quality Techniques||469|
|20.4||When to Do Quality Assurance||473|
|20.5||The General Principle of Software Quality||474|
|21.1||Overview of Collaborative Development Practices||480|
|21.4||Other Kinds of Collaborative Development Practices||492|
|22.1||Role of Developer Testing in Software Quality||500|
|22.2||Recommended Approach to Developer Testing||503|
|22.3||Bag of Testing Tricks||505|
|22.6||Improving Your Testing||528|
|22.7||Keeping Test Records||529|
|23.1||Overview of Debugging Issues||535|
|23.2||Finding a Defect||540|
|23.3||Fixing a Defect||550|
|23.4||Psychological Considerations in Debugging||554|
|23.5||Debugging Tools--Obvious and Not-So-Obvious||556|
|24.1||Kinds of Software Evolution||564|
|24.2||Introduction to Refactoring||565|
|25.2||Introduction to Code Tuning||591|
|25.3||Kinds of Fat and Molasses||597|
|25.6||Summary of the Approach to Code Tuning||606|
|26.6||Recoding in a Low-Level Language||640|
|26.7||The More Things Change, the More They Stay the Same||643|
|Part VI||System Considerations|
|27||How Program Size Affects Construction||649|
|27.1||Communication and Size||650|
|27.2||Range of Project Sizes||651|
|27.3||Effect of Project Size on Errors||651|
|27.4||Effect of Project Size on Productivity||653|
|27.5||Effect of Project Size on Development Activities||654|
|28.1||Encouraging Good Coding||662|
|28.3||Estimating a Construction Schedule||671|
|28.5||Treating Programmers as People||680|
|28.6||Managing Your Manager||686|
|29.1||Importance of the Integration Approach||689|
|29.2||Integration Frequency--Phased or Incremental?||691|
|29.3||Incremental Integration Strategies||694|
|29.4||Daily Build and Smoke Test||702|
|30.5||Building Your Own Programming Tools||721|
|Part VII||Software Craftsmanship|
|31||Layout and Style||729|
|31.4||Laying Out Control Structures||745|
|31.5||Laying Out Individual Statements||753|
|31.6||Laying Out Comments||763|
|31.7||Laying Out Routines||766|
|31.8||Laying Out Classes||768|
|32.2||Programming Style as Documentation||778|
|32.3||To Comment or Not to Comment||781|
|32.4||Keys to Effective Comments||785|
|33.1||Isn't Personal Character Off the Topic?||820|
|33.2||Intelligence and Humility||821|
|33.5||Communication and Cooperation||828|
|33.6||Creativity and Discipline||829|
|33.8||Characteristics That Don't Matter As Much As You Might Think||830|
|34||Themes in Software Craftsmanship||837|
|34.2||Pick Your Process||839|
|34.3||Write Programs for People First, Computers Second||841|
|34.4||Program into Your Language, Not in It||843|
|34.5||Focus Your Attention with the Help of Conventions||844|
|34.6||Program in Terms of the Problem Domain||845|
|34.7||Watch for Falling Rocks||848|
|34.8||Iterate, Repeatedly, Again and Again||850|
|34.9||Thou Shalt Rend Software and Religion Asunder||851|
|35||Where to Find More Information||855|
|35.1||Information About Software Construction||856|
|35.2||Topics Beyond Construction||857|
|35.4||A Software Developer's Reading Plan||860|
|35.5||Joining a Professional Organization||862|
Most Helpful Customer Reviews
I first read this book when it was published, and I was just graduating college. Since then I've built software in C, C++, and Pascal. I've built hardware with verilog and VHDL. I've built testbenches with Vera and E. This is the most relevant book, and I still have it on my shelf to loan to new graduates. It helps you to understand all of the most important concepts for developing hardware and software with any language imaginable. With all this, you would think that it is hard to read. But this book is written in an enjoyable style, a rare quality in engineering of any kind. Read it!
Once you've learned the basics of programming, this is the book to get to fill out the 'big picture' of large development projects, AND help with all the little details. From algorithms to coding standards, project estimates to quality assurance, this book clearly overviews the field, and points you in the right direction for more detail. I lent my copy to a friend, so now I'm ordering TWO more.
Easily the best book on software development. The information is described clearly and the examples highlight the message. Many supporting references validate the author's observations and conclusions.
This is a must read for every software developer. In our software development company, we give a copy of this book to every new employee.
I didn't agree with everything in this book, but I did agree with most of it. It's a pretty good set of guidelines and just relates the things that should be common knowledge among programmers but unfortunately obviously ain't. We've settled a lot of arguments with this book. Some have accused it of a Microsoft orientation, but I haven't seen that. I wish schools would start their computer-science track with a flowcharting class, then a class based on this book.
I have found that no matter what programming language you use, this book provides many indespensible tools for building rock solid software. I have made it a habit to revisit this book at least once every 18 months to remind myself of the many ideals to software construction, and to gauge my working progress toward better code construction.
This book will make you a better programmer, regardless of your level of experience, target operating system or language. It's that good.
Old but still useful.
Exhaustive review of programming techniques and tools. A must read for beginners, more experienced programmers can skip sections they are familiar with. Although they do this with the risk of missing some detail that they previously weren't aware of.
There have already been over 130 reviews on this book, what can I add?All I can do is repeat the good reviews that have already been made. This book is wonderful! It is one of the few books that I would say are essential read for anyone who calls themself a programmer! (It would be nice if some managers would take the time to read it also)This book is old, but yet it is not out of date! The advise it gives is timeless. Oh how much better the worlds codebases would be if more programmers were to read this book! Good job Mr. McConnell.
A comprehensive book that covers a wide range of topics on software construction. Based on significant amount of material as well as author's experience. It's a big one, but is broken down well, and not really that hard to go through. The writing style is to-the-point. Offers great advice for different situations, letting you decide what option best fit for you and your organization. Awesome as a reference book as well.
Finally got around to reading this programming standard.It's a substantial book that covers a lot of areas in the programming domain, and would probably round out even the more experienced programmer.
Classic book on software development and software engineering practices and what makes software a success or an impending failure. It's a very good manual for beginners and experienced developers alike.
I don't understand why this book has achieved such a cult following.For the most part it states the trivial and obvious in how to write code well. Is this simply a reflection of what Malcolm and I are always talking about, that the ignorance of most programmers of the most trivial things is quite shocking?
I don't think yet another long review is required for this book because I consider it among the standard books that a real-world software developer should have read. To put it another way, any software developer who already internalized all of the wisdom and techniques in that book can be considered a pretty good developer and / or software team manager. But be careful, this book is not a how-to book and does not focus on any specific technology. You can be an ASP.NET developer working on MS Windows platform or a Python developer working on a GNU/Linux platform. If you are involved with a project that includes more than a few thousands line of code and you work as a part of a team then you owe yourself to have the knowledge described in the book.I think I'll create a small file that includes all the checklists that are given at the end of the chapters as well as the further reading lists and send a copy of that every junior software developer I work with.
An amazing book about software construction. Although very long and slow in the middle, McConnell offers extremely valuable insights into what it means to construct professional software and gives strong themes in computer science. McConnell is a great writer, and his style is perfect in keeping the reader interested and informed. I highly recommend this book, and definitely have a notepad or highlighter ready at all times.
One of the best books for programmers of all levels of experience. Even experienced programmers can benefit from it.
Steve McConnell is a pretty big name in the software development community, and I always enjoy his writing. This book is a collection of good programming habits, a topic which is often neglected in higher-level software engineering books.
This is stuff that needs to be ingrained in a developer's mind. Of particular interest to me since development is a second career and I'm stilling trying to be good at it.
Barnes and Nobles service was great