Code Efficiency Quotes

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Premature optimization is the root of all evil.

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

We flew down weekly to meet with IBM, but they thought the way to measure software was the amount of code we wrote, when really the better the software, the fewer lines of code.

It's hard to tune heavily tuned code.

Get the weirdnesses into the data where you can manipulate them easily, and the regularity into the code because regular code is a lot easier to work with

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

In this respect a program is like a poem: you cannot write a poem without writing it. Yet people talk about programming as if it were a production process and measure "programmer productivity" in terms of "number of lines of code produced". In so doing they book that number on the wrong side of the ledger: we should always refer to "the number of lines of code spent".

I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say Yeah it works but you're leaking memory everywhere. Perhaps we should fix that. I'll just restart Apache every 10 requests.

I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language.

The three chief virtues of a programmer are: Laziness, Impatience and Hubris.

If we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent."

Programs today get very fat; the enhancements tend to slow the program down because people put in special checks. When they want to add some feature, they’ll just stick in these checks without thinking about how they might slow the thing down.

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.

C is a razor-sharp tool, with which one can create an elegant and efficient program or a bloody mess.

What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?

Even for the very best programmers ah, sometimes you'll see someone else's program or somebody will come along and they'll show you what can be done in a simpler way.

It would be possible to optimize some forms of goto, but I haven't bothered.

Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is

Programmers can be lazy.

PHP is rarely the bottleneck.

Trivia rarely affect efficiency. Are all the machinations worth it, when their primary effect is to make the code less readable?

Trying to outsmart a compiler defeats much of the purpose of using one.

I think people don't realise that running a piece of code that verifies some conditions for a financial transaction, that by itself is a lot less work than verifying a cryptographic signature, and so even if the virtual machine is inefficient, the cryptographic signature is still going to dominate.