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."
Check out
For example, ever wonder how ping(8) works?
$ cd
$ ls
Makefile ping.8 ping.c
Tsk tsk. You forgot the "return(0);". And you didn't indent. AND you didn't check the return value of printf() (forgiveable, everyone forgets that). Is this what beauty's about? That particular snippet is ugly enough to warrent a warning in most compilers, but slashdot seems to think its worth a +1...
Windows98SE is the *BEST* code which I've had the privilege to view. Superb. It's unfortunate that Bill Gates won't release it for all to see, because it would put *everything* else to shame. When it comes to quality, Windows98SE wrote the book! One of the perks of working for Microsoft has been the honor of being allowed to touch this cyber-magic known as Windows98SE source code.
Try anything written by Knuth...
You gotta be kidding. This is _exactly_ what fucking useless ugly code looks like. Its a terrible misuse of the C preprocessor that buys you nothing in form, fucntion or clarity. When I read a C file I want to see the C language, not some l33t redefinition of its basic looping constructs. And why call it a loop abstraction? Do you call
#define unless(a) if(!(a))
an if abstraction, too?
If there really is crap like that in the Linux kernel (cant say it would surprise me given what a pos Linux has become) then the linux kernel desperately needs some guidelines.
You write shit like that for a living and you starve.
I was surprised that, just 5 minutes after reading freeciv code, I could find what I was looking for. Consider I hadn't programmed C forg the past 3 years. www.freeciv.org It's a masterpiece in my humble opinion.
Afore the other side ye'll see!
WHAT is your name?"
"Anonymous Coward."
"WHAT is your quest?"
"I seek the holy grail of beautiful code."
"WHAT is your favourite code design methodology?"
"Top-down. NO! Object-oriented! AIEEEEE.....!"
god damn it!
Ok, yea, right there in the hex, you should put a few lines like
# function for generating the card to be delt to the user from the computer.
Ok, so with compiler coding (post-Mel), you could do this, and that useless ascii would total maybe half a kilobyte, maybe one. In olden days that was a gabillion dollars!!
Arogent people who bash those before them with their 20/20 hind sight piss the shit out of me.
Mel wrote the fastest and most optimal program possible, hands down. That's not a negotiable fact. He went the extra mile(s) to get get it working the fastest, at which point, it became a work of art. Since Mel, things have changed, and now greener pa$ture$ rule the world. That wasn't the case back then, when conserving resources was everything. Why do you think we had y2k? Because it was that damn important to save resources. That was the real cost.
Anyone who calls Mel's code Spaghetti code should go to hell. Mel was an artist. That's like saying that frank lloyd wright's blueprints where scribble, because his buildings couldn't go through a tornado. Mel was an architect in a world of engineers. To quote RENT, "take him for what he is". Damnit, that really really pissed me off.
Excellent point!
/proc/*. Browsing through the wmsysmon code I found that (to my surprise) there is a sysinfo() call that can give me that exact information... suddenly my code is made simpler, more elegant, and more readable, as well as more bugfree thanks to one line in an obscure little applet (well, maybe not *that* obscure :).
That's something that no one has mentioned yet (that I've seen). ANY code you see can be beautiful code! A couple of months ago I got thrown back into coding C at work after being in perl for a couple of years. It went well, but I *knew* my code wasn't all that great. It worked, was readable, and relatively bug-free. But I still knew it needed some work. I read a couple of books (Programming Style or something like that?), and looked over a bunch of code that I was available. Everything from smail source to code from newsgroups.
I learnt little bits from all these sources. A chunk of code can be bug free and crappy, but still give you good insight into how to code better. For example, I had a great routine for getting system mem/cpu info from
If the code for these programs wasn't open source, we'd have nowhere to look. There would be code around, but having a huge array of applications to look at and scoure through, makes everyone's code better.
Yes, but none of those concepts are programming concepts.
MAC | A polar bear is a cartesian bear after a coordinate transform.
MAC | A polar bear is a cartesian bear after a coordinate transform.
In other words, this application should prove to be an excellent programming how-to reference for wannabe hackers. Also, pay attention to the bibliography on coldsync's web site; there's some damn good stuff there.
(Yes, that's right: an application with a bibliography. How cool is that?)
MAC | A polar bear is a cartesian bear after a coordinate transform.
MAC | A polar bear is a cartesian bear after a coordinate transform.
I see that nobody has mentioned the BSD source trees yet. All the BSDs (and NetBSD in particular) have some of the cleanest, simplest source code I have seen (barring /usr/src/contrib/, which is imported).
/ src
It may not be earth shattering stuff, but every time I have needed to modify the source code to FreeBSD, it has been a delight to see how good the code is.
Check out an unpacked source tree at ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current
-Dom
I don't believe too many have mentioned the beauty of the Smalltalk class library. It was carefully crafted over many years and I don't believe there's any method with over 15 lines of code (except for the bit-blitting classes).
Take a look at one of the non-commerical versions of VisualWorks, or even Squeak (an open source variant). It's quite impressive, and teaches one a lot about good object orientation.
-Stu
I think the point is that English is a very poor language to express precision and C is a very poor language to express "gestalt" or big picture issues.
// set x to 1
For this reason, I think purpose statements and algorithm "walkalong" comments are crucial.
I think what I do feel is that I don't like useless contextual comments that either
a) state the obvious,
x = 1
or
b) tell me something WITHOUT rationale or explanation.
/* passing in null may cause problems */
calculatePricingContext(quoteContext, null);
Which is what 80% of commenting tends to be.
-Stu
Better yet, make the comments flow with the code:
/* ok, finished with the current line, so we */
linecounter++;
The best comments describe why, not what. And if you leave the code as part of the sentence, then it becomes far more jarring when the code is changed, adding an additional incentive to keep the comments up-to-date.
I remember when I asked a similar question a few years ago. It might be informative to take a gander at it. -David
...ya know, it just seems like a really bad "Revenge of the Nerds" joke in disguise....
;)
--aarOn
"...we dont care about the economics; we just want to be able to hack great stuff."
You seem to think that there's some nessecary relation to programming and graphic design because they're both expressed on computers...
--
Some code features: automatic downloading and installation of plugins, two download techniques, web content fetching and munging, FTP of output files, logfiles, version safety, OO mixed with imperative style, a meager design document, Perl, modules, about 6000 lines of code, good comments, caching.
-----------------------------------------------
A few years back I wanted to add some functionality to the fvwm95 task bar as well as fix a couple of bugs. I'd never looked at any window manager code before and had no idea how modules would work and communicate.
I quickly found it concise, elegant and above all logical, I was able to make my changes incredibly quickly and added a few more things I rather fancied just because it was all so clear.
So congrats to the multitude who work(ed) on these projects and thanks, even though I no longer use the fvwm line of managers.
Regards
(Where is the boundary between medium-sized and large programs, anyway? Python is roughly 150,000 lines of code, though over half of that is in the various extensions that come with the source distribution; the core interpreter itself is around 60,000 lines.)
though I believe you shouldn't comment every single function you create, if they are obvious, because it dilutes the value of the REAL valuable comments that explain difficult-to-understand sections.
Agreed. I've seen comments so brain-dead it made the code HARDER to understand than if it weren't commented at all. But maybe one should still include comments of the form "I didn't comment this, it's obvious" so whoever reads the code doesn't think you got lazy?
~ radiographite: art by john shepard
You seem to think that there's some nessecary relation to programming and graphic design because they're both expressed on computers...
:-)
Well, we are talking about beauty, no?
~ radiographite: art by john shepard
Check out GNU libavl for some good binary tree structure code. The stable version is well written C; the development version is a literate program. (Note: I am the author.)
noah
I don't know where in my post you find any reference to debuggers that hold your hand or some kind of context sensitive help system or whatever. I sure never mentioned that. I'm just saying that Mel was a bad programmer because his code was unnecessarily obfuscated and completely inflexible. It has nothing to do with what tools he did or did not use. Obfuscated, inflexible code can be written with the latest GUI IDE. It doesn't take an old timer with a hex editor, and any hack value it has is quickly lost when you're the one tasked with figuring out why the code won't work after upgrading the system.
noah
I'm not quite sure about that. Konqueror isn't even close to being stable, ditto Mozilla. If you're looking for how to pull off a lot of complicated things, they would be the place to go. If you are looking for actual elegance and educational value, to say nothing of things that actually work, there are better places to look. For example, Scheme is a very simple language through which a lot of high-level, fascinating concepts can be demonstrated quite easily. I find some of the more intricate parts of Abelson & Sussman's SICP more enlightening than chugging through 10,000 lines of Konqueror, but to each his own...
--
I think there is a world market for maybe five personal web logs.
Donald Knuth's Tex certainly qualifies. Not only was it written, from the ground up, by arguably the greatest computer scientist of our time, but it's so good that it's bug free. Literally, there are no bugs in it. Stop and think about what that means for a minute. Can you come up with any software program on the planet of equal size and complexity (several megs of source code - not huge, but still formidable) that can make that claim? I can't. Granted, I may be incorrect, but nevertheless I find that amazing. You can view the parts of Tex that Knuth actually wrote here. They're written in (I think) CWEB, which is some literate programming language he has a real hard-on for. That probably means it fscking rules all, but personally I don't have the time/patience to pick it up. If you're sufficiently motivated, though, I'd imagine the Tex sources would prove very enlightening.
--
I think there is a world market for maybe five personal web logs.
Indeed, it was this book that got me thinking
about beautiful code again.
That's a really good idea; codepoetry.net. I was also thinking maybe of a "Peer Review of the Week" type feature, where one can submit an excerpt from their current project and people can critique it line by line.
In the Perl world, there is Perl Monks; something more ecumenical would be nice though.
Heh, I had seen this one and spent a good deal of time marveling at it, and wondering if it was a good or bad thing :).
I have read his "A Discipline of Programming"... it's interesting, especially now that someone has developed an interpreter for his invented language.
Like functional programming, I can see the beauty, but it's a frustratingly slow read nonetheless. I WANT to believe I can write "provably correct" programs, but I don't suppose that will happen any time soon:)
Certainly there is a lot of code to be found in books. The bibliography at the end of Code Complete is excellent. I guess I am looking more for beautiful production code in the Free Software community.
Ada code can be incredibly beautiful. While I am cranking out Perl somedays I wish 'use strict' enforced the same sort of discipline.
That is an acceptable definition for beauty too. The simple beauty of something that works. There are a lot of wonderful paintings of simple farm scenes. The rusted tractor, a broken wheel, a dilapidated barn, but besides the rustic feel, you get a sense that something honest is happening there; something useful and good, that works harmoniously with the universe.
I think it's unfortunate that this comment got modded down; it's a legitimate question. I wouldn't have put it quite the same way, however.
I guess it's obvious that a lot of people do enjoy reading code. It's part of what computer literacy is; being able to read and write the language.
If you can't read it, or don't want to read it, I don't understand why you'd want to write it. I know some people think of programming as something to do to put food on the table, and their intended audience for the code is the machine itself and the QA department. If you are writing for any reason less than that, I don't see why you bother at all.
I wasn't clear. You and I agree. When I say
"any reason less than that" I am saying that
you should first do it because you want to, because you love it, second because it's your job and you at least take some pride and making it
actually work, but if you are doing it for some
lesser reason than that, why do it.
Best Reason: Love of the art
Second Best: Pride in chosen profession
...
Worst: Don't care about it at all, just want to write it and forget about it.
Jive sucks. Agreed. But, although I haven't looked at the sourcecode for Half-Full (or is it Glasscode?), I must say the user interface is quite unusable. To me, good code isn't just pretty to look at--it also has to be functional, and to function well. Half-full may well meet the first requirement (pretty to look at--although I simply don't know), but it fails miserably with the 2nd requirement.
Slashcode would be an example of very functional code that does *not* look pretty. It's the flip side of the coin.
Sorry to rain on your parade, nebby. But you need to study a little about user interface design.
--Be human.
When I was using TeX, I was using xdvi as well - and that also really impressed me. Simple interface, SUPER snappy response on the gui - no animations, alpha blending, or themes...
Click on that magnify button and zoom the window around... ahh..... does anybody write code like TeX any more?
---
MAN, that's some well-commented code!
Weird commenting style, though -- he documents the hell out of his algorithms and data structures, but doesn't comment his code that much (no mention made of function return values or error conditions raised), and the thing I thought was weirdest -- he has plenty of #ifdef cplusplus statements, but then he goes ahead and uses '//' comments!
Not that my malloc's any great shakes (e-mail for source)...
Just junk food for thought...
In my day job, I'm occasionally charged with the task of writing code that takes our processor architecture to the limit. We're talking every cycle count, codesize is important, and functionality must not be overly compromised. I've been fairly proud of most of my results, and I think they're quite beautiful examples of what can happen when you first design a well-thought-out piece of functionality, and then optimize it to the hilt.
In my application space, this is appropriate. I'm coding for a DSP, and the functions I'm coding are individual DSP processing steps. These are nice, separable functions that some would have us implement directly in silicon. My job is to show them that a programmable processor can do the job.
The following links show some of these "DSP kernels" that I am especially fond of. In my opinion, this code is actually fairly well structured for assembly code. All of the hardware registers have been abstracted behind .asg directives, so that they can be given human-readable names. These names relate back to the C code description of the function (which is also provided in a comment block attached to the code). As an added bonus, comments throughout the code explain the numerous optimizations.
In a different realm, I have a mix of beautiful and ugly code for an entirely different platform. Recently, I've written a Falling Tetrominoes Game for Intellivision named 4-Tris. The assembly code for this game is rather clean and heavily documented. The game actually implements a lightweight task scheduler and then builds the game on top of that as a series of event handlers. Of course, there are some definitely UNbeautiful bits around the edges. There's a Pong game hidden in there that's written as nearly complete line-noise. Also, the song format compiler is an absolute hackish mess.
So, it's safe to say that my code runs the gamut from clean and clear to nearly line-noise.
BTW, for those who are interested, I also have a Monitor Program that I wrote for the 8051/8052 microcontroller. I can't decide if it's ugly or beautiful. The problem here is that the architecture itself is downright ugly, but some of the optimization tricks in the code are either beautiful, insane, or par for the 8051 course. :-) At the very least, I consider it ugly compared to 4-Tris and the DCTs above, so...
--Joe--
Program Intellivision!
Your search for Beautiful code depends on the person reading the code. What is understood by one person is not by another you must look through the source files and look for yourself for Beautiful code
Nah, try this:
msg:
main:
subu sp,sp,4
sw ra,0(sp)
la a0,msg
jal printf
lw ra,0(sp)
addiu sp,sp,4
jr ra
Or, why not this:
msg:
main:
save %sp,-112,%sp
sethi %hi(msg),%o0
or %o0,%lo(msg),%o0
call printf, 0
nop
ret
restore
But my Sparc assembly is a little rusty, so the last one might not be entirely correct.
Well, that wasn't *nothing*.
Er...wait...
NOOP
God, I love Assembly.
Or use /* comments like
* this
*/
plus some .emacs treachery to automatically format your comments for you...
--Rob
I sat here trying to think of some examples for a while, but I can't. I went and looked at some of the code I have on my systems... it isn't.
I sometimes think this is one of the failings of a lot of open source projects... without a good solid core group of people leading the charge you tend to end up with hack atop hack atop hack and various different coding styles and no coherent design. An example of that kind of code is SourceForge.
Now I can think of at least three examples of the opposite... unfortunately they're all proprietary code bases so I can't share them.
In many of the larger projects though you can ocasionally find bits and pieces of pure poetry in code. There's an example in the Linux kernel, I forget exactly where - maybe in the vmm, where someone took the time to fully digest a rather hairy function and they totally rewrote it without changing the inputs, output, or side-effects in a small clean block of code. These are the folks that turely deserve this shirt.
We need a new website, one that can showcase really good code... make it known as the art form it is. codepoet.com and codepoet.org are both already taken by indivuals... perhaps codepoetry.net? make it required reading by cs students, just like trips to art museums are required of art students, and theatre and literature majors are required to study the great works of their fields. Maybe they can sell T-shirts and posters with elegant code on them, and books full of gracefull algorythms.
For irony the site can also link to the obfuscated perl contest.
The Linux kernel source certainly shows some smart, lean code. But it is so lacking of commentary in the source code that it's unbelievable. It seems the whole idea is that if you can't figure out what the kernel does by looking at the C statements, you're not worth working with the source anyway.
This may attract extremely smart people who like to code new stuff, but turns away many other types of people who normally do boring maintenance work, try to fix bugs, use existing code to add a simular feature, etc. etc.
I personally prefer source code that is doesn't hurt the eyes when you look at it a few weeks after the previous time: many comments, empty lines and whitespace inserted to identify logically seperate parts of the code, etc, etc.
Erwin
Sure, it's a bit limited as an OS by todays standards, but architecturally it's neat enough, and small enough and readable enough to be printed in its entirety in the appendix of a book which describes the theory behind it. So you could think of the first half of the Minix book as one enormous meta-comment for the rest of the code, perhaps.
It's nice, clean, traditional C style, too.
From that perspective, the Unix of the Lyons book is pretty readable too.
For something non-C, the source of the SmallEiffel compiler and it's libraries (all in Eiffel of course) is a pretty nice read too. CVSup (in Modula-3) is nice. Read lots of things, in lots of different languages. Some languages seem to lend themselves to clarity of expression a little more than C or C++ do. I don't think I've ever seen C++ code that was beautiful to read.
-- Andrew
It's old-style C code, but in terms of overall structure and organization it's hard to beat the original Bell Labs Unix. Now that the Lions commentary on 6th Edition Unix is generally available (Lions' Commentary on UNIX 6th Edition, with Source Code; ISBN 1-57398-013-7), you can both read the code and Lions' brilliant commentary on it. It's amazing what a few thousand lines of carefully-crafted code can do; most text editors and mail readers are larger than the original Unix kernel.
Don't read this to learn how to program in C -- the language has grown enormously since this time, often in ways that allow for better style and consistency-checking. But do read it to see how to program with a clean, modular design and carefully thought-out organization, and probably learn more about operating systems per unit time spent than you would reading anything else.
The "bugs" are in the design of the interfaces. That's pretty hard to fix w/o breaking the standards.
http://www.tug.org/
Note to moderators: Small, but informative posting
--
Q: What do you get when a Postmodernist joins the Mafia?
HOWTO get better dates on slashdot
Though it's still pretty ugly, and apparently not as elegant, my servlet forum software might interest you.
--
#!/usr/bin/perl -w
print "Hello World\n";
Hey! That's what I do. If you're editor isn't big and bloated enough to reformat block '*' comments like that, then you're using the wrong editor! *grin*
Actually, I have to do it that way because I run the source files through a documentation generator and it needs to comments to be of that form. Besides, it does help set comments apart for people who don't have color syntax highlighting.
Need a Python, C++, Unix, Linux develop
I agree with this pretty strongly. I think code should be good enough to stand on it's own without comments. The best code I've seen has this property, and it's a quality I strive for.
IMHO, comments are best used to describe overarching design issues, or particularily tricky algorithms that, even with well named variables and well structured code, are difficult to understand.
Need a Python, C++, Unix, Linux develop
A month or two ago I could no longer ignore an itch that wanted to be scratched. I've had a few gizmos whose capabilities were only partially supported by the Linux kernel. After two years of waiting for the device driver to be updated, I searched the web until I found the specs that I needed, then just grabbed the kernel tarball, and started poking around.
Now, keep in mind that until then I've never looked at the Linux kernel source in much detail. I have manually compiled it a couple of times, but that was many years ago, in 2.0 days.
Still, after only an afternoon of poking around, I was able to easily figure out what I needed to hack, and how. I came away with a very favorite impression of the kernel's innards. I did not fully understand everything I've seen, but the code was clearly laid out, and there was no doubt that if I really wanted to invest some additional time, I wouldn't have any problems figuring it out.
It's not every day that you can download almost twenty megabytes of compressed source code that you've never seen before, and only a few hours later you are able to figure out how to go about doing what you want to do.
---
Such a good coder, and yet your web site is hideous and unreadable.
Dump the tiled background, those fell out of style years ago, and backgrounds that make the text unreadable were never in style to begin with.
-josh
No, but people who are sloppy in one area tend to be sloppy in others.
And no, not asking for any specific aptitude in graphic design - a pure white background would have been better than that crap web site.
-josh
Actually, this security flaw was fixed quite a while ago.
Do yourself a favor and check out the newer releases (I'm running NeoMail 1.20pre4 and have never had a single problem and has no security flaws that I'm aware of or have heard about...) *grin*
Many have the belief that NeoMail (http://neomail.sourceforge.net) is a project written in Perl which is not only excellently coded and well commented, it is also very efficient.
Sure, but in their efficiency, they gave us the Y2K problem. Last I heard (in January or February 2000), the costs devoted to fixing it may have exceeded £400 billion (~ $580 billion US). Thanks, guys? :)
Cheers,
I did that in a cs class of mine. It was abundandtly obvious. The grader agreed w/ me but I still lost points. Now that I am in the real world I javadoc every function I write. It is obvious to me, obvious to any other programmer... but is it obvious to everyone?
<SIG>
I think I lost my work ethic while surfing the web. If you find it, please email it to crispy@crotch.caltech.edu.
</SIG>
My sig has a broken link in it.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
If you were in his position, how much effort would you want to spend keeping track of which routines were safe in which versions of which OSs -- particularly the closed-source Unix varieties? And if an upgrade to an OS introduces a security flaw in a routine that was previously safe, would you want to drop everything to get out a patch for that OS's users?
In this case, having a whole package of reimplemented routines that you know are safe strikes me as the lesser evil.
--
send all spam to theotherwhitemeat@ropine.com
The best-commented code I have ever seen is Doug Lea's malloc, or dlmalloc, the malloc used in glibc, among other places. I had no idea how a malloc would work, and I wanted to write one for my OS class, so we looked at the dlmalloc source code. MAN, that's some well-commented code! Not only does it explain what individual functions do, but it also explains each general part of the algorithm in excellent detail. And it's malloc; it better not have any bugs!
Do you people *really* have nothing better to do? Does Microsoft really hurt you that much? Do you really think that the world is meant to be perfect and the software industry owes you something? What? Oh, you're thirteen! Of course...
The appallingly bad API that Microsoft provides with their tools is a very good reason to dislike Microsoft. In answer to you question, "did Microsoft hurt me?" Yes they did. Their incredibly poor level of documentation, coupled with an almost complete disregard for decent coding style, and the near constant abuse/redefinition of C++ has cost me more time that I care to consider when trying to do my work. I can accept the occasional use of void pointers when passing data to a function in C++, but having somewhere between 30 and 50 percent of the functions in the API use one or more void arguments is completely unacceptable. The failure to provide decent examples/documentation for MFC is also unacceptable. When I am required to use MS products, that we had to pay a premium price for, I expect the products to be well documented and work correctly. Microsoft's development tools fail to meet both of my expectations, so I would have to concur that Microsoft is not the place to look for good code.
Though I agree that most MS APIs are bad I also understand why they haven't been changed. Why are we still using sprintf instead of snprintf? Compability comes to mind. We are trying to keep source level compability with other UNIXes where MS is trying to keep source level compability with other versions of Windows(TM). In addition to compability problems changes would render current knowledge on MFC etc. completely useless. I'd think that those void pointers are there for historical reasons only.
I would prefer to have to completly relearn the API instead of having to deal with MFC. As best I can tell, MFC is a nasty kludge on top of the WIN32 API, which does go a long towards explaining the abundence of voids. Since a price was already being paid to have C++ wrappers for many functions, it would have made more sense to have the conversions to void done inside the wrappers.
Source level compatibility is a wonderful thing as long as it doesn't actually hinder work. In the case of windows, I think it would be a far better piece of software if teh just made a clean break with the past. Heck, they could provide some form of emulation for compatibilty, it's not that hard.
If you still disagree think about X and xlib. Why are we still using API that doesn't have any support for alpha blending, vector graphics, decent pixmap filtering etc. features supported by hardware in current graphics chips. We don't have even anti-aliased fonts which I myself take for granted in every other OS I use these days.
Let's not even get into X and xLib, just suffice to say X and xLib suck in their own particular ways. My current gripe with X is broken header files that use implicit type declarations, yet another bad practice.
I wouldn't call MS documentation poor. Perhaps they don't give you all the documentation for free, but there good documentation for the areas MS wants the developers to know. Sure there's undocumented features that MS uses in its own software and others follow with reverse engineering. It's MS source and it's up to them what they want to tell about it to developers.
I would call MS documentation poor, particularly when we did pay for it. One fine example is changing the title of a window. It took considerable time to figure out what should have been an easy task. If I pay Microsoft for development tools and documentation, I expect both to be useful. I have found books written by people who claim to have been associated with the design of MFC to be more useful than the docs with MFC. The problem here is that I shouldn't have to line the pockets of someone who couldn't be bothered to do the documentation right the first time.
If you don't like MS APIs or their OS don't support them. Notice that if you don't make programs for their OS you don't need to care about their API quality. What comes to coding style (I assume you mean code formating)... for example I cannot stand GNU coding "standards" - fortunately I have indent.
Not supporting an OS because I don't like it is a luxury I did not have. The customer unfortunatly convinced the boss that MS was the only acceptable platform. Quitting the job was not a viable option.
Coding style refers to more than simplty formatting. It also refers to how language constructs are used. Void pointers exist for compatibility, not for passing the same data type to a function every time. To use void where a specific type can (and should) be used is poor coding style, particularly in C++ since it defeats type checking.
The fact that MS does provide some old ugly APIs doesn't automatically suggest that MS couldn't be perfect source for look for good code. Unfortunately MS seems to keep most of it's code secret. Do you really think that company that hires every top quality coder it can get would generate only bad code?
I didn't claim that the MS programmers like the state of the code. I did however claim that their code does not meet my standards. Regarding your question, I can only make judgements on the code I can see.
Have you guys ever heard the saying "IF YOU DONT LIKE IT, THEN DONT USE IT!"
Nice idea in theory, but almost completely impractical in reality.
People seem to be mentioning the obvious targets: Knuth, BSD etc. but I notice nobody has mentioned Dan Bernstein's projects, notably qmail. This guy basically didn't trust the standard C library routines for security and wrote his own string handling, file processing etc. based on a few system calls. He also splits up his programs into separate binaries as much as possible and is very, very minimalist in other ways too. The code seems quite impenetrable at first, I'm not sure beautiful is the right word, but it's certainly an education.
Also worth a read is Sam Latinga's C++ port of the classic Mac game Maelstrom. The actual code of the game is surprisingly small and very well-written.
Oh, and while I think about it, the InfoZip sources are a real surprise too-- I mean this code is one of the most portable pieces of code you'll ever see; they're a very good example of the sort of lengths you'll need to go to in order to achieve this kind of portability, and it's still elegant in my opinion.
Matthew @ Bytemark Hosting
...right HERE!
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
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)
Although readability is neccessary in code, it is more imporant that it works. Certain concepts are hard to code, and some algorithms have to be implemented in a certain way so that they work how you want them to. Library functions, for instance, require speed. Although you could code them "beautifully", without a perfect optimizer (which really doesn't exist) it would be slower than coding the function for that purpose.
The most important niche for readability is in new code, high level code, or constantly changing code. Maybe some others. Those are the places that you need to be able to understand the algorithm by looking at the code and/or comments. If something is rock solid and is not going change, is well documented and tested, the code doens't have to be pretty since it works how expected and nobody needs terribly to read it. If you're working on a multiperson project, though, and your code is likely to change, it's a good idea to document it and code it prettily so others can tell if they're adding or subtracting.
And, as always, it is important to stress the engineers'/scientists'/programmers' motto: Function before Fasion.
-Leo
I used to work at Microsoft as a tester for Windows NT 5 (pre Windows 2000). I had read the "required reading" of "Showstopper" and was curious to see Cutler's code. I found his assembly code for NT spinlocks and it was highly commented and very elegant.
;)
When I was at school at the University of Washington, one my profs worked with Cutler at DEC. He said Cutler would print out his code into two piles: code and tests. My prof said the test code pile was 3x taller than the shipping code. Cutler is a huge stickler for testing your own damn code!
cpeterso
Martin Fowler said it best in his book Refactoring: Comments are a good thing, but they are frequently used as a deodorant to cover up bad smelling code. I prefer to write self-documenting code. This means that I do little things like choosing meaningful variable names, using whitespace to group code in small digestable chunks, choose expressions for their understandability in the same way I choose English phrases, use common idioms used in the industry for whatever language I'm using, and try to use good coding practices in general. There are cases where it is impossible to show in the code itself why something is done, in that case, I'll use comments, but I'll also ask myself if there is a better way to write the code so it doesn't need explanation. In any case, I try to avoid "x++; // Add 1 to x".
Meldroc, Waster of Electrons
See http://www.ioccc.org/
Cool stuff !
If you ever code in MUSHcode, you'll learn to hate functional programming.
-Splat
Well, it's not completely functional, since most implementations now support side-effect functions, but many coders frown on their use. It is, however, most definitely the ugliest language I've used.
-Splat
I agree... though I believe you shouldn't comment every single function you create, if they are obvious, because it dilutes the value of the REAL valuable comments that explain difficult-to-understand sections. Like one comment in the JDK I remember:
Reference getRef()
/* gets the ref */
Or something like that... who needs it?!?
Among the best code examples in open source are those written by or lead by a single insightful programmer. Two that come to mind immediately: Perl (Every source file has an orthogonal but relevant epigram), and InterNetNews
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.
Several times I tried looking to what was supposed to be good code. I just found it really hard to grasp it all practically.
Then I happened to be looking through the source for Nethack, which I was playing like a junkie, and kept spotting neat tricks, several of which I subsequently used in the project I was on at the time (I always knew playing Nethack in work would do some good eventually).
Anyway, I found that by choosing something I was really really interested in, that's very optimised and generally well written, it held my interested and I still pick up wee gems.
CHeers
Noims.
This is not the greatest sig in the world. This is just a tribute.
For Java code afficionados, I'd heartily recommend taking a look at Lucene. It's small but pretty. One particularly bad example of code out of control would be Turbine. The latter is very frustrating because they generally have great ideas and lots of energy, but wading through the convoluted class hierarchies and gratuitously overloaded methods (some of which must be called more than once with different arg types) is not for the faint of heart.
Often you'll find pretty cool code in the C library. I havn't looked much at GNU libc. The whitesmith's c library used to be very cool (what happened to that??). Anyway here is some cool code...
char *strcpy(char *c1, char *c2) {
while (*c1++ = *c2++)
;
return c1;
}
The sad truth is that I work with people that pretty much have that attitude. Maybe that's not what they intend, but that's the result. When I've asked how to make a change to a JavaScript parser, I was told: I had to trace through the code, so you should too. This coming from the guy who requested the change. The thing is, when I pressed him for more information, he finally explained enough that I was able to make the fix in a couple of minutes, otherwise it would have been hours.
You are in a maze of twisty little passages, all alike.
Get the quake source code. Very interesting, more even if you are into gaming or graphics.
Granted, it's not that pretty or beautiful, but it's clever, and it's not that obscure once you look at it for a bit. Basically, the code that isn't for a particular compiler is commented out in that language. The neatest part was how they figured out how to make a comment block in all seven languages!
It's better, in a cross-platform portability way, to use individual spaces. If somebody is using an editor which can't automatically change the number of spaces, too bad for him.
Obviously, indentation is important.
--
You're a suburbanite.
No, I maintain that it is not a holy war: holy wars always concern personal preference; the tabs vs spaces debate is one of technical interoperability.
I disagree, and rather than repeat the arguments myself, I point you here.
--
You're a suburbanite.
Aside from Knuth there is Dijkstra. He put a lot of emphasis on algorithms, and hence code, being beautiful. His values of beauty are primarily from a mathematical point of view.
A classic on algorithms expressing Dijksrtas values is his book 'A discipline of programming' (ISBN 0-13-215871-X).
The problem with reading source code is that it's a lot like art. Not art the idea, but art the thing. (Writing good code is an art (the idea) but that's not the point)
Art is enitrely subjective. And the definition of good code is subjective. You realize this, and state that you're not interested in what defines excellent code. But we do agree that to find excellent (to you) code, you're going to have to dig through a lot of good (to others) code before you find that gem. Which leads to the next problem...
Art takes study to fully understand. And again, excellent code takes study to fully understand. Some will say that the ability to understand code quickly is an element of excellence, but this goes back to the first point, that art is subjective. Perhaps someone else places versatile and consistent APIs across a tool set above readability. Programmers are always making trade-offs between the relative incline of the learning curve and the power of the interface. (windows vs. unix, for example)
You can continue the analogy for a while, but these two combine to make a situation where you're going to have a tough time finding good code. You'll get tons of submissions of what excellent code is, but to make that distinction yourself, you're going to have to study each case in-depth.
Good luck.
J.J.
"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 "
Some of the most "elegant and masterful design" I've ever seen is code from the obfuscated C coding competition (http://www.ioccc.org/); it may often look pretty atrocious to the "untrained eye", but there are some pretty amazing examples of masterful design - and good design is something beautiful in itself, no matter how aesthetically displeasing it may be to the average Joe's eye. Huge industrial structures like, say, oil rigs, often look ugly to the general public, but I guarantee you, to the engineers who design and build such things, the people who can appreciate the achievement in building such things, they are often seen as beautiful.
So explain to me how exactly this post is off-topic? When did /. moderation become so lousy?
I wasn't as impressed as you seem to be, at least not with the Quake1 source code (I can't comment on the doom source code). It certainly wasn't bad code, it was relatively well thought out, and relatively neat, but poorly commented, and the use of #define's and the plentiful use of function pointers in some cases made it pretty obscure and confusing to determine what was getting called when, and what parts of the code were supposed to do what (particularly since comments are so scarce.)
of course, the only part I looked at though was the socket-level network code, so perhaps the other parts were better, I don't know. But I don't remember being overly impressed with the code. Not unimpressed, but not impressed either.
uh. to a nonperl programmer like me - that looks more like line noise than anything beatiful.
signatures pending - ansa@kos.to - (dont mail there)
The reason I think this is artful is that people tend to write code that runs only in their own platform. The fast majority of Linux code I see will not compile/run on a Solaris/SPARC system. Likewise, the Solaris/SPARC code rarely runs on Linux. Throwing Windows into the mix makes things even tougher.
For example, one of the chief problems is that the old *(int*)p problem. If you are lucky, you simply get a byte-swapped value; if 'p' is unaligned, your program will actually crash (it's a RISC thing).
When deal with external data structures (network protocols, binary files), most programmers think it is "elegant" to map structures on top of pointers. In reality, it is one of the most evil/ugly things you can do to code. One of the prettier pieces of code I've seen recently actually had a comment /*struct are for weenies*/ (meaning the structure-mapping process, not internal data structures). Dealing with such data one byte at a time sure look ugly to the uninitiated, but it really is the prettiest way.
In any case, one of the reasons I'm posting this is because I don't post much open source, and therefore don't know much about what other people find ugly. I would be interested in hearing your comments about the source on www.altivore.com. Please send e-mail to altivore-comments@robertgraham.com.
Actually, if you look at the assembler output of that code versus using a dummy structure as the head of the list and testing based on pSrch->pNext, you'll notice that your version is slower to execute in the main search loop.
I'd post a more detailed explanation, but Slashdot's wonderful "lameness filter" forbids me to post any code.
---------------------------
"The people. Could you patent the sun?"
"Any fool can make a rule, and any fool will mind it."
--Henry David Thoreau
Most I learned about *good* coding I got from an OOP course I took. There are a couple of factors that explain this:
* In every Smalltalk environment most of the source is open.
* The code for the main methods of the main classes is mostly standard... probably as pretty as it can be.
* Code sharing is a *must* in the smalltalk community, hence good programmers try to make code very easy to understand (the best kind of code, in my opinion).
* Certain features of the language (inheritance, polymorphism, code blocks, etc.) make for very modular code and very short and to the point methods.
If you're interested in OOP you should give Smalltalk a look... there are many freely available environments, like Squeak, Smalltalk Express, Dolphin Smalltalk, etc. I also recommend Kent Beck's 'Smalltalk Best Practice Patterns' which is a very good coding style guide that mostly applies to smalltalk, though you can apply a couple of the rules it presents to Java and C++'. Also, the book 'Refactoring' by Martin Fowler (Addison Wesley) is worth a look, as it teaches (with Java examples, tough it also applies to C++ and Smalltalk) how to make code that's easy to change, easy to read, non-redundant and very modularized.
As a Slashdot discussion grows longer, the probability of an analogy involving cars approaches one.
Even better, they make use of Design Patterns, Extreme Programming concepts, and other great software engineering practices (and as an added bonus: nice, friendly, insightful discussions minus the egos on their mailing lists).
The source code is free for the taking (very liberal license), super-cross-platform, and you can buy solid commercial support if you like.
It's good stuff; check it out.
While ACE is "hard to use" at first, I think this has a lot to do with inherent complexity; the patterns and OS-level stuff it takes on are really deep issues, and aren't likely to go away any time soon. ACE does a great job reducing the accidental complexity of a system, and for that reason it's well worth the (significant) investment of learning, I think.
Honestly, though, the size of the build tree is not something I worry about as a programmer; if a gig or two of an well-designed framework are going to make my life easier and my code better (more portable, higher performance, easier to review, easier to debug, free of memory leaks), then it's a gig well spent. Besides, 80GB drives are cheap :)
(Of course, the ACE folks cheat; their quad Xeon boxen burn through a complete ACE+TAO build in a few minutes).
That's actually an example of very bad code. Besides its obvious aesthetic shortcomings, it lacks error checking, it embeds hidden and unnoted dependencies, it's not extensible, etc. Brevity is a characteristic of much great code, but brevity achieved by doing only half the job doesn't count.
Slashdot - News for Herds. Stuff that Splatters.
I'm actually having trouble believing that you're serious. Can anyone's view of programming really be so impossibly narrow that they can't see the obvious deficiencies in that code, and actually try to argue on its behalf? Wow. That is just totally sad.
No, I damn well didn't miss it; it doesn't matter. Two objections:
I repeat my original statement: the code does not totally lack error checking, but it does lack error checking (relative to what should be present in good code).
It is easy to argue that, but wrong - on several levels. You left out IO::Socket, a little bit of UNIX, and a little bit of HTTP, but it doesn't matter. Your argument is a little bit like saying you need to know only one thing to become a doctor, that one thing being medicine. It's absurd.
Even that doesn't matter, though. When it comes to extensibility, anything that requires that you modify existing code is still a level below anything that can be extended without such modification. This code is only extensible according to a definition so lax as to allow any code to be considered extensible.
All of the parts that distinguish software engineering from mere screwing around. I'm not talking about functionality, I'm talking about the things that make some code that performs a function better than other code that performs the same function. This code may indeed fulfill its requirements (chiefly brevity) and do so admirably, and I do think it's pretty cool. However, as an example of "beautiful code" - the topic of this article - it totally and utterly fails. I wouldn't be surprised if even its author agrees. It's not beautiful, it's not supposed to be beautiful, that's not its purpose, and however cool it may be it has no place in a discussion of beautiful code.
Slashdot - News for Herds. Stuff that Splatters.
I think most people who read it would say my response was quite rational...even if they disagree with it, or find my tone offensive. That contrasts quite sharply with cid #489, which makes absolutely no attempt whatsoever to support or rebut any relevant claims. I'd love to continue this discussion, but only if you give me something deserving of a response instead of mere meta-argument.
Slashdot - News for Herds. Stuff that Splatters.
I downloaded the Tk source a couple of years ago to make a small modification and ended up printing out and reading the whole thing for the pure pleasure of it. It shows that C can be very easy (enjoyable even) to follow. The code's modularity and reuseability is miles better than most of the "Object Oriented" code I've seen too.
I haven't looked at the code in four years, though. It may have degraded since, I believe, it has a lot more authors now than it did at that time.
Of course, all the code I work on (for example, the Janos Java NodeOS) looks great, too.
Gtk+ is one of the finest examples of software engineering I've ever seen. By extension, I'm including glib. Check out these documents for most of my reasoning:
The Gtk+ FAQ
The gobject reference
Tic Tac Toe in Gtk+
LISP is often claimed to be beautiful.
Heh.. makes me think of something I always do, but still get in trouble for with my coworkers.
Elem *pMyLinkedList;
Elem **pSrch;
for (pSrch = &pMyLinkedList; *pSrch;
pSrch = &((*pSrch)->pNext));
(*pSrch) = new Elem;
(management of a link list with double ptrs so you don't have to condition the first element)
If I recall the OpenBSD guys don't necessarily audit the code for security, they focus on good, clean, correct programming practices. Security then naturally falls into place.
Although I have no personal experience with it OpenBSD might be a good place to look.
while ( ( *p++ = *q++) ) ;
:-)
this is the guts of STRCPY function. When first saw this, I was amazed how elegant & concise the code is. Yet not too cryptic!
I always give this to candidates I interview and only about 10% guess it is something close to C strings !! I would say all these Java Strings and garbage collection has spoiled a generation of programmers
LinuxLover
It made my compiler go 'jerky' :-)
#define for_each_thingy(current, list) for(current=list->head; current; current=current->next)
Then you get to write code like this:
void print_thingy_list(Thingy_list list){ /* Wow, nice and abstract. */
Thingy *t;
for_each_thingy(t, list){
print(t);
}
}
--
Patrick Doyle
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Its a terrible misuse of the C preprocessor that buys you nothing in form, fucntion or clarity.
Well, I guess software practitioners will never agree what makes code "beautiful".
To me, C's for-loop construct, while powerful, is hard to grok except in the simplest cases. The phrase "for_each_thingy" seems to be much clearer than parsing the code and trying to rediscover its intent.
I call it loop abstraction because once you write "for_each_thingy" then it doesn't matter whether the thingys are stored in a linked list, or an array, or are accessed by function calls. Your "unless" example has no such benefits.
Why duplicate the code for accessing thingys all over the place, when you can define it once and reuse it?
I'd like to hear why exactly you think hard-coding the looping mechanism each time is better, aside from C purity arguments and personal insults.
--
Patrick Doyle
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
http://www.ioccc.org
http://www.muppetlabs.com/~breadbox/bf/
http://linuxassembly.org
Everytime I see something like this it makes me want to scream. Perl is interpreted! The interpreter must be loaded into memory before perl scripts can be run!
That 650 line C program has that 34 line perl script beat.
Please don't compare compiler source code with interpreter source code.
--
'Intellectual Properties' are uncontrollable in the wild. To base an economy on them is just stupid.
The finest code I've seen is Quake and the Windows NT kernel.
Quake is impressive for a few reasons. Though relatively terse in comments, the code speaks for itself. Carmack, Cash and the rest know how to express the essence of a game in the fewest number of lines imaginable. This is what you would expect, of course. Then there are the deeper aspects of seeing arguably the master of high performance game programming at work. By following the flow of execution (literally or figuratively) over the course of weeks, you begin to develop an understanding (albeit pale) of what a decade on the leading edge means.
One of the few things I enjoyed doing while working at MS was browsing the NT kernel source. The group that Dave Cutler (author of VMS) assembled to write NT was really the quintessential systems team. Now the code is definitely NOT what *nix folks would usually like in terms of style. But the clarity of thought, evident to anyone reasonably well versed in the practice, screamed a quiet elegance. A simplicity of design that I hadn't seen prior, nor have seen since.
Agreed. It's a shame that corporate interests conflict with the advancement of the state of the art. By that token, you're right about TeX. Indeed, Linux is one of the greatest things to happen in the history of computing, IMO, regardless of beauty or elegance (of which there is plenty within the Linux kernel).
If you want a glimpse of the NT code, some is provided in the DDK. For example, ntddk.h contains many important microkernel datastructures and entrypoints, macros and inline functions. It's not the inner workings, but you can get an idea of the style and structure.
Oh well, once Linux democratizes computing, I think MS will come out with a Linux distro to try to kill the rest (like they did with IE), introducing nonstandard extensions that become defacto because of developer adoption. Maybe when they do that, they'll "open source" NT and we can all appreciate it.
I had a very similar experience. It's nice to see the story behind a passion. I learned to program when I was 13 on the Apple II. A year later I got a C64 and delved deeper. My interest in amateur radio led me towards EE, so by the time I got to college, that was my major.
I was a disillusioned kid at that point and learning EE only to go work for some part of the military industrial complex (this was the late 80's) made me like the prospect even less.
Then one day I was talking to some comp-sci grad students about the state of the art and realized that the world of computing hadn't actually passed me by! This was an avenue that was still achievable. So I scraped some money together, bought a 386/SX-16 (without the HD at first, to save money) and taught myself to program. Shortly thereafter, I dropped out of college to pursue a career. Ten years and countless remedial books on algorithms and datastructures later, I can call myself a programmer.
BTW, some of the most elegant code I've ever seen is the Windows NT kernel. That comment's likely to draw distain from this crowd, but the effort was led by Dave Cutler, the same guy who led the VMS crew. Dispite what people say about MS, this man's creation is a masterpiece (disregarding whatever is layered on top of it).
I think it all depends on what you define as 'beautiful' code.
Is it aesthetically pleasing code, that's idented properly, uses newlines for readability rather than new commands?
Or is it a piece of code that you must sit and spend a few hours on a few lines of code to truly grok all that it is?
A good example of this is procmail. It's an extremely widely used mail delivery agent. Its code however, in my opinion is ugly. It's hard to follow (hell, they even use 'goto' in C...)... but if you spend the time to grok it, you are amazed at exactly how tightly the code was written.
I consider procmail, for all its performance stretching obfuscated elegance, to be ugly code. I consider something like qPopper (sponsored by Eudora) to be beautiful code. It's highly readable, the variable names make sense, it's modular, it's logical.
In working on developing a customized mail service, I had to modify both procmail and qpopper. I absolutely hated working on procmail and loved working on qpopper.
Just my $0.02cp... all that's left after Uncle Sam takes his damn taxes...
--etrnl
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.
Python's C source is written by Python programmers - they value elegant code.
I know a lot of people who were struck by the clarity in the Python sources. It's pretty easy
to understand and modify. Heck, I fixed a bug after using Python for two weeks.
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
Comments are a paraphrase of the theory. Code is the implementation details.
One without the other isn't all that usefull.
Now, just in case you think Haskell is only used for dense mathematical expressions, note that it comes with literate programming functionality built in. And the Haskell Home Page has some examples of some quite meaty real-world examples.
-----
Klactovedestene!
This really got my geeky juices excited when I saw this. One piece of source code that could compile/run unchanged into 7 different languages. Listed in the source they are: ANSI COBOL, ISO Pascal, ANSI Fortran, ANSI C (lint free), Shell script (GNU Bash, Ksh, sh), PostScript, and 8086 machine language. No matter which you use, the magical words "Hello World" will appear!
Click here for the link.
From the: Borland-has-nothing-on-Van-Gogh dept.
It seems to me that the bulk of "beautiful code" which is produced today is that which is still written in an editor at a low level to be compiled on the fly or to do low-level, system-admin type of stuffs. (IE: Perl, shell, etc.)
Since making it through the scads of OOP methodologies and theories in college, I have seen little to nothing in the way of high-level (C++, Java, Smalltalk, PowerScript) languages that come even close to the pure genius of a nicely written Perl function.
Is it just me, or have our fancy compilers and IDEs and methodologies removed from us that intricate, complicated, horribly frustrating task of doing low-level, compact work that now we rarely see something of beauty? When was the last time you read some good assembly that just made you smile because it was so damn clever?
Swiss watches still sell well because they have something that the $5 digital watch from Wal-mart doesn't. Intricacy of the parts, the beauty of the syncronization of movement, the pure elegance in physics.
Blog,Twitter
This is in my mind some really really sexy code.
I guess you can call is OSS, you see it in almost every Programming Language book that uses scheme or something like scheme/lisp.... to see what it does check out Y-Combinator Derivation . So the basic idea is to be able to have a recursive func. that does not have a name.....
(define Y
(lambda (m)
((lambda (f) (m (lambda (a) ((f f) a))))
(lambda (f) (m (lambda (a) ((f f) a)))))))
Non-Deterministic Finite Automata
Ditto on apache
I suppose I'm not too threatening, presently, but wait till I start Nautilus
If the code was hard to write, I'm going to damn well make it hard to read!
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
#include <stdio.h>
int main( void )
{
printf( "Hello world!" );
}
Mark Duell
When I download something, the first thing I look for is comments. No matter how clever or elegant the code is, nothing 10,000 lines long can ever be so self-evident that you don't need comments.
1) I hope you don't mean 10000 lines in a single execution unit.
2) Well written code needs few comments. By well written I mean, most importantly, using appropriate object names. They should come from the environment - designs, protocols, manuals etc - without abreviation, retaining spacing (with underscores) and capitalization, so that there is no ambiguity as to what you refer.
3) Comments should be reserved for non-intuitive or optimized code. This should be rare, and well encapsulated to allow extensive testing.
4) In general, much commenting signifies bad coding!
Would it be great if you were
writing beautiful code...
on a beautiful computer,
while you eat beautiful nacho chips,
and gaze longlingly out your beautiful window,
at a beautiful butterfly,
and a beautiful rabbit,
playing in your beautiful yard...
Oh, - and your drunk.
sorry... props go to SNL and the Jack Handey deep thoughts... but this is the first thing that popped into my mind.
You say you want a revolution?
Oh yeah? Well, The Kalevala looked like line noise to me, too; until I got my first edition copy of Crawford's 1888 translation. Now it looks like very strange poetry -- I think maybe I'll have to learn Finnish and appreciate it nearly as much as the Karelians.
Fortunately, I don't think Babblefish has a Perl to Finnish mode, which means you won't see a version of Rick's server that looks like very strange code -- it will continue to look like line noise to you until you learn Perl, at which point its poetry will emerge from the noise.
Seastead this.
That's in the eye of the beholder. To some of us, Rick's code reads like poetry or elegant math notation.
it lacks error checking
There are 6 places where it catches and reports errors via the "or die" construct. Did you miss that? If not, what did Rick miss?
it embeds hidden and unnoted dependencies
That's too vague to be considered a valid critique.
it's not extensible
While the purpose wasn't to write an "extensible" web server, it is pretty easy to argue that it is more "extensible" than most web servers because you have to know only two things to extend it:
Perl.
34 lines of Perl.
brevity achieved by doing only half the job doesn't count.
In a parsimoneous form, Rick has specified, in a high level language, the functions of a web server.
What part of "the job" did it miss?
Then we'll see how difficult it is to "extend" his server.
Seastead this.
No, I damn well didn't miss it; it doesn't matter.
"Or die" doesn't really count as error checking.
Your argument...'s absurd.
Even that doesn't matter, though.
All of the parts that distinguish software engineering from mere screwing around.
That's pretty aggressive for someone who failed to respond in a rational way to any of my questions.
Seastead this.
http://www.email.net/work-well-together.html
Seastead this.
Check out the 34 line web server written by Rick Klement, the best Perl programmer I've ever known, who says of it:
.
I wrote this after seeing a small HTTP server that took ~650 lines of C. I thought it would be an interesting challenge to try for a ten-to-one reduction. Not only did I exceed that, but the ~650 line server did not do POST type CGI's, which mine will.
This server (which I name 'ws') has been quite useful. I use it for CGI testing, it's much simpler launching 'ws' with all parameters given on the command line than modifying an Apache conf file and firing the new Apache server up.
'ws' takes four arguments on the command line,
ws port_number doc_tree_base cgi_tree_base cgi_location
but they all have defaults. I usually fire it up with
ws 80 .
and then fetch plain docs from machine/somedoc.html and CGI's from machine/cgi-bin/somecgi.pl
Seastead this.
Tell that to the psychiatrists and psychologists who treated me in the psychiatric hospital where I spent the summer of 1985, when I was diagnosed with schizoaffective disorder.
Or to my insurance company at the time, who sprung for the $10,000 treatment.
I know it may be fashionable to claim one is manic depressive, but I can assure you it's unmistakeable in me, and it's not something I would choose. There's no Hell so deep as what I experienced in my college days.
If you don't believe me, maybe you'll at least believe I do some good in my writings. I regularly receive emails in response to my website on Manic Depression from people who've experienced it - either they have it or their loved ones do - and they don't know what to do about it.
There is a lot of information available about the illness but because of the stigma which is perpetuated by ignorant people such as yourself, not a lot of folks have the confidence in themselves to speak out about their experience publicly as I do, occasionally here on Slashdot and permanently on that website.
I speak out in part because of my confidence in my position in my career and also my belief that speaking out on what is right is one of the most important things you can do, even when it comes at great personal cost.
The people who write to me tell me the fact that I speak out personally as I do makes a tremendous difference in their lives. It has happened many, many times that someone has written to me to tell me that I'm the first person they've shared the fact that they think they're mentally ill, or contemplating suicide.
You should know that that page receives about 3,000 hits a month, and I recieve several emails a day from people looking for advice, about half of them people who have the illness and the others from people who are closely involved with a sufferer and don't know how to deal with them.
By the way, I'm happily married. I first met my wife three years ago, and we were married in St. John's Newfoundland on July 22, 2000. We just bought our first house together, in Midcoast Maine, and moved into it last weekend.
Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
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 am not sure if you want to quanitfy this as being beautiful or what-not, but I am sure you can find examples of many different types of code.
Here is the FreeBSD source tree fully HTML-ized.
And, in effort to not start a war with the zealots, here is a link to view the Linux kernel source.
Jeremy
I picked up Lua after reading this article about it in Dr. Dobb's Journal for use in Grim Fandango. (It has since advanced and yet simplified in tremendous ways... The article is about version 2.5, and it's now at version 4.0.) In addition to being a beautifully simple yet expressive language, Lua also has one of the cleanest codebases I've had the fortune to hack around in. The compiler/interpreter are all easily navigable... Comments are sparse, but well-placed and thoughtful; there need not be more because most of the code clearly explains itself. It's all written in straight ANSI C, and is instantly portable to just about everywhere without even any configuration macros. It's extensible in clean, logical ways... and oh yeah, it's BLAZINGLY FAST.
http://www.ionet.net/~timtroyr/funhouse/beer.html Check out the "Turing Machine" submission, or BrainF***
"These people look deep within my soul and assign me a number based on the order in which I joined" --Homer re:
I'd definitely recommend looking at the latest kernel. You'll learn neat stuff like:
o How to do OOP in C (including virtual functions; see any of the *_ops structs)
o How to write macros that inline well (eg the spinlock macros)
o How to arrange structs for better cache performance (eg the network-related structs)
o How to write portable code that configures itself via macros; the final results compile to very efficient platform-specific code without a hint of overhead
For a higher-level view of software, I'd also encourage you to examine glib and gtk.
o These expose a large, industrial-strength API; you'll see how a modern large-scale package is organized, and how it deals with complex issues like character sets
o You'll learn one approach to event-driven programming; glib and gtk make extensive use of callbacks and reference counting since order of execution is impossible to predict in an interactive program
o Along the way you'll pick up Gtk programming, which is quite a useful skill if you need a GUI sometime
If you're interested in scripting languages, definitely check out Python; it's very well-organized and cleanly designed. Plus knowing how to embed/integrate scripts with a C/C++ package is very valuable.
While carefully studying these packages, I'm sure you'll even find a bug or two to fix - giving you an opportunity to contribute as well as learn =)
Dan
if you want some shitty code...let me show you what I was just working on....
did you need a seperate class for each piece, or can't you just use the list of moves as the distinguishing feature of a Piece?
I still have to believe that those rules can be configured in a more flexible manner then hard code.
Check out Jive for an excellent example of beautiful coding in Java. There are a lot of forum software packages out there but none as complete (in terms of code design).
I've been able to look at this code and immediately understand, admire and learn from Matt Tucker's code from day one. Makes a good read.
If you don't understand anything I post, please accept that I ate paste as a small boy...
It takes a rare soul to write beautiful code off the bat (Like Nick Weininger or Paul Cantrell- if you know `em), let alone beautify the crufty/spaghetti variety. For some people, (a little more artsy) like my roommate, they can't start a project to save his life, but they elegantize more code (and save more sleepless nights/asses/grades) than I think even they know.
Besides- Knuth cornered the mathematical/beautiful typography market 2 decades ago- and nobody's tried to go up against him since. It serves as a credit to his vision, and his art.
You wanna see great code in as many languages as youve ever seen assembled? Sing and follow me! "99 bottles of beer on the wall, 99 bottles..."
http://www.ionet.net/~timtroyr/funhouse/beer.html
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
1000.times do
puts "Hello? World? What?"
end
If TEX by Donald Knuth doesn't bring tears to eyes nothing will. ;-) But seriously, there probably isn't a better example of programming at it's finest, particularly if you are interested in Literate Programming
Find them here.
I think beautiful code is subjective like art but unlike art programming has a relatively short history. I think things that would define beautiful code could be things like originality of thought, simplicity, and efficiency as well as the more common things like is it easy to read through and does it exhibit the general consensus of how things should look at the time. I think that in time groups will begin open source "peer reviews" where people could actually vode on things like syntax, originality, simplicity, how well they perform the function for which they were intended. I'm not sure of anything out there like that right now asside from the obscufiblagh* whatever they call it.
I think it would be neet to see a site pop up where thats all they did was take pretty code and imortalize it for study and general advancement of the "science".
I spent the years 1975-'80 hacking first Stallman's Teco ^R-macro-based Emacs on Dec-10's and then Bernie Greenberg's MacLisp Emacs on Multics. Moving to UNIX, I started playing with Gosmacs in 1981, and from 1982-'95 I worked on Stallman's GNU Emacs - one of the prettiest pieces of code I've ever seen.
Some history: I forked the base for what became GNU Emacs from Gosling's CMU thesis (on optimal redisplay algorithms - necessary stuff when talking through 300 baud modems) editor that later he sold to Unipress. (BTW, Gosling got the keymap idea from Craig Finseth's FINE (Fine Is Not Emacs) who got it from Stallman's.) Because Unipress claimed ownership of the code, RMS buckled down and rewrote essentially the entire thing. And what an amazing job he did!
(This is from memory of my old days of hacking emacs - things may have changed...) He created a 26-bit object space, with a 5-bit object descriptor and 1 bit for mark-and-sweep GC all packed into a 32-bit word. Then there's the DEFUN macro, which simultaneously defines C and elisp-callable functions, as well as setting argument limits, prompt and a documentation string. The doc string can be used interactively, via the (pre-web) hypertext info system, or run through TeX to create a printed manual! Sweet!
My Mac's been dead for a few months and since I don't have access to the excellent Mac Common Lisp (MCL), I play with elisp these days. And there's some killer elisp packages. Vi is great, but Emacs Rulz!
--
The antidote for misuse of freedom of speech is more freedom of speech.
-- Molly Ivins
heh heh..
that's a good one.
can be found right here.
It's cool because it's really small.
In fact I think it's the smallest program possible with an ELF binary. About an eight of the size of the excecutable created if you use some kind of fancy-schamcy assembler. And a 50th the size of the same program created by gcc.
darn cool if you ask me.
The funniest piece of code I can recall was in .profile, it was:
a users
PS1=`echo $LOGNAME | cut -d= -f2`
PS1=$PS1"> "
Donald Knuth's web site is here. Information about the reward for TeX bugs (currently $327.68) can be found here under the section titled "Rewards".
It says: "If you do succeed in finding a previously undiscovered bug in the programs for either TeX or METAFONT, I shall gladly pay you a reward of $327.68. Corrections to errors in The TeXbook or The METAFONTbook are worth $2.56, as in all my other books."
Check out Chad's News
I was faced with the results of learning C++ without knowing OOD or OOP principles.
I can't post here his code, but it was bad enough to make me invent a new term on the spot: fettuccini classes, the OOP evolution of spaghetti code.
Ciao
----
FB
Nope. It's fettuccini. Just like fettuccini Alfredo, the most famoush italian dish - you can find it in any italian restaurant in the US.
The fact that nobody in Italy knows what is it is secondary - real italian food is what you eat in US italian restaurant (so start eating garlic bread everyday, please).
Ciao
----
FB
Any chance you work for Microsoft? A little 'research', eh?
OK, sorry.
Evan - needs to hit preview before submitting
If a corporation is a personhood, is owning stock slavery?
Uhm, what's wrong with reading code? It's very nice to see how someone did something. Some of the most creative and elegant constructions I've seen ANYWHERE have been in source code. It's really an underrated form of expression.
If a corporation is a personhood, is owning stock slavery?
If you're not interested in code as code, you don't get it.
That being said, I'd also like to point out theres more to an open source project than just the code. A beautiful project includes docs (not just inline with the code), communications channels (mailing lists, newsgroups, etc.), useful examples, FAQs, etc. It takes alot of work to get these things to a useable state by the community.
man 9 style
I'm not quite sure about that. Konqueror isn't even close to being stable, ditto Mozilla.
I don't know about Mozilla(probably ugly), but Konqueror is very nicely coded. Konqueror is becoming *very* stable and I think is an excellent browser. The source code is very structured and readable. I tend to believe that using Qt and OO code helps create very readable and easy to understand programs.
my @output =
map { $_->[0] }
sort { $a->[1] cmp $b->[1] }
map { [$_, expensive_func($_)] }
@input;
The question is: Is this code that is "really bad"? Or "code that shows elegant and masterful design"?
Or is it both?
My vote is for both... Elegant, masterful, excellent and beautiful, yet can be really bad in certain uses.
Though I agree that most MS APIs are bad I also understand why they haven't been changed. Why are we still using sprintf instead of snprintf? Compability comes to mind. We are trying to keep source level compability with other UNIXes where MS is trying to keep source level compability with other versions of Windows(TM). In addition to compability problems changes would render current knowledge on MFC etc. completely useless. I'd think that those void pointers are there for historical reasons only.
If you still disagree think about X and xlib. Why are we still using API that doesn't have any support for alpha blending, vector graphics, decent pixmap filtering etc. features supported by hardware in current graphics chips. We don't have even anti-aliased fonts which I myself take for granted in every other OS I use these days.
I wouldn't call MS documentation poor. Perhaps they don't give you all the documentation for free, but there good documentation for the areas MS wants the developers to know. Sure there's undocumented features that MS uses in its own software and others follow with reverse engineering. It's MS source and it's up to them what they want to tell about it to developers.
If you don't like MS APIs or their OS don't support them. Notice that if you don't make programs for their OS you don't need to care about their API quality. What comes to coding style (I assume you mean code formating)... for example I cannot stand GNU coding "standards" - fortunately I have indent.
The fact that MS does provide some old ugly APIs doesn't automatically suggest that MS couldn't be perfect source for look for good code. Unfortunately MS seems to keep most of it's code secret. Do you really think that company that hires every top quality coder it can get would generate only bad code?
_________________________
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
"To the person who posted this comment, I don't think this community is for you. Many people have grown tired of the appearance of more and more trolls, who have nothing to offer this community. I myself have thought about leaving many times, and going to greener grass. "
Oh please. Trolls make Slashdot fun. There is nothing more entertaining than dropping your threshold to -1 for a few laughs. Instead of bitch and moan at trolls, why not raise your threshold? If you don't know how to raise your threshold I don't think this community is for you.
"If you are also tired of these trolls, and of the blatant bias and sheer overload (of posts) the authors of this site are showing on Slashdot I would like you to check out Kuro5shin.org "
So posts should be censored? If you believe in censorship, I don't think this community is for you.
-gerbik
Beautiful Code Links (Score:5, Informative)
:)
I aim to inform.
-gerbik
Some of the most beautiful code produced in the past 20 years can be found here.
you can thank me later
-gerbik
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.
Kernel source, Apache, Samba, Gnome Bonobo, KDevelop, Mozilla, Konquerer...the big name stuff should be pretty juicy.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Bend as a reed in the wind. The novice curses unknown authors. The expert smiles and writes his code.
Code is poetry. Do not impressed by bombast, vocabulary, clever phrasing, rhyme, allusion. Beautiful code is distilled idea: language, syntax, style, comments, format, philosophy are mere surface quality.
If you attain enlightenment, you peers will laud you with praise. One day, you will meet one of the masters whose work led you to Satori. You won't have much to discuss, because you both understand the deep meaning of code.
My reasons for recommending this code are:
This is clearly the work of a professional programmer, yet it was a game he was working on in his spare time. I use this as a standard in my own work.
Not so much the code itself, but the APIs are easy to use, they're highly portable, and very free. I wish I could say libpng, but it took a little bit too long to figure out how to make it do what I wanted. Maybe that was just me though. There was some trial and error involved. Let's hear it not only for "beautiful code" but the entire package being well designed and easy to use.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
What you're failing to consider is that Mel was coding for a far different era of computers. Not only did he do things the way he did because it was *cool*, he did it because computers weren't really all that fast and you had to play dirty tricks in order to squeeze every bit (pun intended) of performance out of them that you could. -Mark
I would suggest you download Hugs, start dabbling in Haskell, and read the Haskell Prelude. It is relatively easy reading and contains code that is very beautyful.
Totally beautiful -- in my case it took someone who understoon object-oriented principles and had done a bit of C++ in small 6-week to 3-month college projects into the culture of real O-O development.
Caveats -- after doing Smalltalk, C++ will get really painful and you'll keep snickering every time you read Java code.
As well as it might pay, most of the work done in Java and on the internet these days is a lot closer to COBOL programming (batch and transactional) than anything close to the complexity and ingenuity of an Eliza or GPS.
..to set records straight 8)
How could Italians live up to their hype of passionate lovers if they really ate so much garlic bread ? 8)
Forget that crap.. start cooking yourself !
Its interesting that you mention how to format comments but not what you put in them. Excessive and useless commenting is almost as bad as having no comments at all. Its frustrating to have the code so chopped up with crap, that I can't even fit 15 lines of code on the screen. Good variable names can greatly reduce the need for comments.
Its interesting too that everybody is looking for "beautiful" code. Are we talking about algorithms, design or style? But whatever the focus, I greatly prefer simple code that can be easily read with minimal comments. You mention the nightmare of working with 10,000 lines of code, and the importance of comments there. I agree, but I think the design is much much more important there. I shouldn't have to know all 10,000 lines of code in order to make some patches. I should be able to determing which sections are relevant, get an overview of those sections, and be able to easily make changes in one place that don't mess up everything elsewhere.
Despite all the hype around Extreme Programming(XP), it promotes some great ideas that lead to more simple(ok, even beautiful code.) It suggests trying to keep all methods so they fit onto 1 screen, avoid any duplication of code in classes, have everybody on your team work with a consistent style! and try to limit class sizes to under 1000 lines. But most importantly of all, one must refactor to make things simpler whenever possible. Constant refactoring!
Before I get flamed, I should include the disclaimer that simpler is not always better. There are times when you did need to use a clever chunk in order to improve performance, then it might be worthwhile to explain in greater detail as to whats going on. But for the most part, keep it simple.
Surprised nobody mentioned smalltalk code.
See Squeak for example, even the bootstrap C code is generated from squeak itself.
Once you get used to the syntax, the code is so much easier to understand for the same functionality compared with ones in other languages. Thanks for the OO nature, the code is easier to maintain as well.
I don't want to start another comp.lang war. I like C, I like Haskell, I use java/python quite a lot, but for purity and elegance, nothing comes close to Smalltalk.
Probably one of the most groundbreaking graphics engines ever. Examining the code is like watching John Caramack think. Beautiful, Beautiful, Beautiful...!
But then, I doubt there ever was a Y2K problem, except in situations such as banks where an account holder would be given -100 years worth of intrest. Why should most computers care that its now 1900 or 19100? Not even Windows is so flakey that it would crash because of that.
------
Not a typewriter
This is best code I have ever read, hands down.
-I like my women like I like my tea: green-
>I know it's not indented... I tried... Darn html.. Oh well...
if only Support(/.HTML)
//to indent
CheerUp;
use
infrontOfText
stopUsing
ifOff
PS: Allowed HTML should use lowercase examples, and allow XHTML <br /> - I keep having to remove them :-(®
--
mrBlond
CowboyNeal for president!
"Hit any user to continue."
If you want an example of a sweet-ass API you should check out the PGPSDK, that's just amazing. They some how managed to make a polymophic object orientated system in pure C (or course, it probably can't be extended as easily as it could be if it were C++ or java, but still).
Really, really easy to work with.
Amber Yuan 2k A.D
"and dear god does this website suck now." -- CmdrTaco
What's your point, exactly? Human may not be designed to think in reverse polish and to do recursion, indeed. However, humans were also designed for hunting and polygamy. They were also obviously not designed for using computer, otherwise they should have a hand with 105 fingers and another one with 3 or so.
That thing we humans arogantly call "progress" has always been achieved by forgetting the straightforward applications of our "design" and by using our abstraction capabilities to accomplish unobvious activities. Functional programming is no exception. And it gave us Emacs.
So? I'm afraid I don't get it.
Check out savastio.c or any other ioccc winner.
If you can read those, well.. you're either too good or have too much time in your hands. Either way, it's good.
This is the original Duff device (in pre-ANSI C). A gem, that the ANSI comitee carefully looked at and declared valid.
Take a look at how the loop unrolling is performed. See how the loop is misplaced between the first and second case label. This is beautifull, because it have been a creative act to even think that the compiler could grok it.
send(to, from, count)
register short *to, *from;
register count;
{
register n=(count+7)/8;
switch(count%8){
case 0: do{ *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while(--n>0);
}
}
See author comments at:
http://www.lysator.liu.se/c/duffs-device.html
(But clearly, I would not want that in production code)
Btw, what I call beautifull code is crystal clear code. The first ncsa httpd was of that kind (imho). Anyway, beautifull code matters much less than beautifull _interfaces_.
Cheers,
--fred
1 reply beneath your current threshold.
.. is in the eye of the beholder - this amphorism works in this case too. But anyone who has had a chance to look at M$ MFC or Native Winblows code would have to agree that you would have to be blind to find beauty in any of that kludge. But code is not s'possed to be pretty. It's gotta work. That's what it's there for. Code On.
-*-*-*-*-*-*-*
Bzzzt....wrong. I've worked on more examples of god-awful COBOL code than I care to count. Crap code comes from laziness, incompetence and lack of thought about the future - the Y2K bug is an excellent example (although other platforms had their share). Good code comes from talent and I've seen plenty of well-written, and easy to mod code as well.
I agree that much of the Doom source code is quite nice. For me, its beauty comes from its simplicity; the logic is split well, and free of unnecessary optimizations.
Reading through it helped me greatly back when i was first learning C.
This is a big problem for me, too. The major problem is that they tend to put the various kinds in with the food they are meant to flavor, instead of grouping them all together in a single aisles. So it is really a matter of personal preference.
But I would suggest going over to the Mexican food aisle, because I find Tobasco to be very beautifully tasting...
Espera un minuto...
OH...Source, you are looking for source then! Well, never mind.
Hopefully I didn't put any [] around my words.
This code sucks like you wouldn't believe.
C++ exceptions allow for exceptional control paths and clean non-local error handling. Anonymous Coward still doesn't have his/her facts straight.
Here is my essay on this topic (which slashdot declined to publish a couple months ago).
Chuck
There's also a very well-written style guide that explains the logic behind the style.
Ubi dubium ibi libertas: Where there is doubt, there is freedom.
Your favourite song retold in a total of 227 different languages:
99 Bottles of Beer
www.perlmonks.com
I heard of this from everything2.com.
- email account is @hotmail.com
Discussion Never Hurt Anyone.
Discussion Never Hurt Anyone.
Libertarians
(Quoting from the c2/wiki BeautyAintMyBusinessNoSir (which is a response to BeautyIsOurBusiness)):
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -- Buckminster Fuller
- Dr. Foo Barson
The javadoc is here, with links to the code, and I chat a bit about it here.
For an example of how NOT to code, why not check out some Perl Obfuscation? I think it's a great thing to look at, even though (or especially because) I really don't like Perl as a language (heresy! heresy! Don't flame me please, I've heard the arguments).
Read my keyboard review.
You are saying that you are interested to both the ends of the ladder, the Good and the Bad. It is very easy to find the Bad, so it's not worth the effort, since it is much easier to be lazy than overzeolus. What you don't expect though is *where* you can find the Bad. Bad code lies everywhere, even toghether with the Good. Even made by the same person....I whish to be deliberatly provocative: Linux. Try to see the code of floppy disk driver inside the kernel, floppy.c. From my point of view, it's an ugly mess of good hacks and sloppy coding. Try to see the source of much-abused ls command. Beware, it's so convoluted that I think non one touches it anymore. Of course, the Good and the Bad can be swapped, i.e. some people will say exactly the opposite, but code is like people: sometimes is bad, sometimes is good, depending on the way you woke up. Even for wizards like Linus.
While I agree that the intention of the Obfuscated C Code is to produce bad
code, I can't help feeling that the best entries are very beautiful. If the
entries were not intended to be "bad" then the beauty would have been lost
but deliberately obfuscating a program (to the point where the viewer
wonders if it is C at all) justifies the "poor" programming choices and
qualifies it as art.
I personally love to see skilled programmers stretch the compiler and the
language to the limits and it is this, I think, that makes the Obfuscated C
Contest so aesthetically pleasing.
"A long time ago (1990) some people were talking about polyglot programs in rec.puzzles, these are programs that are written in several languages. We thought this sounded like fun so we wrote this one."
We think it contains some pretty cool code, and most people still haven't found the hidden gems! There are two superfluous characters in the whole file (not including those used for formatting). Can anyone identify them?
It still seems to work on most modern platforms.
"Keep the blank lines, they are important"
Cheers, Peter
ideology.com.au
i never coded on circlemud codebases (i always played, heh go fig) but every admin i've ever seen who has always said it was the worst kind of spaghetti. i'm not sure if it was that way 'out of the box', or after they had mucked it up... ;)
eudas
Blessed is he who expects the worst, for he shall not be disappointed.
When I was 16 I was writing a text game for C64 in basic and thought there must be a better way to store data that predeclared arrays.
In first year Uni I learned about pointers and the more basic algorithms using pointers to represent lists, queues, recursion etc etc. I was in heaven.
Read Gabriel's "Patterns of Software: Tales from the Software Community" for one man's search for beauty in a lot of places -- his code, his company, the arts, his life.
Beautiful code is a subject worth contemplating, not speeding by with the standard crap answers above. Here are two quite-different places to find beautiful code:
(1) The "Programming Pearls" books by Bentley.
(2) "On Lisp" by Paul Graham
Also, Here are some quotes of relevance:
The [benefit] which rhyme has over blank verse...is, that it bounds and circumscribes the fancy. For imagination in a poet is a faculty so wild and lawless, that, like an high-ranging spaniel, it must have clogs tied to it, lest it outrun the judgment. -- John Dryden
The central task of a natural science is to make the wonderful commonplace: to show that complexity, correctly viewed, is only a mask for simplicity; to find pattern hidden in apparent chaos. - Herb Simon
The mathematician's patterns, like the painter's or poet's, must be beautiful; the ideas, like the colours or the words, must fit together in a harmonious way. Beauty is the first test; there is no permanent place in the world for ugly mathematics...It may be very hard to define mathematical beauty, but that is just as true of beauty of any kind -- we may not know quite what we mean by a beautiful poem, but that does not prevent is from recognizing one when we read it. -- G. H. Hardy
Joseph LaGrange..."believed that a mathematician has not thoroughly understood his own work till he has made it so clear that he can go out and explain it effectively to the first man he meets on the street." -- E. T. Bell
When judging a physical theory, I ask myself wether I would have made the Universe in that way had I been God. -- Einstein
Beauty is the proper conforminty of the parts to one another and to the whole. - Hesienberg
There is no excellent beauty that hath not some strangeness in the proportion! - Francis Bacon
Simplex sigillum veri - The simple is the seal of the true. And Pulchritudo splendor veritatis - Beauty is the splendour of truth. - S. Chandrasekhar
The Scientist does not study nature because it is useful to do so. He studies it because he takes pleasure in it; and he takes pleasure in it because it is beautiful. If nature were not beautiful, it would not be worth knowing and life would not be worth living... I mean the intimate beauty which comes from the harmonious order of its parts. -- Poincare
My work always tried to unite the true with the beautiful; but when I had to choose one or another, I usually chose the beautiful. -- Hermann Weyl
Beauty is truth, truth beauty - that is all Ye know on earth, And all ye need to know. -- Keats
There are some great men of science whose charm consists in having said the first word on a subject, in having introduced some new idea which has proved fruitful; there are others whose charm consists perhaps in having said the last word on a subject, and who have reduced the subject to logical consistency and clearness. -- J. J. Thomson
Do you know we're sitting on 4 million pounds of fuel, one nuclear weapon, and a thing that has 270,000 moving parts built by the lowest bidder? Makes you feel good, doesn't it? -- Steve Buscemi ("Rockhound") in "Armageddon."
It's funny that you would ask that question right at the same time that i found this link. It's an article (with a reasonably good bibliography) about software engineering and writing good code.
check out his links at the end of the article as well
You should take a look at Sun's Java Classes available on their Java website. These classes are designed pretty well, and the standard of the code is very high. Even though this code is pretty high-level, it shows some interesting programming aspects (hashed lists, interfaces, object oriented design, just to name a few).
i've skimmed a book about beautiful code, beautiful designs and such. the best kind of code is code that is "inhabitable" where one, or ones, can go into the code and feel comfortable learning the guts, and making modifications quickly and easily. this type of code is not beautiful. i've seen inhabitable code, and it's great for the maintenance team. beautiful code is more like a legend that doesn't exist. if it were truly beautiful, noone would dare touch a thing and it would outlive any usefull life. you don't see people going around touching up the mona lisa just because it needs some modifications. art (beauty) is somthing you build or create once and then walk away. code should not be art.
Take a look at "Lions' Commentary on UNIX 6th Edition" by John Lions. It's an older text, but it's beautifully coded. Although this is a great text for OS programming, if not the standard, it can also server as a good reference for style and design. It's written by the guy that invented C, so you know it's going to be good. :)
zerovoid
...but the Linux kernel, useful and reliable though it may be, is NOT a good example of beautiful code.
It's largely a hack, and a fairly poorly laid out hack at that.
For a beautiful open source unix-a-like, look at the NetBSD kernel. In fact, all of NetBSD is nice.
arnald
Agree with BSD, agree with TeX, disagree with Linux kernel.
Something I've learnt a lot from myself is Scintilla. It's a free editing control (with my favourite editor, SciTE, thrown in too) written in (a subset of) C++, but in a very nice way... It's hard to put your finger on why it's so readable, but it just makes sense. I think it's at the perfect size to study - not too big to be incomprehensible, but not too small to be unrealistic.
Have a look.
arnald
Your Windows NT comment is interesting - it seems you aren't just trolling, that you are serious. The only problem with offering the Windows NT kernel as an example of good code is that... you can't see it. You need to sign a non-disclosure to look at it, which makes it unusuable for demonstation purposes.
Perhaps one day, when Microsoft opens the Microsoft Source Code museum, it will be possible to evaluate the code, and compare it to other code. It may be a enlightening excercise to see what was good enough to support most of the business world for about a decade. Until then, the original poster is better off looking at open source code, like TeX.
check out the source of "pine" or "wu-ftpd"! you'll realize that everybody in the world writes beautiful code except people at the washington university.
My Code looks awful It is never aligned and tabed niceley and all that jive. It often hass masses of comented out garbage. It does, however, get the job done, is written in the time allowed and makes me happy. I would dearly love to write some nice perl poetry. Maybe when I retire.
From the Jargon Files: Mel's full name is Mel Kaye. He is refered to in the LGP-30 manual as "Mel Kaye of Royal McBee who did the bulk of the programming [...] of the ACT 1 system".
-- notice the lack of #weird incantations at the start
class GREETINGS is
 main is
#OUT+"Hello, World.\n"
 end -- of main
end -- of class GREETINGS
No, your children are not the special ones. Nor are your pets.
One of the most wonderful example of elegant but poor code is the recursive method for generating Fibonacci numbers. O(n!). The iterative method whilst looking so much slower runs so much faster. O(n). Remember kids good code is ANSI C code :)
Naden.
Funtage Factor: Purple
Well, you certainly don't want to look at Slash if you're looking for well-written, easy to read code.
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
If you read the Quake source, you will feel like God has stepped down from heaven to write software.
Will code a sig generator for food
I won't patronise you or the other
Ian
the JCL has it's moments. I'd actually suggest the Delphi VCL first, but the source ain't free. Too bad - it's an excellent lesson in inheritance.
meh.
My code is heavily commented... out.
Gosh, this is really a hard question as you can see from the apparent lack of enthusiastic answers. If only you asked where can you find BAD, AWFUL code I can guarantee there would be a lot more links. I mean, there are movements devoted to producing as bad code as possible. Take a look at Obfuscated C Code Contest. You can learn from negative examples as well, and they are much easier to find.
On a semi-related note I think the slashdot crowd would get quite a kick out of these weird C compiler errors
"// this is the most hacked, evil, bastardized thing I've ever seen. kjb"
Dennis Ritchie kindly makes available source for "two very early compilers". Circa 1970 stuff from under the floor boards resurrected from tape.l C.html
Check out:http://cm.bell-labs.com/cm/cs/who/dmr/primeva
Here's where you'll find codes of all kinds.
There's always sufficient, but not always at the right place nor for the right folks.
#include #include "bawls.cpp" void main (){ Bawls A[99]; //initialize type Bawls to Array
for(int i = 99; i > 0; i--){
passAround(takeOneDown(A[i]));
}
} // eof
Patrick C. Lamoreux lamoreux@iastate.edu
10 print "Beautiful code" 20 goto 10
http://www.circlemud.org I had fun intalling this on freebsd and getting it to run. You can open the code and make mods to the mud and enjoy playing your mods. Apply the patches from the ftp site. Others can come in and enjoy your mods. I learned alot about C programming from modifying this software and had fun playing with the mods I created. For instance, mod the software to have Puff roam around town instead of hanging out in Limbo. RO mud did this. Is it still around?
Remember back in the days of Second Reality by Future Crew and groups like Orange et all. If you can find the source to a demo, you can witness some truely awe inspiring code. www.scene.org These people squeezed every last clock cycle out of those old 386's. Most people didn't think it was possible. I know I didn't back then.
All a coder really wants, are fast cars, fast women and fast algorithms.
i masterbate every night to a hardcopy of vi's source.
(Comments that have to be made before somebody comes out with a totally unrelated anti-microsoft comment)
Do you people *really* have nothing better to do? Does Microsoft really hurt you that much? Do you really think that the world is meant to be perfect and the software industry owes you something? What? Oh, you're thirteen! Of course...
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.
I was with you until you said that. Are you saying that writing code just because you enjoy it is a lesser reason than to put food on the table (or make money for your business)?
I'm not much of a coder myself. I do a little here and there, but nothing I would call beautiful. But I still enjoy reading elegant or "pretty" code when I get the chance. My favorite passtimes however would be music (playing, writing and listening) and stories (also reading and writing). So, taking your statement to the next level are you going to say that anyone that plays music, but doesn't do it because they are trying to make a commercial go at it are doing it for a lesser reason than the people like N-Sync and the Backstreet Boys? Or are you saying that the guy that writes stories just because he loves to write is doing so for a lesser reason than the guy that is hoping to get rich off of writing the ultimate book?
Somehow that seems backwards (if that is what you are saying). It seems the lesser reasons to me would be doing it for money/fame/fortune. Doing something just because you love and enjoy doing it seems a much higher reason. I'm not sure if you were implying what it looked like, but if you were, I disagree whole-heartedly.
------------
Oh, OK;-).
Sorry about the rant then.
------------
Your comment seems clever, until you consider humans created keyboards,mice,computers as a whole.
#!/usr/bin/perl printf("Goodbye World."); return 0;
___
The way to see by faith is to shut the eye of reason. --Ben Franklin
I'm inclined to disagree. Code can be an art form, and if you dont agree you probably arn't a programmer. I wish I could write code decent enough to post under the 'beautiful' subject here, and I would tend to respect those who can...
___
The way to see by faith is to shut the eye of reason. --Ben Franklin
Let us take a short program and translate it into how Anthony Trollope, P. G. Wodehouse, Evelyn Waugh, Ernest Hemingway, William Faulkner, J. D. Salinger and downright bad writers like Danielle Steel and Jackie Collins would write them -- I would love to see the comments on a Trollope program.
... you need to read some classic Raster code. I suggest Enlightenment 14.0. The elegance can move a geek to tears. To see the subltle gravity of his code, where just one loop can bring tears to the CPU. You too will be moved to ask a question similar to that ancient riddle: can god make a stone he cannot lift? Can Raster make a performance killing kluge that he would flinch at? Learn my son, learn. Only after can you be prepared to work on gnome-pannel.
BZZZT! WRONG!
You write shit like that for a living while wearing a nice suit and talk about e-ventures and you get a big car and a silicon wife.
Trust me, I know!
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
www.the5k.org has a great contest for writing a web page/site under 5k (html, javascripts, images included, no server scripting). As much as I dislike javascript there are some pretty impressive entres in the contest. It won't be pretty - as in the code will not be commented, and white space is stripped out - but those brave enough to go figure out the obfuscation will certainly find some of it quite "beautiful".
Hey, can I put a commercial for myself on Slashdot? Please! I could talk about what got me into programming, then when they've taken the bait I can switch and start selling myself as a consultant. ;)
I didn't pay for my operating system either
I agree that comments are very important in external headers, and I usually try to give an overview of the class and its purpose. If you don't have the class source code, this is of course vital.
Code should definitely have *some* comments. I just mean that the ideal amount of English compared with code can be much lower, depending on which language you're using. In essence, the purpose of higher-level languages is to express the code in a way that's closer to English - so less English comments should be necessary.
What I don't want to see is a comment which would be redundant, if only it matched the code. Or crap like this:
a += 1; // increment a
I think my opinions are close to those of Stroustrup. He has spent more time explaining them than I can. I agree with more of what he says than I disagree with. And he did invent C++!
I didn't pay for my operating system either
anybody know where to find this? I have not been able to construct a search that doesn't find a lot of stuff I'm not looking for.
----
trolls swarm slashdot. when will plastic get FPs and goatse?
You can read a version at Microsoft but if you, like me, don't even like going there then there are other copies on the web. There's one at apostate that has some additional addenda that might be interesting (I didn't look too closely) and one here that has some rather mindless criticism sprinkled in. Here's a plain text version.
A variant of this naming convention that most people have heard of was also adopted by Microsoft for use with Windows. The version Windows uses is a steaming pile of shit and is a complete perversion of the original idea, so don't base your opinion of Hungarian on Windows or on criticisms from people who only know that version. If you have the good sense to despise Windows's Hungarian because it is the opposite of abstract, you'll love the real thing. It can be hard to get used to Hungarian, but I don't know anybody who has gotten used to it who was able to stop using it.
BTW, he also worked at Xerox PARC where he more or less "invented" WYSIWYG word processing, before he succumbed to the evil empire and became charless@microsoft.com, father of Microsoft Word.
----
trolls swarm slashdot. when will plastic get FPs and goatse?
"Good art" can be found in museums. That doesn't mean it's all the same or obeys one definition, but it's still generally agreed to be good and is at least as instructive to look at as a discussion of the definition of good art.
----
trolls swarm slashdot. when will plastic get FPs and goatse?
I had to hack fetchmail recently to keep mail from bouncing when fetched from our isp to our internal postfix server (see the dropdelivered option).
I found hacking the source extremely easy, the source being modular and well documented.
This program could serve as documentation on how mail protocols (SMTP, POP, IMAP, etc) work and how to implement them.
Yay for fetchmail!
--
Semantics is the gravity of abstraction
The book is "Design Patterns" by the Gang of Four
Your pizza just the way you ought to have it.
didn't microsoft give the source code for windows 3.1x ?? that should be a good read :)
Dude, take that back! It's not my fault that we're a bit more alert here in Canada! Btw, your post was funnier than mine. But mine was first! Ha! :-)
What exactly is the question here? Isn't it "Ask Slashdot"? I see no question marks in the entire message.
get the last word of "The day is at its end."
I don't find this beautiful... elegant, maybe. At this particular moment (which is tainted with fatigue and may not represent my usual thought process) I think that code beauty is about getting something done in an efficient way, taking every advantage available in the language and execution environment. Obfuscated code can be beautiful if it does what it does better than a more easily read version of said code can do.
Okay, enough of this for tonight... Eight hours of fluorescent light + 6 hours of staring at a CRT = a tired brain..
When I was in the 11th grade in high school I was coding using borland C++ 4.5 which did not allow me to use 32 bit instructions. So I figured I could cheat the compiler and do something interesting to get maximum performance on a copy from a buffer copy to svga framebuffer:
//save regs
//get vram seg
//point extra segment to vram
//get buffer location
//start at offset 0
//dwords to copy
//set dir to forward
//32bit movsd
unsigned long far *dbtemp= dbdw[0];
asm {
push ds;
push es;
push bx;
mov bx, 0xA000
mov es, bx
lds si, dbtemp;
mov di, 0
mov cx, 16384
cld
}
__emit__(102,243, 165);
This was 3 years ago now and I still keep the file that this snippet is in around. How many C coders out there know of the __emit__ function anyway ?
any body think of this yet?
o et ry&lastnode_id=481
;;)
http://www.perlmonks.net/index.pl?node=Perl%20P
#!/usr/bin/perl
join $me,
my $gorgeous,
and listen $carefully, $please;
eval { the circumstances } and
warn $me if not $comfortable;
for ($i; "understand";
"but please, let us" ) {
lock our $lips,
and link $us, $together;
grep $me, $now, if $ready, and "i shall be happy";
unlink our $reservations
and do { $me, $passionately, }
until $at, last, our $desires_are_satisfied };
sleep $happily, my $dear_one;
for (our $experiences_have_been_wonderful,
and our $time_together_will
{ last }
It could use some optimization to be sure, but it sure is pretty.
Hello!
We plan a course for our students concerning the Apache Source Code. The goal will be to create a good code documentation for developers and to extract concepts and solutions for common design problems.
I believe that the analysis of existing (and running) software is an important task for someone working in the software industry, because in most cases you join a project where you have to alter or extend existing code and you have an enormous advantage if you quickly understand how it works.
I am planning a project to make available all the good ideas and solutions hidden in the source code of so many good open source projects. The analysis course is just the first step towards an encyclopedia of software engineering knowledge.
I would suggest that if you're interested in compilers, parsing and so on, you check the source of the GNAT Ada95 compiler, which is in the opinion of most of those who looked at it: elegant efficient and really readable Of course, it is in Ada...
...et le pire de tout c'est qu'en plus on est contents!
Beautiful code is not only defined by the quality and efficiency of it's statements. It's also defined by the quality of the design of the whole, and in the maintainability of the app/code. That's one of the reason why I really like digging into Darren Reed's code of IP Filter, I think it is ressourceful to see good code like this, that implement standards correctly and cleanly, and that use the features of the language without abusing them.
Benoit Beausejour SmartWorker Project (www.smartworker.org)
In line with previous replies, beauty in code certainly is in the eye of the beholder, or at least in the realm of the problem domain. To my mind the only definition of beautiful code is code without ugly features, which are somewhat easier to define. To my mind, the principle causes of ugly code are:
So, logically speaking beautiful code should emerge when the above errors are avoided for an interesting problem. The first point is trivial and has been covered by other replies "The software must work". The second point is dear to my heart - absence of commentary is bad, but banal, contradictory or otherwise invalid annotation is far worse! Encapsulation must be considered a central concept in any software engineering effort, and this black art should be considered fundamental. Redundant code is misleading and can have performance implications too. Adherence to house style for code is a considerable cause of strife when programmers collaborate... however a simple consistent style is important to avoid confusion. Finally, employing appropriate techniques form the conceptual link between beautiful code and beautiful programs.
A while ago I read a great book: Programing Pearls, which discussed some of the most elegant aspects of programing the author had encountered (along with historical context). It's a great read and in my opinion highlights some fascinating historic revelations in software development... by no means a "how-to" book, nor up-to-date, but enlightening non the less.
see http://www-swiss.ai.mit.edu/~jaffer/SCM.html for concision, cleverness, clarity and effectiveness.
It is a large, very well structured c program that shows how you can write object oriented code without using C++. I haven't looked at in a while, but I know that I learned a lot from it a few years ago.
http://www.lysator.liu.se/~alla/dia/