Skip to main content

4 excuses to write poor quality code

1. This module can't be unit tested, it's too [insert-adjective-here].
      • If it's too [insert-adjective-here], how do you even know it's working in the first place? And what about after we extend it with a new feature?
2. Breaking logic into methods incurs a performance hit.
      • So does inheritance, and separation into classes. Does this mean your design should consist of a single class with a single method where all business logic is placed?
3. Commenting code is time consuming and hinders development.
      • Same goes for going to the bathroom, but you don't see people skip that, do you?
4. Coding conventions are too rigid, I'll call my fields whatever I want.
      • Now that's just an excuse to write ugly code.

I guess one cannot get away with such statements without saying there are always exceptions, so here it is - there are always exceptions. I'm not talking about the corner cases you stumble across once in every who knows how long, I'm referring to the everyday coding practices which account for most of our codebase.

If you said "true that" to any of the large font-ed text - you're sitting on a time bomb, i.e, that time you'll need to change, extend, or debug your code. In a way, you're just like the fellow below. You may not have the same stylish tie, but other than that you're pretty much in the same condition when it comes to well being.


Comments

  1. I read in some forum:
    "Coding conventions are too rigid, they restrict my creativity."
    :-O

    ReplyDelete

Post a Comment

Popular posts from this blog

Sending out Storm metrics

There are a few posts talking about Storm's metrics mechanism, among which you can find Michael Noll's postJason Trost's post and the storm-metrics-statsd github project, and last but not least (or is it?)  Storm's documentation.

While all of the above provide a decent amount of information, and one is definitely encouraged to read them all before proceeding, it feels like in order to get the full picture one needs to combine them all, and even then a few bits and pieces are left missing. It is these missing bits I'll be rambling about in this post.

Dependency Injection - The good, the bad and the ugly

The Good
Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI, numerous DI frameworks have arisen (Spring, Guice, Castle Windsor, etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application.

I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same.