damienkatz.net — You know those crappy programmers who don’t know they are crappy? You know, they think they're pretty good, they spout off the same catch phrase rhetoric they've heard some guru say and they know lots of rules about the "correct" way to do things? Yet their own work seems seriously lacking given all the expertise they supposedly have?
Nov 24, 2007 View in Crawl 4
stripesNov 25, 2007
His main thrust for most of the items isn't that X, Y, or Z is normally bad but that it is "crazy" to insist that X, Y and Z are ALWAYS bad. So for example he says insisting that short functions are ALWAYS better then long ones is "crazy". Saying "5 10 line functions are almost always more readable then one 50 line function" is OK.Or at least it looks like that is his main thrust, and I'll agree with "inflexibly applying 'good code style' rules tends to be worse then generally following the rules, but sometimes breaking them".Sort of like the #1 rule of photographic composition "ignore any or all of the following rules if it makes the picture better (but if you don't know why breaking the rules is the right thing to do this time you may well be wrong)".So "avoid design patterns" is a crock (they are frequently useful). "Shoehorning all of your code to follow at least one design pattern even when none apply" is good advice (sometimes no design pattern applies).Now maybe I'm giving too much benefit of the doubt, and he is a loon, but I don't think so. Almost all his points focus on "always", and his clarifications in the comments I read reiterate that, and add an "always" to a section he missed.
th3wiz4rdNov 26, 2007
I could see using UML to break a large project into smaller pieces (especially when you have multiple people). When I read that part though ("You model all your code in UML before you write it." ) I pictured some idiot drawing a UML diagram for every line of code then going and writing it afterwards -- that is very lame. The sad thing is I had professors in college that refused to do it any other way -- one would even write the actual code inside the diagram (wtf is the point of that?).
deathwearsahatNov 27, 2007
My current task is refactoring/repairing 50 mobile computer apps that were generated entirely by taking a previous, unrelated app, copying and pasting the ENTIRE thing, and changing 5% of the code. Do not do this. End result is 50 apps using 4 times as much memory as they should.It is a good thing the person who fudged this stuff together is no longer with the company.
cpoveyNov 30, 2007
Ever considered working for Microsoft?
groovepapaDec 4, 2007
agree. I instantly dug this for #1. it's amazing how arrogant some Java dev's can be.
skim1420Dec 5, 2007
I don't know, from my world's point of view the author doesn't take into consideration that IT's biggest costs are maintenance, not development. Many of the "wrongs" he cites are actually good practices in the long run. I'd guess CIOs of major organizations would tend to disagree with this list.
miltonlab5 days ago
lectura pendiente