Steve McConnell Quotes

Good visual layout shows the logical structure of a program.

11 years is a long time in this industry.

Implement "is a" through public inheritance. When a programmer decides to create a new class by inheriting from an existing class, that programmer is saying that the new class "is a" more specialized version of the older class. The base class sets expectations about how the derived class will operate and imposes constraints on how the derived class can operate (Meyers 1998).

Spend your time on the 20 percent of the refactorings that provide 80 percent of the benefit.

the road to programming hell is paved with global variables,

It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it.

Programming requires more concentration than other activities. It's the reason programmers get upset about 'quick interruptions' - such interruptions are tantamount to asking a juggler to keep three balls in the air and hold your groceries at the same time.

complicated code is a sign that you don't understand your program well enough to make it simple.

You save time when you don't need to have an awards ceremony every time a C statement does what it's supposed to. Moreover,

In software, consultants sometimes tell you to buy into certain software-development methods to the exclusion of other methods. That's unfortunate because if you buy into any single methodology 100 percent, you'll see the whole world in terms of that methodology. In some instances, you'll miss opportunities to use other methods better suited to your current problem.

it's done by creating 25 times as many dirty tests

In software, the chain isn't as strong as its weakest link; it's as weak as all the weak links multiplied together.

The default movement on a software project should be in the direction of taking elements of the software away to make it simpler rather than adding elements to make it more complex.

The only way to reduce the variability in the estimate is to reduce the variability in the project.

Error processing is turning out to be one of the thorniest problems of modern computer science, and you can't afford to deal with it haphazardly. Some people have estimated that as much as 90 percent of a program's code is written for exceptional, error-processing cases or housekeeping, implying that only 10 percent is written for nominal cases (Shaw in Bentley 1982). With so much code dedicated to handling errors, a strategy for handling them consistently should be spelled out in the architecture.

It's hard enough to find an error in your code when you're looking for it; it's even harder when you've assumed your code is error-free.

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.

Copy and paste is a design error

Trying to apply formal methods to all software projects is just as bad as trying to apply code-and-fix development to all projects.

Be critical of classes that contain more than about seven data members. The

Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively.

Mature testing organizations tend to have five dirty tests for every clean test.

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.

Immature testing organizations tend to have about five clean tests for every dirty test.

Watch for coupling that's too tight. "Coupling" refers to how tight the connection is between two classes. In general, the looser the connection, the better. Several general guidelines flow from this concept: Minimize accessibility of classes and members. Avoid friend classes, because they're tightly coupled. Make data private rather than protected in a base class to make derived classes less tightly coupled to the base class. Avoid exposing member data in a class's public interface. Be wary of semantic violations of encapsulation. Observe the "Law of Demeter" (discussed in Design and Implementation Issues of this chapter). Coupling goes hand in glove with abstraction and encapsulation. Tight coupling occurs when an abstraction is leaky, or when encapsulation is broken.

defect corrections have more than a 50 percent chance of being wrong the first time

Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation.

in the vast majority of systems, efficiency isn't critical.

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.

The job of the average manager requires a shift in focus every few minutes. The job of the average software developer requires that the developer not shift focus more often than every few hours.

Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor

A typical software project can present more opportunities to learn from mistakes than some people get in a lifetime.

Another good reason to create a class is to model an abstract object - an object that isn't a concrete, real-world object but that provides an abstraction of other concrete objects. A good example is the classic Shape object. Circle and Square really exist, but Shape is an abstraction of other specific shapes.

Choose your battles. If rapid development is truly top priority, don't shackle your developers by insisting on too many priorities at once.

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.

Motivation is undoubtedly the single greatest influence on how well people perform. Most productivity studies have found that motivation has a stronger influence on productivity than any other factor.

Hurrying to solve a problem is one of the most time-ineffective things you can do.

Make interfaces programmatic rather than semantic when possible. Each interface consists of a programmatic part and a semantic part. The programmatic part consists of the data types and other attributes of the interface that can be enforced by the compiler. The semantic part of the interface consists of the assumptions about how the interface will be used, which cannot be enforced by the compiler. The semantic interface includes considerations such as "RoutineA must be called before RoutineB" or "RoutineA will crash if dataMember1 isn't initialized before it's passed to RoutineA." The semantic interface should be documented in comments, but try to keep interfaces minimally dependent on documentation. Any aspect of an interface that can't be enforced by the compiler is an aspect that's likely to be misused. Look for ways to convert semantic interface elements to programmatic interface elements by using Asserts or other techniques.

developer testing should probably take 8 to 25 percent of the total project time.

If the derived class isn't going to adhere completely to the same interface contract defined by the base class, inheritance is not the right implementation technique. Consider containment or making a change further up the inheritance hierarchy.

Use locking to control access to global variables. Similar to concurrency control in a multiuser database environment, locking requires that before the value of a global variable can be used or updated, the variable must be "checked out." After the variable is used, it's checked back in. During the time it's in use (checked out), if some other part of the program tries to check it out, the lock/unlock routine displays an error message or fires an assertion.

It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive.

On their way to America, the Pilgrims argued about the best maximum length for a routine. After arguing about it for the entire trip, they arrived at Plymouth Rock and started to draft the Mayflower Compact. They still hadn't settled the maximum-length question, and since they couldn't disembark until they'd signed the compact, they gave up and didn't include it. The result has been an interminable debate ever since about how long a routine can be.

once gotos are introduced, they spread through the code like termites through a rotting house.