It’s a different kind of stage fright – you work on a site for weeks or months, and you know deep down that the quality of your work is solid. You’ve gone through the site with a fine-toothed comb, testing the ins-and-outs, and you finally feel ready you hand it off to your peers. You hold your breath, because your application is now, for the first time ever, completely in someone else’s hands. There are no more walk-throughs; This is the real deal.

Will they find bugs? Will they do some combination of events that you never thought of that just happen to be devastating to the program – something you overlooked – something completely obvious that will make you feel (if not look) like a brainless fool? Are you sure you uploaded every file you needed to?

These are the things that run through my head every time I near the completion of a web project. It’s the time when you hold your breath and hope that your peers and clients are blown away with your product (or at least satisfied).

That’s my type of stage fright.

As a PHP developer, I’ve been very tempted to create a mini-app, but time and ideas have been short. However, the other day I took a ‘political quiz’ mini-app, and the results of the quiz inspired me.

For those who know me well, you should know that I’m a very firm believer in the Libertarian party and philosophy. So it was without surprise that my political quiz results were personally disappointing – it’s a line graph between being a ‘liberal’ and ‘conservative’. I fall in the middle of that, pretty much, with a slight lean towards the liberal side – but I really have a personal problem with being associated with liberals (to be fair, I have a problem with being labeled ‘conservative’ as well). The real political spectrum is 2 dimensional, not 1, so during the next few weeks I am going to be designing and developing a Facebook app – a short political quiz, using the Nolan chart as a way of measuring results.

It should be an interesting learning experience.

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.