Crockford on Quality and Style

Some of the best few paragraphs on codebase quality and style I have read in a long time:

Computer programs are the most complex things that humans make. Programs are made up of a huge number of parts, expressed as functions, statements, and expressions that are arranged in sequences that must be virtually free of error. The runtime behavior has little resemblance to the program that implements it. Software is usually expected to be modified over the course of its productive life. The process of converting one correct program into a different correct program is extremely challenging.

Good programs have a structure that anticipates — but is not overly burdened by — the possible modifications that will be required in the future. Good programs also have a clear presentation. If a program is expressed well, then we have the best chance of being able to understand it so that it can be successfully modified or repaired.

The long-term value of software to an organization is in direct proportion to the quality of the codebase. Over its lifetime, a program will be handled by many pairs of hands and eyes. If a program is able to clearly communicate its structure and characteristics, it is less likely to break when it is modified in the never-too-distant future.

From JavaScript: The Good Parts (chapter 9, “Style”) by Douglas Crockford.

Are you stuck with a legacy PHP application? You might like my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.
Share This!Share on Google+Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedIn

2 thoughts on “Crockford on Quality and Style

  1. I’ve come around with this, and I disagree with the last paragraph. I think there is one thing that is more important than a program which “is able to clearly communicate its structure and characteristics”: test coverage. The reasoning is that no refactoring can ever be done if the changes cannot be proven correct and that no regressions have been introduced.

    He also says that such code “is less likely to break when it is modified in the never-too-distant future”. The question is not whether code “is less likely to break”; it will break! And the tests will tell you this. The only thing worse than buggy code is buggy code that no one knows about.

    The four rules of Simple Design, given in the order of importance:

    1. Passes all tests
    2. Minimizes duplication
    3. Maximizes clarity
    4. Has fewer elements

Leave a Reply

Your email address will not be published. Required fields are marked *