Allow me to make a generalization and ask a question at the same time. When you write your code, do you write it for yourself, or for someone who might use the code? Do you try to make your code as clever as possible, or as simple as possible?
At YAPC::NA 2008, Schwern had a great talk on skimmable code. Simple code frees up the programmer's cognitive resources to concentrate on the business logic, not on reading the code. One could argue "well, you're just not smart enough to understand my code". That's a valid answer, but it is more likely that I don't have the time to spend deciphering your code. I believe that I'm a reasonably intelligent person. But also a busy person, and it's rare enough that I get the time to write my own code and focus.
I'm starting to believe more and more that writing simple code is hard, and writing complex code is easy. Simple code is easy for your users to read, and it is easy for you to read as well. Most often, we are the biggest users of our own code. Damian had a nice anecdote in PBP about watching out for the person who has to look at your code six months after it has been touched. Most often, that user is you, so be kind to yourself and code for the inner user in you!
-- attributed to Blaise Pascal
Re:Didn't have time...
Eric Wilhelm on 2008-06-29T18:09:08
Exactly. The quickest way to make a change tends to create "smart looking" code, but it makes it harder to make the next change because you end up with something like 4 elsif clauses where each one has 5 boolean statements and half of the booleans are negated. So, every change requires the programmer to decipher all of the conditionals and their constituent booleans, probably with zero comments.
Grouping the conditions into a dispatch table would make it fairly self-documenting and allow room for comments about what business rule is tied to which condition. That would be "smart" code, but extremely readable compared to the alternatives. So, simplistic coding yields complicated code and sophisticated coding yields simple code.
The first one is to try to code things in a straightforward way that anyone can understand. That means laying things out clearly, using a widely understood group of features, etc.
The second one is that if I break the first rule, break it hard. If I really need to be really tricky, get all of the trickiness out of the way in one place. If I need to use an advanced feature like overloading, use it a lot so that anyone who has to work with the project will quickly be clued in that it is going on and how it works.
Following those two rules works pretty well. Particularly if I'm the user who has to read the code 6 months later. (Which is usually the case for me these days. I don't think that anyone has read more than 20 lines of the Perl that I've been written in the last year...)
Eric Wilhelm::Pascal = btilly::Einstein
mr_bean on 2008-06-30T01:58:09
Is this what Einstein meant when he said:
Make everything as simple as possible, but not simpler?
How is it possible to make something simpler than is possible?
Re:Eric Wilhelm::Pascal = btilly::Einstein
chromatic on 2008-07-08T20:04:10
How is it possible to make something simpler than is possible?
Everything is an object, in Java, even if you don't need it to be an object, in which case it's either a primitive (for efficiency), or namespaced global functions (a class full of static methods) -- but everything is an object in Java, because that makes everything easy.
