The importance of consistency

Bit of a background

When I was a kid I used to retype these programs from computer magazines. I didn't do much of my own coding, and frankly, back then it didn't really matter how I coded. Nobody would ever see it again.
Then at Uni we coded Pascal, and that was just fine, the code snippets grew as the assignments went along, but again. It didn't really matter how I coded, because the only one to view the code was the (evil ;) ) teacher, so as long as I made my own code legible to myself, I was quite happy.
Then I started coding ColdFusion and PHP for a living, again, most projects weren't large enough for a bunch of coding standards.
However, later on my professional life, I've battled with other people's code... Not thinking much about the fact that I left my own code behind me for some poor sucker to wade through (before he decided to rewrite my cr*p).
Anyway.. Point is, that just like me, you probably wrote some insane stuff in your days. And I don't mean those hip "insanes" either, I mean truly certifiable stuff.

What to do...

Whillst I won't preach about Coding Standards this time, I do have to point out that a unanimous way of coding is a "Good Thing"(tm).
OK, OK, consistency! That's the keyword. Well, apart from legibility, but that's another story.
Back to the topic... Consistency.
The reason why being consistent is to avoid confusion. See, being confused is a "Really Bad Thing"(tm). And the reason for that is that if you're confused, you're going to have to take your thoughts off what's important. Usually being creative and productive. That's really bad. You want to be able to focus on what you're supposed to do, not focusing on figuring out what the h*ll is going on, and what the f**k the other devloper had in his head when he wrote the misspelled and irrational code-poetry you're wading through.
Being consistent eliminates all that - and it actually isn't that difficult either. Let me give you a few examples.

Example 1: Variable Naming

Now this example is really easy. You've agreed that you're going to use some sort of Hungarian Notation to name your variables. This is all good. It'll help your fellow developers distinguish between what's supposed to be in the variables, and what actually is in the variables when things go implants-upwards.
But this whole thing is completely useless when it's not used consistently.
This happened to me. I was working on a class, that had an instance of the of the database object, you know, so we can run some queries. Now, this DB object is commonly known around our neighbourhood as $oDB (being PHP we're using the $-sign). However, the stuff I was coding required some DB action to be passed in from the calling class. Naturally I just typed $this->oDB and happily passed the DB object into the code I was working on.
But it didn't work! Therefore I had to start to figure out why things didn't work. I obviously started with my own code, as I didn't think of something like as trivial as accessing an empty variable. I went through this and that, scratching my head, printing tons of debug stuff out to finally figure out that I didn't pass anything into my own code... it was empty.
When I had that figure out, I had to figure out how to fix it, luckily that didn't take too long, it kinda was there, hidden behind a few extends, but I managed to de-abstract that and add that little extra "o" onto the property name.
Yip, it was called $DB not $oDB.
By the way; if you're a PHP coder; this is a good time to switch on notifications in the error reporting; they'll tell you much more than you think.

Example 2: Databases

It's not uncommon to have a slightly different way of naming things in every different "language" you're using; SQL, XSL, PHP, Java, bash, etc etc. And whilst one common way of writing things would be best, the differences are quite quickly learnt.. The problem arises when you have several different ways of doing things, withing the same "language".
I've recently worked with a database that's got column names such as:

  • ID
  • users_name
  • users_passwrd
  • tagID
  • etc, etc..

I'll just list the differences here, and if you didn't pick them up (too much carbs for lunch?!) here they are:

  • All CAPS
  • Plural and singular combined in a non-meaningful way
  • Abbreviations that don't really do any good, compare password, vs passwrd - that's one character. Hardly worth it!
  • CamelCase mixed with "underscore_naming"

The simple result from this is that a developer can never ever trust his memory to code something, as writing out of his head. He'll have to abort his coding to go look for the appropriate column name.
This seeking will waste valuable time, not only for looking but then to get back into the zone to resum the coding... A slip past /. is probably merited before resuming work - especially after a frustration like that.
Fair enough you say - but I say Wait, there's more!!
In our 'modern' programming, we're storing our DB configuration in an XML file so that we can generate PHP based Object-Relational Mapping (ORM). Needless to say, unless you're using Ruby on Rails and adhering to DRY, this will mean that your now, inconsistent naming has been spreading like a virus to 3 different places;

  • Your Database
  • Your XML files
  • Your Programming code (PHP in my case)

Needless to say, the one-and-only-naming-convention doesn't exist, so "naturally" we'll now have three different naming conventions to adhere to - but in this case there's no single one way of adhering, so everybody does it a bit different.
The result of this is that a developer can't focus on writing the code but will have to focus on finding out what the current name is.
If you've got any sense now, you'll see how much time we're wasiting looking for stuff instead of being productive and focusing on our client's problem and business ideas.

Getting the point..?

That's just a few examples. Please let me know if you need more convinsing. I've got examples, trust me I've got examples.
Consistency is one of the pillars of "Good Programming". If you can't adhere to being consisten with the rest of the team, you really should recosider. The days when one person maintained one piece of software are gone. Gone gone gone, and most of us are happy about that. We like ideas like OpenSource, we like the idea of a community working together to fix things and make things better. As a loner you won't get far; not in the OS community, and definitely not in a corporate world.
Please, pretty please, adhere to the standards and make all our lives easier. You'd be surprised how quickly you set into coding to a given standard. The real joy comes when you're reading someone elses' code, and it just makes sense, as if you wrote it yourself. "Because you're worth it" to pun L'Oreal.