Code Complete Quotes

Rate this book
Clear rating
Code Complete Code Complete by Steve McConnell
7,402 ratings, 4.28 average rating, 352 reviews
Open Preview
Code Complete Quotes Showing 1-30 of 122
“Programmers working with high-level languages achieve better productivity and quality than those working with lower-level languages. Languages such as C++, Java, Smalltalk, and Visual Basic have been credited with improving productivity, reliability, simplicity, and comprehensibility by factors of 5 to 15 over low-level languages such as assembly and C (Brooks 1987, Jones 1998, Boehm 2000). You save time when you don't need to have an awards ceremony every time a C statement does what it's supposed to.”
Steve McConnell, Code Complete
“the road to programming hell is paved with global variables,”
Steve McConnell, Code Complete
“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.”
Steve McConnell, Code Complete
“Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software-development techniques you use determine how many errors testing will find.”
Steve McConnell, Code Complete
“The big optimizations come from refining the high-level design, not the individual routines.”
Steve McConnell, Code Complete
“once gotos are introduced, they spread through the code like termites through a rotting house.”
Steve McConnell, Code Complete
“You can do anything with stacks and iteration that you can do with recursion.”
Steve McConnell, Code Complete
“Don't differentiate routine names solely by number. One developer wrote all his code in one big function. Then he took every 15 lines and created functions named Part1, Part2, and so on. After that, he created one high-level function that called each part.”
Steve McConnell, Code Complete
“One of the paradoxes of defensive programming is that during development, you'd like an error to be noticeable—you'd rather have it be obnoxious than risk overlooking it. But during production, you'd rather have the error be as unobtrusive as possible, to have the program recover or fail gracefully.”
Steve McConnell, Code Complete
“developers insert an average of 1 to 3 defects per hour into their designs and 5 to 8 defects per hour into code”
Steve McConnell, Code Complete
“The goal is to minimize the amount of a program you have to think about at any one time. You might think of this as mental juggling—the more mental balls the program requires you to keep in the air at once, the more likely you'll drop one of the balls, leading to a design or coding error.”
Steve McConnell, Code Complete
“Spend your time on the 20 percent of the refactorings that provide 80 percent of the benefit.”
Steve McConnell, Code Complete
“A brute-force solution that works is better than an elegant solution that doesn't work. It can take a long time to get an elegant solution to work. In describing the history of searching algorithms, for example, Donald Knuth pointed out that even though the first description of a binary search algorithm was published in 1946, it took another 16 years for someone to publish an algorithm that correctly searched lists of all sizes (Knuth 1998). A binary search is more elegant, but a brute-force, sequential search is often sufficient. When in doubt, use brute force. — Butler Lampson”
Steve McConnell, Code Complete
“Reduce complexity. The single most important reason to create a routine is to reduce a program's complexity. Create a routine to hide information so that you won't need to think about it.”
Steve McConnell, Code Complete
“Inheritance adds complexity to a program, and, as such, it's a dangerous technique. As Java guru Joshua Bloch says, "Design and document for inheritance, or prohibit it." If a class isn't designed to be inherited from, make its members non-virtual in C++, final in Java, or non-overridable in Microsoft Visual Basic so that you can't inherit from it.”
Steve McConnell, Code Complete
“Managing complexity is the most important technical topic in software development. In my view, it's so important that Software's Primary Technical Imperative has to be managing complexity. Complexity is not a new feature of software development.”
Steve McConnell, Code Complete
“Managers of programming projects aren’t always aware that certain programming
issues are matters of religion. If you’re a manager and you try to require compliance
with certain programming practices, you’re inviting your programmers’ ire. Here’s a
list of religious issues:
■ Programming language
■ Indentation style
■ Placing of braces
■ Choice of IDE
■ Commenting style
■ Efficiency vs. readability tradeoffs
■ Choice of methodology—for example, Scrum vs. Extreme Programming vs. evolutionary
delivery
■ Programming utilities
■ Naming conventions
■ Use of gotos
■ Use of global variables
■ Measurements, especially productivity measures such as lines of code per day”
Steve McConnell, Code Complete
“People who are effective at developing high-quality software have spent years accumulating dozens of techniques, tricks, and magic incantations. The techniques are not rules; they are analytical tools.”
Steve McConnell, Code Complete
“The most challenging part of programming is conceptualizing the problem, and many errors in programming are conceptual errors. Because”
Steve McConnell, Code Complete
“Steps in Building a Routine Many of a class's routines will be simple and straightforward to implement: accessor routines, pass-throughs to other objects' routines, and the like. Implementation of other routines will be more complicated, and creation of those routines benefits from a systematic approach. The major activities involved in creating a routine—designing the routine, checking the design, coding the routine, and checking the code—are typically performed in the order shown in Figure 9-2. Figure 9-2. These are the major activities that go into constructing a routine. They're usually performed in the order shown”
Steve McConnell, Code Complete
“By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race. Before the introduction of the Arabic notation, multiplication was difficult, and the division even of integers called into play the highest mathematical faculties. Probably nothing in the modern world would have more astonished a Greek mathematician than to learn that … a huge proportion of the population of Western Europe could perform the operation of division for the largest numbers. This fact would have seemed to him a sheer impossibility…. Our modern power of easy reckoning with decimal fractions is the almost miraculous result of the gradual discovery of a perfect notation. —Alfred North Whitehead”
Steve McConnell, Code Complete
“In the case of natural languages, the linguists Sapir and Whorf hypothesize a relationship between the expressive power of a language and the ability to think certain thoughts. The Sapir-Whorf hypothesis says that your ability to think a thought depends on knowing words capable of expressing the thought. If you don't know the words, you can't express the thought and”
Steve McConnell, Code Complete
“The words available in a programming language for expressing your programming thoughts certainly determine how you express your thoughts and might even determine what thoughts you can express.”
Steve McConnell, Code Complete
“During production, your users need a chance to save their work before the program crashes and they are probably willing to tolerate a few anomalies in exchange for keeping the program going long enough for them to do that. Users don't appreciate anything that results in the loss of their work, regardless of how much it helps debugging and ultimately improves the quality of the program. If your program contains debugging code that could cause a loss of data, take it out of the production version.”
Steve McConnell, Code Complete
“Example 6-11. Java Example of Enforcing a Singleton with a Private Constructor public class MaxId {    // constructors and destructors    private MaxId() {       <-- 1       ...    }    ...    // public routines    public static MaxId GetInstance() {       <-- 2       return m_instance;    }    ...    // private members    private static final MaxId m_instance = new MaxId();       <-- 3    ... } (1)Here is the private constructor. (2)Here is the public routine that provides access to the single instance. (3)Here is the single instance.”
Steve McConnell, Code Complete
“Steps in Building a Routine Many of a class's routines will be simple and straightforward to implement: accessor routines, pass-throughs to other objects' routines, and the like. Implementation of other routines will be more complicated, and creation of those routines benefits from a systematic approach. The major activities involved in creating a routine—designing the routine, checking the design, coding the routine, and checking the code—are typically performed in the order shown in Figure 9-2. Figure 9-2. These are the major activities that go into constructing a routine. They're usually performed in the order”
Steve McConnell, Code Complete
“Here are the benefits you can expect from using this style of pseudocode: Pseudocode makes reviews easier. You can review detailed designs without examining source code. Pseudocode makes low-level design reviews easier and reduces the need to review the code itself. Pseudocode supports the idea of iterative refinement. You start with a high-level design, refine the design to pseudocode, and then refine the pseudocode to source code. This successive refinement in small steps allows you to check your design as you drive it to lower levels of detail. The result is that you catch high-level errors at the highest level, mid-level errors at the middle level, and low-level errors at the lowest level—before any of them becomes a problem or contaminates work at more detailed levels. Pseudocode makes changes easier. A few lines of pseudocode are easier to change than a page of code. Would you rather change a line on a blueprint or rip out a wall and nail in the two-by-fours somewhere else? The effects aren't as physically dramatic in software, but the principle of changing the product when it's most malleable is the same. One of the keys to the success of a project is to catch errors at the "least-value stage," the stage at which the least effort has been invested. Much less has been invested at the pseudocode stage than after full coding, testing, and debugging, so it makes economic sense to catch the errors early.”
Steve McConnell, Code Complete
“Because it's a poor tradeoff to add complexity for dubious performance gains, a good approach to deep vs. shallow copies is to prefer deep copies until proven otherwise.”
Steve McConnell, Code Complete
“One symptom that you have bogged down in complexity overload is when you find yourself doggedly applying a method that is clearly irrelevant, at least to any outside observer. It is like the mechanically inept person whose car breaks down—so he puts water in the battery and empties the ashtrays. — P. J. Plauger”
Steve McConnell, Code Complete
“At the software-architecture level, the complexity of a problem is reduced by dividing the system into subsystems. Humans have an easier time comprehending several simple pieces of information than one complicated piece.”
Steve McConnell, Code Complete

« previous 1 3 4 5