Much of this prose, and definitely all of the funny parts, were stolen from Nick Parlante
Let's honestly review the conceptual landmarks most programmers use when thinking about how good their code is:
Publication Quality
Code suitable for publication in an article or textbook. Well-chosen algorithms and data structures, thoughtful overview and inline comments, perfect formatting, all the identifiers make sense, no coding hacks of even the slightest vulgarity. Something you'd be proud for anyone else to see---you'd include it with your portfolio for a job or grad school application. By the way, no one writes code like this by accident. It has to be a deliberate goal from the beginning.
Peer-Review Quality
Some companies have regular "peer code reviews" where a programmer walks their peers through their recent work to get feedback on their code or get approval before checking the code into production. Many programmers dread peer review because much of the code they whip out from day to day is a bit embarrassing. Companies like it because it scares the programmers into avoiding shamefully bad code. So peer review quality code tends to be mostly pretty good, but with occasional lapses that can be rationalized to an understanding audience- "I was going to decompose that, but I didn't have time." "oh yes, ha ha, on page 8 there are some utterly awful looking functions I whipped out to fix that VM leaking bug we had in May. I don't think it will port to the HP anyway. I think we're going to make the summer intern re-write it." "I'm going to go through and write documentation for that module and fix the variable names just as soon as I finish this current project I'm just right on the verge of finishing. Real soon now. I promise. Stop laughing at me!"
No-One-Is-Ever-Going-To-Look-At-This-Again Quality
Code that's being pounded out to solve a time-critical problem for the short term. Few comments. Cryptic names. Indentation is probably ok just out of habit. Instead of unifying common code, the programmer will just copy and paste chunks of code. Although this code was intended to be a two-week hack, sometimes such code ends up working its way into production code and plaguing programmers for generations to come.
Look-At-Me-I'm-So-Clever Quality
As with many other disciplines, some programmers can't resist the pleasure of noodling around in the obscure parts of a language. This is fairly understandable really--- programming languages are arcane creatures, and there's something pleasing about exploiting some obscure construct. But it's not a useful impulse really. It tends to go something like this..."By eliminating all the function calls and using this incomprehensible platform-specific feature that no normal person has ever heard of, I was able to reduce your whole program down to: for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); It's a full 24% faster, and it only took me a day." Efficiency is often cited. This impulse seems to come up in meetings and lectures too.
For reference, here's the official chart of what's impressive and what's not, as published by the Opinionated Programmers Council headquartered in Geneva, Switzerland and the Gates 1B-hallway.
| Code that works for all cases | Impressive |
| Code which was finished on time | Impressive |
| Code you didn't write, but got stuck with somehow, and yet find easy to deal with and maintain | Very Impressive |
| Elegant, clean code with the occasional bit of inspired cleverness | Impressive |
| A scarily-complex and optimized computation packaged in a nice, painless-to-use abstraction | Impressive |
| Nice-looking code which runs fast and ports with no work | Impressive |
| Code which works on many, but not all cases | Not Impressive |
| Nasty-looking code which is a pain to read and debug | Not Impressive |
| Thoughtless code which took little time to write | Not Impressive |
| Fast code which doesn't work quite right | Not Impressive |
Stanford CS department standards
In a Lord-of-the-Flies, uncivilized incarnation, many programmers will slip into No-One-Is-Ever-Going-To-Look-At-This-Again style code. Whatever takes the least time to type. But that habit doesn't translate well in the real world where programs need to work correctly and be maintained. On the other end of the spectrum here at Stanford, all we do is write, read, and think about code and how to write it better. Even if rarely attained, we should at least hold out Publication Quality as the ideal to shoot for. Peer-Review quality might still get an "A". Mediocre looking code that computes the right answer should get a "B". And so on down the scale for code which doesn't quite work right. The ideal for great looking code is quite high. Ask yourself: If you were to show your code around, is there any part which would seem like it could stand some improvement?