|« Really, Always Return Something||How To Test Legacy Applications »|
Developers discuss and debate clean code all the time. They even debate what constitutes clean code. The discussion about clean code is as old as languages themselves; entire languages (I’m looking at you, Python) have been written around the philosophy of easily readable code.
But why should you care about writing clean code? What does it matter? Especially if you work on a small one or two person team, why should you care about clean code?
At it’s most basic, code is transformed from the letters you write and routines you invent into 1’s and 0’s that the computer processes in a particular order to get a response.
The computer doesn’t honestly care whether or not the code is beautiful. It doesn’t care whether or not you wrote every expression on its own line, what your indentation strategy was, or whether or not you put all the code on a single line (assuming, of course, you’re not using a whitespace-sensitive language).
The computer only cares that the code compiles, and can be executed. Pass this check, and the code will run. Fail this check, and the code won’t run. Period.
So if the computer doesn’t care, why should you?
The answer is that code is written to communicate ideas in a human readable form.
If you didn’t care about the expression of ideas, you could simply write code in 1’s and 0’s for the processor to handle. After all, this is what code will end up being in the end.
But languages are designed to express ideas as much as they’re designed to instruct computers. Language features are added because they make it easier to express certain ideas. Entire languages have been developed with the purpose of handing a particular set of problems. Many if not most languages are implemented using another language (PHP is written in C, for example). Developers could write in C, but PHP allows them to express themselves in a new and different way from C.
Since our goal in writing code is to communicate ideas to other humans (not to computers), it is imperative that we write that code clearly and cleanly.
Writing clean code can take many lessons from writing documents or books.
Developers often edit code for clarity, in much the same way that an editor modifies a document for clarity. And developers look for better ways to express their ideas, much like a writer seeks to express their ideas in multiple revisions.
Messy code, though it may work, fails at communicating the ideas of the author as well as clean, clear, organized code. Sure, variable names like $a and $i might hold values, but descriptive names like $databaseObject and $iterator are much clearer and articulate a far better point.
The purpose of writing clear and clean code is really about your pride in authorship. Since your code communicates your thoughts to another developer, and to the rest of the world, it’s crucial that you do everything you can to make those ideas clear.
When we write poor code, we say that we don’t care. When we write messy code we’re saying that we don’t have pride in what we’re doing.
Writing clean code takes just as much effort as writing a good blog post or a great book. The logical arguments and functionality are the plot and cohesiveness of your program.
Take pride in your work. Clean code is important!
In two weeks time I’ll be opening preorders for my latest book, The Ten Commandments of Code. Sign up below to receive updates and special offers on the book!
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."
Foo wrote at 3/19/2013 7:22 am:
I am not sure I agree with “pride of authorship”. Pride is a vice. Pride is about ego. Egoless programming is a virtue.
Havvy wrote at 3/19/2013 8:38 am:
Use $database not $databaseObject…
Marcin wrote at 3/19/2013 8:43 am:
This article looks like it is only to generate traffic to get that book sold. Correct me if I’m wrong but sentences such as “Since our goal in writing code is to communicate ideas to other humans” are completely of out the blue. Since when writing code is to communicate ideas to other people?
Writing code is solving problems. Period.
Brandon Savage (@brandonsavage) wrote at 3/19/2013 2:08 pm:
@Foo, pride in this case is the sense of a job well done and a stake in the outcome. Pride that results in ego is not the same as pride of doing well.
@Marcin You are wrong. Here’s why: if code was just for solving a technical problem, then Brainfuck would be as useful as Python. Since nobody uses Brainfuck in a legitimate way, semantics of a language must matter. As does how you write that language.
With regards to your assertion of my less-than-altrusitic motive, nobody does anything without a reason. I’ve been working on this book for months. I want to share what I’ve learned with the world. Sure, I’ll make money doing it. But if I wanted to make tons of money I wouldn’t have taken up writing.
Bar wrote at 3/19/2013 2:43 pm:
> @Marcin You are wrong. Here’s why: if code was just for solving a technical problem, then Brainfuck would be as useful as Python.
Yeah because Brainfuck is such a great tool to solve problems.
This is the same as saying. You are wrong. Here’s why: if an engine is for driving a machine, then my car engine would be as useful as an airplane engine to drive an airplane.
Robert Kaiser wrote at 3/19/2013 4:31 pm:
Just as a note, for me reason #1 for writing clean code is that I myself just might need to extend or fix something in this code long enough in the future that I won’t remember how everything worked, and then I need to find my ways to do the right thing there. Fortunately, the effort to make things understandable for myself a few months/years down the road is pretty much exactly the same as making the same things understandable for complete strangers. :)
Bobby Kotadinov (@BobbyKostadinov) wrote at 3/20/2013 9:07 am:
I attended your talk last year in php london conference and back then, and reading the comments now I get the feeling some people finding the “art” of clean and expressive code too bothersome and too airy.
However I agree with your opinions 100%. In my personal experience, working on LONG term, continuous project, clean code makes the difference between a working application and a total mess that is half the time killing apache.
My main goal, for my team, is to force each developer to write a standardized clean code. I insist on this more than I would insist on specific code architecture. I have found through experience that brilliant ideas get bogged down in messy, long code and at the end become a burden to maintain.
If you write a class and the effort to keep things clean is too much, imagine working on a system with 100000 files and having to introduce new developers to that is just…
it actually costs money, it creates downtime, creates logical errors due to developers not understanding the business in the code and doubles the development time needed.
So keep advocating clean code! :)
Devon H. O'Dell (@dhobsd) wrote at 3/21/2013 5:11 pm:
> The computer doesn’t care about clean code
> The computer only cares that the code compiles, and can be executed. Pass this check, and the code will run. Fail this check, and the code won’t run. Period.
Except if “beauty” is part of the syntax of the language. And arguably, it is. Otherwise, Python wouldn’t make whitespace important, and utilities like gofmt wouldn’t exist. LISP also comes to mind.
> The answer is that code is written to communicate ideas in a human readable form.
Code is written to automate tasks through an interpreting agent (like a computer).
> But languages are designed to express ideas as much as they’re designed to instruct computers. Language features are added because they make it easier to express certain ideas. Entire languages have been developed with the purpose of handing a particular set of problems. Many if not most languages are implemented using another language (PHP is written in C, for example). Developers could write in C, but PHP allows them to express themselves in a new and different way from C.
PHP is a very C-like language. Its syntax is based on C’s syntax. PHP doesn’t allow “new and different” means of expression in its language at all. I can honestly not think of a single original feature of PHP that is part of the language itself — fundamentally the only differences between C and PHP as a language are classes. In which case I would point at C++ and Java, both of which have a C-like syntax.
I think you might be talking about the availability of libraries and the ease of use that comes about from having an expansive standard library. C is not great for web programming, but that is neither “language feature” nor “misfeature.” PHP, on the other hand, is terrible for anything that needs concurrency, threading, or real-time guarantees. It just doesn’t work. In the case of PHP, this isn’t really a language misfeature either, the interpreter and runtime are simply not written in a way that makes these sorts of things viable.
Languages are designed to help people solve problems relating to automating computers.
> Since our goal in writing code is to communicate ideas to other humans (not to computers), it is imperative that we write that code clearly and cleanly.
If this was the case, I’d never have to write architectural or technical design documents. If you want to write literate code, do so — you may be interested in learning more about literate programming (http://www-cs-faculty.stanford.edu/~uno/lp.html) and a PHP implementation (https://github.com/bergie/noweb.php). People who love literate programming may disagree, but I think this is a mostly failed experiment. Many engineers I know (myself included) are nowhere near as literate as Knuth.
Either way, I think you’re fundamentally wrong. Writing code is about automation. Writing documentation is about communicating ideas. There are methods (linked above) that combine these. Very few people do it, and (in my experience) it is mostly done in academic implementations of algorithms.
> Messy code, though it may work, fails at communicating the ideas of the author as well as clean, clear, organized code. Sure, variable names like $a and $i might hold values, but descriptive names like $databaseObject and $iterator are much clearer and articulate a far better point.
I disagree *very* much, and so does Rob Pike. He makes a much better case than I could at http://doc.cat-v.org/bell_labs/pikestyle
> Clean code is about pride of authorship
Broken clean code is worse than working spaghetti code.
Hikari wrote at 4/11/2013 4:05 pm:
Lol I loved the melogic way you expressed it! Write clean code to be pride of it when others read it!
I’d like to go further, talking to a more professional audience. Clean code means maintainability. Easier, faster and more reliable changes in future.
When the objective is to understand the software, reading its code isn’t good. Software must be documented and modeled, to make it real easy and quick to understand.
Then we go to Software Architecture, and create great, versatible and modular architectures, that allow loose coupled components to be reused and maintained separately.
|« Really, Always Return Something||How To Test Legacy Applications »|