Lines of Code are Not Evil

I don’t know what it is about programmers that gives us crack withdrawal itches any time we see “unnecessary” lines of code, but our need to get that fix sometimes takes things way too far. I see way too much code where the programmer has sacrificed readability and understandability in the name of saving a line or two of code. Sometimes it’s okay:

  Collection c = new ArrayList();
  someObject.setCollection(c);

     (becomes)

  someObject.setCollection(new ArrayList());

That’s just damn good refactoring right there. And while I encourage you to save lines where it makes sense, sometimes we take it way too damn far. For the love of God it’s not a sin to have an extra line of code or two. At some point someone is going to need to read that code and, I’m sorry but if I have to read this line of code that you wrote I’m going to show up at your house in the middle of the night and go fucking monkey nuts crazy on your ass:

  for(Iterator i=CollectionUtil.getIterator(list);list.hasNext(); ) callSomething((String)list.next(), (x > 5 ? foo() : bar()));
  (see doesn't even fit)

Less lines doesn’t automatically make your code cleaner. Code is meant to be read top-down. Write it that way.

  Iterator i = CollectionUtil.getIterator(list);
  while( i.hasNext() )
  {
      String s = (String)i.next();
      callSomething(s, (x > 5 ? foo() : bar()));
  }

Yeah, I used a few more lines but you’re not going to get confused and get the urge to punch a baby reading the second version. Seacrest out.

Why Comment Your Code?

There are countless posts and arguments on whether commenting your code is good practice or not and the debate is as futile as PC versus Mac, Pepsi versus Coke,  or David Lee Roth versus Sammy Hagar. Your mind is made up and few arguments will sway your stoic position. Ignore the standard arguments that usually end up with the following conclusion: Good comments are useful, bad comments are not.

Good. Great. Write good comments, whatever. But here’s the brutal truth. Make sure you’re sitting down because I’m going to go all Scorpions on you and rock you like a hurricane. Are you ready, baby?

You are not as good of a programmer as you think you are.

You, like me, and like every other programmer on the planet, write utter crap from time to time and usually other people are going to have to work with it in the future. The problem is that you are you. And to you, your code is always 100% clear so anyone who doesn’t get it from just reading your function/variable names is on par with a VB programmer. Not to shatter your illusion, but your digital shit does stink. So do your fellow programmer a solid and write some plain-English comments in your code so that we can understand the brilliance that you were after when you lost it trying to represent it via code.

Also for what it’s worth… PC, whatever’s on sale at the store, and David Lee Roth (Right Now was good, but listen to VH’s self titled album and the choice is clear).

Who the Hell Wrote This?

After working on the same software for the past 8 years you inherit a lot of old code. As nice as it would be to tread new ground all the time, you often just add small enhancements to existing features. The drill is pretty simple. You figure out what needs to be added, find a relevant part of the code and dive on in. Yes I’m leaving out design and all that good stuff, but that’s not part of the Dude’s story. Every now and then, however, while looking for that magic entry point (that came out dirtier than intended) I find myself staring at some of the most unintelligible, god-awful code I’ve seen in a long time. Long methods, nothing pulled out into separate classes, hard-coded values, and needless complexity in otherwise simple code. And just as I get ready to submit some choice lines to The Daily WTF, it clicks.

I wrote this.

It’s a sobering moment when you realize just how much you can suck at what you do. With this revelation comes the 5 stages of “I suck at programming” grief:

• Denial – There’s no way I could have written this trash! I think [insert innocent co-worker here] also worked on this a little bit and he must have written a lot of this uglier stuff.
• Anger – Why the hell did I do this?! Now this project is going to take twice as long because I have to work in the context of this pile of digital turds. Thanks, me! What a douche.
• Bargaining - Maybe it’s not as bad as I thought. I didn’t have a whole lot of time to put into the initial design of the code. I’ll just keep with the terrible paradigm established before me and bolt on another inextensible method that does what I need.
• Depression – Has it truly come to the point where I abandon every single design pattern I’ve learned and tightly couple all of my objects just because it lets me finish the project a few hours sooner? I feel so dirty.
• Acceptance - I wrote bad code. It happened. While I can’t change the fact that it happened, I can take what I know now and refactor that code. Then when that’s done I’m going to write my enhancement code such that I’ll look back at this project and see just how awesome I can be!

But you won’t. One, maybe two years from now you’ll look back at that project and think that *it* was a festering pile of monkey crap, too. But that’s okay. Everyone writes bad code damn near all the time. I’d try to attribute this quote to someone but frankly it’s so ubiquitous in programming that I can’t find who said it first: great programmers aren’t born, they’re created. You’re gonna suck at programming. 10-15 years from now, you’re still going to suck at programming. The thing that separates the good programmers from the why-the-hell-would-anyone-hire-you programmers is that you constantly improve your skills.

But that only applies to the rest of you. I just finished up my most recent project at work and it’s the most awesomest code ever. So suck it.