On the Revolution Systems blog, the author has a good, common sense approach to making source code more programmer friendly: use better names and be consistent.

Though this is kind of like a “duh” moment, it’s amazing how frequently these practices are ignored. I’ve looked at a lot of source code that was simply horrible because the variable names were concise to the point of being worthless; for example, $tobj could be “temp object”, “time object”, or even “total observational bone joint”. You get the idea.

Alternatively, I’ve also seen code that had an object named something like “Group.classObject.Frame.Widget1.VariableTimer.CountdownToNextEvent”. Even using auto tools like in Visual Studio, it’s still a pain in the butt to write out a name like that every time.

Consistency is another big item. There always seems to be a push to standardize things, especially at my current shop. But even with all the SOPs and policies, I still haven’t actually seen anything discussing variable naming conventions, commenting standards, or even how source code should be put into the code repository. I think part of this is because we rely on the configuration manager to handle things like these; just give the code to the CM and he’ll take care of the logistics.

But what happens when he’s not around and you have to do it yourself? How do you train new people? What about audits or showing senior management how work is accomplished? Standards are made for a reason. They make life easier for everyone.