Code Pain Points

Everyone has their pain points when it comes to code and if you’ve read any of my posts that mention my self-diagnosed OCD, it’ll come as no surprise that I have mine. I was reading something this morning that touched one of those nerves for me and it got me thinking and, on a whim, I thought I’d document a few of them. This list probably isn’t even in the ballpark of exhaustive, but it’s a start.

I’d be interested to hear what syntax and techniques tweak others.

Nestled elses

I don’t know what it is, but my eyes can’t properly discern – not quickly, at least – the curly braces or even the else condition itself when the conditional else keyword is nestled between the closing curly brace of the if and its own open curly brace.

if ( $you && $trying_to && $annoy_me ) { echo 'nestle your elses'; } else { echo 'be kind'; }

For whatever reason, that syntax doesn’t work for me and it drives me just a little crazy.

Variable and Entity Naming

A previous post dedicated to this topic is available in the archive, but it bears another mention: name stuff according to what it is, not according to how you happen to be using it. An email address is always an email address. It will not always be a username. Really.

Indexed Arrays

Don’t get me wrong, there are plenty of good reasons to use an indexed array – queues, stacks, ordered result sets, etc. – but why use them when there’s not? How is anyone supposed to know, without a thorough knowledge of the application, that array [1] holds a width? I’m begging you, where it’s appropriate, use an associative array/structure/HashMap/HashTable. Please.

Arbitrary Line Breaks

No one likes seeing those looooooooong lines of code. The function calls with a seemingly endless parameter list (refactoring may be in order if this is the case) or maybe a markup element with lots and lots of attributes. Almost as bad, though, is splitting those long lines arbitrarily. Instead, break each argument/attribute out on its own line.

Instead of

function doSomething ( argument1, argument2, argument3 = 'default value', [...], argumentn = null )


function doSomething ( argument1, argument2, argument3 = 'default value', [...] argumentn = null )

This method takes up more space, to be sure, but it’s infinitely easier to read. You can always compress it before putting it in production if there is a need to do so. As I’ve said before, I prefer readability to performance.

Hungarian Notation

Is it still 1998? Is anyone still developing with VB? Rhetorical questions, both, but the number of data types available to most languages – including dynamically typed languages – is pretty small. It shouldn’t be that hard to keep track of whether a variable is an array or a string.

Obviously, these are some of my pain points. That doesn’t make the code wrong, it just means that when I’m granted the power to dictate code standards to the world (mwah ha ha ha ha), these are some of the practices that will end. You’ve been warned…

Subscribe0 Comments on Code Pain Points