I'm not trying to knock the book beautiful code, but commenting on
that list by codebyter from the book, i thought it conveyed the wrong focus. It's focused much too much on brevity, and much too little on explanatory power.
One should not write source code like one writes poetry and literature. One should write source code as if writing a textbook -- focusing on explanatory power and clarity.
I guess i can sum up my view like this:
- One should endeavor to write code which is most of all: clear and easy to read and understand.
- I think one is almost always better spending 20 lines writing something in a way that is crystal clear, than accomplishing the same thing in 2 lines of code that requires careful study. The more "clever" those 2 lines of code are, the worse.
- Writing code is different from poetry and literature in that the goal should not be cleverness and coming up with some surprising and unusually short snippet of code that accomplishes something.
- Even in those very rare rare cases where the longer, clearer code uses more memory or takes more cpu cycles, and in which that speed/cpu difference actually impacts usability (truly rare cases), i still believe it's best to write it the clear way first, then come back and refactor later for efficiency if you must.
Or you might even be able to sum it up by saying:
Write code as if you're goal was to produce something that was self-explanatory, that could teach a new maintainer how the system works and make it as easy as possible for them to take over from you. And note that the primary motivation for doing this is *not* because you might have to turn over control of the code at some point, but that this approach makes it easier for *you* to maintain the code going forward and makes it easier for you to debug, which is what you're going to be spending most of your time doing whether you like it or not.
Recent Posts
