Code Readability Quotes

Good code is its own best documentation. As you're about to add a comment, ask yourself, "How can I improve the code so that this comment isn't needed?" Improve the code and then document it to make it even clearer.

Most programs are not write-once. They are reworked and rewritten again and again in their lived. Bugs must be debugged. Changing requirements and the need for increased functionality mean the program itself may be modified on an ongoing basis. During this process, human beings must be able to read and understand the original code. It is therefore more important by far for humans to be able to understand the program than it is for the computer.

Don't you hate code that's not properly indented? Making it [indenting] part of the syntax guarantees that all code is properly indented.

First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.

This evolution may compromise Java's claim of being simpler than C++, but my guess is that the effort will make Java a better language than it is today.

Programs must be written for people to read, and only incidentally for machines to execute.

When you write a program, think of it primarily as a work of literature. You're trying to write something that human beings are going to read. Don't think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it's going to be: You'll understand it today, you'll understand it next week, and your successors who are going to maintain and modify it will understand it.

As pointed out in a followup, Real Perl Programmers prefer things to be visually distinct.

Programs should be written and polished until they acquire publication quality.

Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered.

I wouldn't ever write the full sentence myself, but then, I never use goto either.

Even if you aren't in doubt, consider the mental welfare of the person who has to maintain the code after you, and who will probably put parens in the wrong place.

It is easier to write an incorrect program than understand a correct one.

Procedure names should reflect what they do; function names should reflect what they return

A 'goto' in Perl falls into the category of hard things that should be possible, not easy things that should be easy.

Perl is designed to give you several ways to do anything, so consider picking the most readable one.

Some of these isolated applications that sit on one machine are a million lines of code. How do you deal with that? Most people have no way to wrap their head around it.

If you want your program to be readable, consider supplying the argument.

Syntactic sugar causes cancer of the semicolon.

No one wants one language. There are applications when it's appropriate to write something in C rather than in Java. If you want to write something where performance is much more important than extensibility, then you might want to choose C rather than Java.

Rushing to optimize before the bottlenecks are known may be the only error to have ruined more designs than feature creep. From tortured code to incomprehensible data layouts, the results of obsessing about speed or memory or disk usage at the expense of transparency and simplicity are everywhere. They spawn innumerable bugs and cost millions of man-hours - often, just to get marginal gains in the use of some resource much less expensive than debugging time

Computer languages differ not so much in what they make possible, but in what they make easy.

[Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript.

Perl should remain fast and intuitive (to the extent that it is :-)

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