Slashdot Mirror
Where Can I Find Beautiful Code?
eGabriel writes "One of the benefits of free software that I haven't seen explored here is that of the opportunity to study elegant, masterful code. Besides the fact that we can all share and enjoy applications, and reuse their source code, we can also simply download the code and view it for pleasure, to learn from masters of the art. Certainly there are different criteria for determining what makes a piece of code excellent or beautiful, and I am not as interested in discussing that. If however, anyone has found a piece of free software that serves as an excellent example for study because of qualities they as programmers hold dear, I would love to read that code also and be educated thereby. Equally interesting would be code that really is bad, as long as it didn't turn into direct attacks upon the programmers involved (they can't all be gems!) Any code that shows elegant and masterful design would make for excellent reading; the language in which it is written isn't as much a concern. 'Literate' code is a bonus."
I'm far away from being a linux zealot, but an real good example (IMO, YMMV etc.) is reading linux-kernel. ;-)).
... well the implementor on HP-UX himself and a very interesting discussion began.
L.T. and the other kernel hackers sometimes get into very interesting discussions. Lately there was a discussion where L.T. called the HP-UX sendfile implementation obviously stupid (and BSD's too, yeah, roll on
One of the people who answered was
So, leeching on mailing lists might help - and if you're not into low-level os programming I'm sure you'll find a open source project which covers areas interesting to you (unless you're doing ERP applications or such stuff).
--
"There is so much to be said in favor of modern journalism. By giving us the opinions of the uneducated it keeps us in touch with ignorance of the community."
Oscar Wilde (1854-1900)
Especially if the algorithm is particularly clever, it can be relying on some subtlety that will be entirely missed without a good long comment. Modifying such code is dangerous.
One of the reasons people like Knuth's approach so much is that he puts the comments first, conceptually. The code is essentially embedded in a great long comment that describes everything that's happening. The code is just there to distill the essence of the algorithm into a form a stupid machine can understand. If the machines were a bit smarter, they would be able to run the program by reading the comments and executing them!
Code with no comments is not a sign that the author understands his code so well that he doesn't need them. It is a sign that the programmer is lazy, sloppy, and doesn't care whether or not his code is maintainable. I just can't emphasize this point enough: for Open Source projects commenting is even more important than code. A large faceless company can get away with releasing products built on hundreds of thousands of lines of uncommented code, because they have external documentation, and can afford to spend thousands of dollars training new programmers. But if you want other people to even look at your code, you have to help them understand it. People making patches to code they don't fully grok are just going to make a mess.
Good commenting style is as difficult to develop as good coding practices (the two really go hand in hand). Mental discipline (did you ever say to yourself "I'll go back and comment it later"? Did you?), clear exposition of an algorithm (no, the code is not a clear exposition -- remember code is CODE, it's meant for a stupid machine, not an intelligent human), maintainability, etc. Comments should be written in complete sentences wherever possible. Don't comment like this:
Rather, write them like this:Not everybody uses the same tools you do. Comments should be as easy to change as possible. If they aren't, people won't do it, and the comments can get out of synch with the code, which is even worse than no comment at all.
Languages without block quotes are very irritating in this respect.
So don't look for beautiful CODE, look for well written prose comments. THAT program will be more stable, easier to use, more functional, and a joy to work on.
Jargon file says it best:
TeX has also been a noteworthy example of free, shared, but high-quality software. Knuth offers a monetary awards to anyone who found and reported bugs dating from before the 1989 code freeze; as the years wore on and the few remaining bugs were fixed (and new ones even harder to find), the bribe went up. Though well-written, TeX is so large (and so full of cutting edge technique) that it is said to have unearthed at least one bug in every Pascal system it has been compiled with.
For all of those who haven't read it, or want to again, this is a good story about cool code, and a cool coder.
This is the Google search I found it with.
The real Eight Star misses Technocrat.
lsmvcprm.com, Tools for geek power
I didn't really know how to program, I knew a little FORTRAN, C and Basic from doing data analysis during summer jobs, and I didn't really like it all that much. I used to really have to struggle to spend several weeks writing a 500 line program, and I'm sure I'd be embarrassed if I had to look at the source code to those programs today.
I figured I'd program for a while because it paid the rent (I was making $20k a year doing Sun administration and writing image processing software), but when I figured out what I really wanted to do for a living I'd quit programming and get a real job.
That was in 1988. Then some consultant visited and installed GNU Emacs on our machines (two Sun 3/160's, one diskless, both with terminals and no workstation monitor, but with frame grabber cards and NTSC color monitors). He explained about the GNU manifesto.
I thought it was pretty cool but didn't see it affecting me personally in a big way. I was mostly annoyed that I had to wait up while the consultant installed the software on what was supposed to be my day off while a ladyfriend was visiting from away.
Then my friend Jeff Keller, who went to MIT for a while and vaguely knew Richard Stallman, spent an evening with me singing the praises of Emacs. What I really wanted was VI with macros you could program to include conditional branches, and he said it had all though and much much more.
So I learned to actually use Emacs, and soon learned that it was quite extensible, but it wasn't made too clear how to extend it. The online manual was useful mainly to people who already knew what they were doing.
So I read the source code. One thing I was interested in doing was writing C functions that were callable from Emacs lisp as lisp functions. There are many such functions built into Emacs (usually for performance) and you can add your own. There's this big DEFUN macro that even makes the C API look like Lisp.
I learned that and a lot more. I learned what an eloquent statement of software architecture Emacs is.
I learned that there really was something worth my while doing in the way of software.
I wanted to write a program like that someday. Not another big editor, but a program that would someday strike other young programmers the way Emacs struck me.
During the course of reading the source code, one day I stayed at my terminal 24 hours straight, arising only to get coffee and use the restroom, not even eating. I only realized how much time had passed when I started to fall asleep.
That was when I started to take programming seriously. I began to put serious effort into studying programming, and studying it deeply.
For example I would read Knuth's The Art of Computer Programming on the bus on the way to work and I would stay up all night after work learning to program better on my Macintosh at home.
For many years I selected all of my jobs based mainly on what I could learn from them.
I've become a very skilled programmer. You can see this from my consulting business website, my resume (on my resume the place where I first encountered Emacs is the Programmer job at Verde Technologies) and my programming tips pages.
So in a very direct and profound way I owe it all to Richard Stallman and Emacs.
I still haven't written my great program yet. I don't even know what it will be. One project I've worked on peripherally is the ZooLib cross-platform application framework and a project I've just started up but not gotten too far with yet is the Linux Quality Database.
I did finally get my B.A. in Physics, from UC Santa Cruz, but only after being out of school working at a programmer for a number of years.
Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
I think the question can really only be answered to applying it to a particular task.
There are almost always good solutions to a certain task that can be considered good.
Next thing that must be done is to define "Good Code". I'm sure everyone has their own opinion as to what good code is;
Readable, Well Commented, Efficient Algorithm, Proper Naming Conventions, Follows Appropriate Documented methods, etc...etc...
I'm sure there are hundreds others!
Perhaps a question like "What defines good code" would still be only slightly more beneficial to those reading the posts.
The source code to id software's doom and quake is the nicest real-world code that I have seen. Knuth's TeX, especially in book form, is also worthwhile.