FYI— just realized that I had not enabled comments for the following post, and there I was wondering why no one had commented on it for a chance to win a free book. Because of that, I’ll extend the following contest, in which I choose a winner in a totally arbitrary fashion, until next the end of next Tuesday, March 25. Feel free to post your comments to the original post or here.
Here are the details:
Michael R. Bernstein wrote to let me know that I had neglected to announce the winner of the free copy of Ajax: The Definitive Guide that I offered in my post What’s in a Definitive Guide?” This was quite a coincidence (assuming you believe in coincidence) because Michael, himself, was the winner we arbitrarily chose. Congratulations, Michael and thank you for posting your insightful comments.
For the next book contest, I’m giving away a copy of the Jolt Award winning Beautiful Code. Just post a comment about the subject: what makes code beautiful to you? What makes it ugly? Can code be beautiful? Write whatever you like on the subject, post your comment before Friday, March 21, and I will arbitrarily select a winner from the posts. The odds of winning are great—just ask Michael!
Atom 1.0
Beautiful Code is code that works flawlessly, is readable, and succinct.
My idea of Beautiful Code involves getting a sheet of paper with the source code on it and I can understand the methods and functions on it without any dead-ends, ambiguities or confusing directions.
By the way, I HATE "single letter" variables, like "int x;" What is X? How about "salesTotal" or something apropos? That's ugly, not elegant.
One of my all time favorite books about programming is the classic Programmers at Work. From what I have followed on the Beautiful Code blog, it seems to be a good successor.
When I think of beautiful code, I think of code that accomplishes some difficult or complex class and actually informs the reader about the underlying principles that are being tackled by the code. I remember reading some algorithms for finding least common multiples in college that (while not overly difficult) helped me gain a better understanding of the mathematical relationships in the core problem.
I saw a post online recently by someone creating an anagram program that searched for boy and girl names that were anagrams of each other. The resulting discussion was full of examples of beautiful and novel approaches to tackling that particular problem.
I like really small amounts of code that do a lot of work. I don't mind single characters if it's something like "while ($x>7)" and $x is just a counter.
Readability is great but there's something pretty "beautiful" about a Perl one-liner, too. (And they are often kinda hard to read at first glance).
Good code allows you to understand itself. Beautiful code makes you WANT to understand it, and then go on and use its ideas yourself.
Good code tells you clearly what it does. Beautiful code fires your imagination, and makes you want to use the possibilities that you see.
Good code tells you something. Beautiful code teaches you something, and makes you want to learn more.
Good code ends in a period. Beautiful code doesn't need to end...
Beautiful code (and beautiful XML structure) has a personality and a rhythm like good music. Using consistency in variable names and naming conventions are the most important step, IMHO.
Beautiful code fits in my head.
Beautiful code is layered, and comprehensible at multiple levels of abstraction.
Beautiful code minimizes the need for abrupt mental context switches.
Beautiful code encapsulates an 'Aha!' moment.
Beautiful code is haiku-like.
Beautiful code is working code.
In my opinion Beautiful Code is written to be read, not to be processor efficient, and is commented to the point that supporting documentation is *nearly* unneccessary. I learned to code in BASIC on TRS-80, progrssed through Pascal, C, 370 Assembler, and mainframe COBOL, and my bias is towards:
- meaningful variable and function names
- single letters are OK if their scope is very limited
- Text comment blocks are required for anything complex
- descriptions of use when variables declared
- comment on issues that force odd processing requirements
Oh, and it should be printed on 14 7/8" green bar paper with a fixed monospace font, maybe something like Times Courier...