Warning: this may be the most valuable blog post you ever read.
I’ve been developing for a long time – the first programs that I first wrote that other people were using was back in 1992. At the time, I was the only one working on the code and there was no reason for others to get involved. In fact back then it seemed that we were driven by one-upmanship and sharing code was almost unheard of, unless you had to get an assignment in the next day and you had some stupid reason for not being able to complete it, then someone might take pity on your ass and bail you out. Back then, consistency wasn’t important – what mattered was whether the code ran or not. Even better if it ran and you got paid.
If there’s one thing I could share with you about my experiences over the last twenty years, I would have to say that it’s this. Be consistent.
Consider the following code:
<?php $query = 'select * from customer where id = 123'; $result = mysql_query($query); $row = mysql_fetch_assoc($result); $identifier = $row['id']; echo $identifier; ?>
We’re fetching a row from a table and echoing out the id field. The code above doesn’t really matter, but what does matter is the inconsistency. Can you spot it?
The inconsistency is that the field in the database is called “id” and we put it into a variable called $identifier. This does not break the code, but it does mean that you have just introduced an inconsistency that will bite you.
That’s a pretty simple example, but imagine those kind of differences across an entire application, a database schema or even your whole organisation. It happens, and all too frequently.
The consistency issue isn’t a coding style issue – let me be very clear on that – it’s more a culture issue. You need to work hard to spot these inconsistencies in your organisation and nip them in the bud really early. And they may not appear in code either. You can find them anywhere from code, to documentation, to common usage in discussions in the workplace.
If you let these inconsistencies propagate you’re going to have to deal with them time and time again. Here’s a real world example: I am dealing with a system at the moment where products are identified by their SKU number (Stock Keeping Unit). This number has been referred to as the following in various places (code, documentation, wiki pages, emails etc):
- ItemID (yes, case makes a difference!)
- Identifer (yes, misspelling of Identifier)
The boat has sailed on that one – there is no way that this situation could be wrestled under control, you’ll have to do what you can if you come across this. But if you have the luxury of a fresh project then it’s time to gather your troops and spell it out on the board – CONSISTENCY. Drum it into your processes and procedures, your code reviews and commit messages. There’s no excuse for any inconsistency at all – especially when it will cost you in time chasing bugs because the value isn’t turning up like it should or the record isn’t saving.
If you haven’t already I highly recommend putting together some coding standards for your company – or even for yourself. And follow them to the letter. It doesn’t really matter what style of indenting you use (K&R, Allman, BSD KNF, Whitesmiths etc) – what matters is that you’re … you know what I’m going to say don’t you.
Feel free to borrow from the Turboweb Coding Standards (which in turn were based on the Drupal Coding Standards). Make sure that your new starts read your coding standards and understand them. And take time to teach them well.
Addendum: Ironically I managed to misspell the title of this blog post, I’ve now corrected it but as the link is out and about on various social media sites I can’t change that, therefore if you’re viewing this post by itself you’ll see that the URL says “consitency”