Why Your Code Sucks... and Mine Doesn't

OK, the title is just Why Your Code Sucks, but you know you were thinking it. The article may not be as gramatically (sp) correct as I would like, but it's got some solid advice. My favorite is rejection of dogma:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/09/why-your-code-sucks-and-mine-doesnt.html

Your code sucks if it dogmatically conforms to a trendy framework at the cost of following good design and implementation practices.

I’ve heard a similar argument for the use of goto in C code.

Unfortunately, I cannot agree with Bob Martin’s example involving private members with getters and setters in basic data objects. Nowadays, I never ‘write’ getters and setters. My IDE will do it for me.

The same is mostly true for overly-complicated technologies like EJBs. A decent Java IDE should be able to spit out the mundane parts for you. I guess my point is that many of our design practices are supplemented by tools in order to make those practices livable.

I agree, that is the inexerible march of technology: implement something, find problems, design solution, implement solution, find new problems. This works best when you take take good ideas, patterns, idioms and codify them so that it becomes transparent to the next generation.

Bu the important part is to know why we fight so to speak. Understanding history helps to ensure that we don’t make mistakes. We use properties instead of public attributes because compilers didn’t create good representations of our classes if we later decided to distribute them across the wire. Is that true today? I don’t know. Maybe under the covers the .NET compilers actually generate a Get/Set method, in which case using public attributes is actually equivalent to using public properties.

I think speaking in terms of generalities, you have to first question but then try to understand what brought the industry to a particular point to begin with before you start diverging from what the rest of the stream is doing…

But “coding” consumes time and money. If you focus about business you must spent less time on development and more time on business planning.

But “coding” consumes time and money. If you focus about business you must spent less time on development and more time on business planning.