| CARVIEW |
*
programming and human factors
by Jeff Atwood
September 28, 2004
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:
Your code sucks if it dogmatically conforms to a trendy framework at the cost of following good design and implementation practices.For example, Bob Martin recently raised the issue of dogmatically using private fields and getters/setters for a simple data structure (e.g. a DTO). If a field is transparently readable and writable why not simply make the field public? In most languages you can do that. Granted, in some you can't. For example, traditionally in Smalltalk all fields are private and all methods are public.
In general it's a good thing whenever you can throw out, or avoid writing, some code. Using a heavy framework generally requires that you must write a significant amount of code that has no business value. There are a variety of lightweight frameworks for Java that are a response to the heavyweight frameworks (e.g. EJB) that have become matters of dogma lately. O'Reilly has a new book out on this topic, coauthored by Bruce Tate.
When making framework decisions, consider if a lighter framework will do the required job. Using something like Hibernate, Prevayler, Spring, PicoContainer, NakedObjects, etc. can be a real win in many situations. Never blindly adopt a heavy framework just because it's the current bandwagon. Likewise, don't blindly adopt a lightweight framework in defiance. Always give due consideration to your choices.
Of course, the real problem with software development is the users. It's unbelievable. They've caused problems with every program I've ever written.
"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.
Astrochicken on July 23, 2008 07:38 AMI 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...
Russ McClelland on July 25, 2008 09:01 AMThe 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.
https://stroypostroy.ru/
| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email