Larry Wall 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.

The mark of a mature programmer is willingness to throw out code you spent time on when you realize it's pointless.

Good code is its own best documentation.

Often in writing programs, articulation and clarity are more important than what you actually say.

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

Don't document bad code - rewrite it.

If there is a bug in your code than you have to drop everything you're doing and go fix it.

Certainly not every good program is object-oriented, and not every object-oriented program is good.

Adding functionality is not just a matter of adding code.

We have a rule that if you check in code, you have to maintain it. So I mostly code on the side. I don't check in code anymore.

Content zips around the Internet thanks to code - programming code. And code is subject to intellectual property laws.

Don't hurry your code. Make sure it works well and is well designed. Don't worry about timing.

Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis.

I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

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.

When you program, you want to think you're writing the best possible program for the... for the task you're trying to solve.

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

We’re no longer in the days where every program is super well crafted. But at the heart of the programs that make it to the top, you’ll find that the key internal code was done by a few people who really knew what they were doing.

I used to be enamored of object-oriented programming. I'm now finding myself leaning toward believing that it is a plot designed to destroy joy.

"Legacy code" often differs from its suggested alternative by actually working and scaling.

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

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

More good code has been written in languages denounced as "bad'' than in languages proclaimed "wonderful'' - much more.

Syntactic sugar causes cancer of the semicolon.