Linked by Thom Holwerda on Tue 15th Jan 2013 21:24 UTC
"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.
Thread beginning with comment 548980
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
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.
* 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
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
Member since:
2007-03-26
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.