zahnster

So, the blog’s been pretty dead recently, which is the exact thing I didn’t want to happen. But what can you do. The ‘life’ has been a bit hectic as of recently, but things are moving in the right direction, so it’s a good thing.

Today I feel like ranting… but not just any kind of rant. Hopefully it’ll be a constructive rant. If that makes any sense.

So my rant is all about programming standards. Over half of my job consists of going into existing code and performing maintenance on it, and to be honest, it’s one of my least favorite parts of working in the web industry. Maybe I’m just slightly obsessive over the cleanliness and readability of my own programming, but I’ve always been a really strong believer that the code you write should have meaning; six months down the road you should be able to re-open your old code and know exactly how it works.

The thing is – this is where the rantiness comes in – the standards of programming needed to keep your code maintainable are so simple that anyone can incorporate them! Also, these techniques were taught to me in the most fundamental of programming classes I had, dating back to high school. It doesn’t take any more time or effort, and the benefits you gain from it far outweigh any possible headache.

So what are these techniques? Let me mention a few of them:

1. Use variables with meaning
   Seriously, why isn’t everyone doing this? I know typing $x might be slightly quicker to type out as you’re programming, but six months down the line are you really going to know what $x = $a*$b+$c is going to mean? Are other developers who come in to maintain the application going to know what it means? Chances are they won’t – and they’ll waste more time trying to figure it out than the time you saved by typing ten less characters.
2. Comments, comments, comments!
   I always comment my code – perhaps I get a little too verbal sometimes, but I like explaining my programming process as the code flows. For instance, if I’m creating a function, usually I will have a short description of the function before it opens, and then within the function I’ll have brief, one-sentence comments on ‘code milestones’. In addition to making the code more understandable by providing other developers (and even yourself) with explanations of what your code blocks are trying to achieve, it helps out during the programming process as well – often times I’ll ‘comment out’ my process before I even start to write any code.
3. Consistency is king
   This one, I’ll confess, actually does take some effort, but not as much as you might think. When making changes / additions to existing code, I’ve always found that it’s best to try to emulate the original programmers ’style’, as to keep consistency through the life of the app. Now, I’ll stick to the standards mentioned above; just because the old developer was using $x for everything doesn’t mean I’ll keep that, but with things like the use of include files, functional vs procedural programming flow – sure I’ll try to copy that as best I can. That way, when the next developer comes in, they don’t have to wrap their brain around 2 (or 3 or 4) different programming methods.

Like I said before, these are fundamental things, and it’s just a short list. Part of me even feels weird making a blog entry about something so obvious, but this type of programming is (for some reason) not being picked up as it should. Hopefully one day I’ll live in a world where I don’t dread going into someone’s old script for some maintenance.