The exceptional beauty of Doom 3’s source code
Linked by Thom Holwerda on Tue 15th Jan 2013 21:24 UTC
General Development "I was really excited to write this article, because it gave me an excuse to really think about what beautiful code is. I still don't think I know, and maybe it's entirely subjective. I do think the two biggest things, for me at least, are stylistic indenting and maximum const-ness. A lot of the stylistic choices are definitely my personal preferences, and I'm sure other programmers will have different opinions. I think the choice of what style to use is up to whoever has to read and write the code, but I certainly think it's something worth thinking about. I would suggest everyone look at the Doom 3 source code because I think it exemplifies beautiful code, as a complete package: from system design down to how to tab space the characters." John Carmack himself replies in the comments.
E-mail Print r 1   68 Comment(s) http://osne.ws/klq
Thread beginning with comment 548953
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Good article
by WorknMan on Wed 16th Jan 2013 02:22 UTC in reply to "RE[2]: Good article"
WorknMan
Member since:
2005-11-13

I actually prefer the first way myself, even though I can read the second. In general, I don't mind code that's a little more verbose, if it's easier to read.

Obviously though, there is a tradeoff between readability and verbosity; if you're using 30 lines of code to do something that could be done in 3, you could probably do better. On the other hand, if those 3 lines of code look like modem line noise on a terminal (as many perl scripts seem to end up looking like), I'd rather have the 30 lines ;)

Reply Parent Score: 3

RE[4]: Good article
by Laurence on Wed 16th Jan 2013 09:57 in reply to "RE[3]: Good article"
Laurence Member since:
2007-03-26

On the other hand, if those 3 lines of code look like modem line noise on a terminal (as many perl scripts seem to end up looking like), I'd rather have the 30 lines :p

But again, this is all down to experience. A good Perl developer should be able to read that code easily enough.

Where I draw the line is over-engineered regex:
* they can be completely unreadable - even to many seasoned developers
* and they usually run slower then multiple, more precise, expressions.

A basic example is a 'trim' command. The following will remove spaces from the start and the end of the string:
s/(^\s|\s$)//
However it's actually computationally less efficient then having two separate replaces:
s/^\s//
s/\s$//

So the real issue isn't Perl's syntax, it's that you're either reading bad Perl code, or that you're not familiar enough with Perl to understand it's syntax.

And this is my problem with people who bang on about how bad Perl / C++ / etc is for readability vs Python / VB / etc. Those people are generally inexperienced developers and thus not really qualified to comment. It's a bit like saying simplified Chinese is less readable than English, because I'm an English speaker who's only exposure to Chinese is from friends of that heritage.

Reply Parent Score: 2

RE[5]: Good article
by Brendan on Wed 16th Jan 2013 15:58 in reply to "RE[4]: Good article"
Brendan Member since:
2005-11-16

Hi,

Where I draw the line is over-engineered regex:
* they can be completely unreadable - even to many seasoned developers
* and they usually run slower then multiple, more precise, expressions.


The other problem is adequate error handling.

For me, adequate error handling means telling the user what was wrong with descriptive error messages; like "missing space between foo and bar", "bad character after foo", "bar needs to be at least 4 characters", etc.

With a single over-engineered regex the only error message you can do is "Something was wrong but this code is too stupid to tell you what"...

- Brendan

Reply Parent Score: 2

RE[5]: Good article
by WorknMan on Wed 16th Jan 2013 16:32 in reply to "RE[4]: Good article"
WorknMan Member since:
2005-11-13


A basic example is a 'trim' command. The following will remove spaces from the start and the end of the string:
s/(^\s|\s$)//
However it's actually computationally less efficient then having two separate replaces:
s/^\s//
s/\s$//


On the other hand, why not have a goddamn Trim function? It's infinitely more readable than any of this 's/' crap. You're trying to make excuses for a write-only language who's code looks like line noise by saying, 'Well, a good programmer should be able to read line noise' ;)

Edited 2013-01-16 16:35 UTC

Reply Parent Score: 2