Quotes About Programming

If your function must change the state of something, have it change the state of its owning object.

Duplication and expressiveness take me a very long way into what I consider clean code, and improving dirty code with just these two things in mind can make a huge difference. There is, however, one other thing that I'm aware of doing, which is a bit harder to explain.

To write clean code, you must first write dirty code and then clean it.

The most efficient and effective way to review code is to collaborate in writing it.

the fact that oo languages provide safe and convenient polymorphism means that any source code dependency, no matter where it is, can be inverted

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

The complement is also true: Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change.

That's being attentive to every variable name. You should name a variable using the same care with which you name a first-born child.

Don't hide side effects with a name. Don't use a simple verb to describe a function that does more than just that simple action.

The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.

But then closely related concepts should not be separated into different files unless you have a very good reason. Indeed, this is one of the reasons that protected variables should be avoided.

I used to think 2000 lines was a big program. After all, it was a full box of cards that weighed 10 pounds. Now, however, a program isn't really big until it exceeds 100,000 lines.

It doesn't take a huge amount of knowledge and skill to get a program working. Kids in high school do it all the time. Getting it right is another matter entirely. When software is done right, it requires a fraction of the human resources to create and maintain.

All race conditions, deadlock conditions, and concurrent update problems are due to mutable variables. All the problems we face in applications that require multiple threads, and multiple processors—cannot happen if there are no mutable variables.

Any comment that forces you to look in another module for the meaning of that comment has failed to communicate to you and is not worth the bits it consumes.

More precisely, the Law of Demeter says that a method f of a class C should only call the methods of these: • C • An object created by f • An object passed as an argument to f • An object held in an instance variable of C

Master programmers think of systems as stories to be told rather than programs to be written.

Paradigms are ways of programming, relatively unrelated to languages. A paradigm tells you which programming structures to use, and when to use them. To date, there have been three such paradigms. For reasons we shall discuss later, there are unlikely to be any others.

structured programming, object-orient programming, and functional programming.

Structured programming imposes discipline on direct transfer of control.

Object-oriented programming imposes discipline on indirect transfer of control.

Functional programming imposes discipline upon assignment.

Don't comment bad code—rewrite it." —Brian W. Kernighan and P. J. Plaugher1

Each of the paradigms removes capabilities from the programmer. None of them adds new capabilities. Each imposes some kind of extra discipline that is negative in its intent. The paradigms tell us what not to do, more than they tell us what to do.