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.
Thread beginning with comment 549265
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: Good article
by henderson101 on Fri 18th Jan 2013 13:59 UTC in reply to "RE[7]: Good article"
Member since:

I've been working with a contractor (politically, I had nothing to do with him being hired for the project - I would have vetted him better, but he's actually being subcontracted to a third party who seem happy not to care.) He doesn't believe in inheritance. It drives me absolutely insane. He will do exactly as you say. He's very pattern orientated, but prefers using interfaces and single level hierarchies. I came from a Delphi background and I'm used to using interfaces to create a contract that is implemented in a class, but also creating hierarchies that build up reusable blocks of code. The flat namespace approach really doesn't make sense to me at all. Example: I have a requirement to implement a set of classes to process allocation of a table based set of prices, which differ by application. I personally would create a base class with the commonality in it, then build classes on top of that to implement the specifics. I would more than likely create an interface with the specific details for accessing any of the children generically, I'd utilise abstract and virtual methods/properties to ensure the interface could be applied at a level where it made sense. He on the other hand would create one interface and implement a new class for each different use. His argument is that inheritance causes complexity that can be avoided, but I've worked on some stupidly complex class hierarchies that were poorly designed and still simpler and easier to maintain that a class per implementation of the functionality with lots of boiler plate code included.

Edited 2013-01-18 14:04 UTC

Reply Parent Score: 2

RE[9]: Good article
by Alfman on Sat 19th Jan 2013 05:50 in reply to "RE[8]: Good article"
Alfman Member since:


It might be a matter of preference. I often find that I don't like the way inheritance is used and strongly prefer interfaces myself. This is one reason I like .net over C++. The "IS A" relationship and "HAS A" relationships often tread very thin lines and with the exception of polymorphism the differences become syntactic rather than expressive.

Reply Parent Score: 2

RE[10]: Good article
by henderson101 on Sat 19th Jan 2013 21:25 in reply to "RE[9]: Good article"
henderson101 Member since:

Yeah, inheritance doen't soleve every problem. But it has its applications. In the case where the same boiler plate code is almost cut and pasted in to multiple classes with no variation, it makes a lot more sense to create a base class and inherit tose characteristics. Don't get me wrong, I don't advocate inheritance over sense ("inheritance madness" as a Turkish co-worked used to call in back in the '90's), but I also think it is important to use all the tools you have effectively, not overly complicate or convolute your code and leave the least margin or error for future maintainability. Cut and paste flat hierarchies are prone to feature disparity when one developer changes an aspect in some but not all classes and then introduces unexpected behaviours. I'd rather see a helper class with the base implementation and then the use of the adapter or mediator pattern with full encapsulation be used than absolute cut and paste.

Reply Parent Score: 2