Ranting is not my favorite way to express, I’m more like a constructive guy. But also, the blog is a reflection of what I’m doing right now. And for the title of the post you can guess I’m not doing a lot of GIS.
Lately I’ve been spending my time reading some questionable code, which made me think about the habits of programming. There’s no exact science here, but it is true that bad handled code can explode really fast creating a series of problems.
- Maintenance hells.
- A bug fixed, uncovers another bug.
- Hard to get somebody up to speed.
- Lots of snorting (iup that’s me).
- Clear increase of gray hair (iup, that’s me).
I started drafting a post about this topic. Then, it exploded in size. So I decided to split it in digestible bits of enjoyment.
The original title was: The Code Apocalypse but I settled for something milder because… that’s my style :-D.
Variable Names
Let’s use the common sense. And always think that you are writing code for somebody else.
Don’t name a variable 'a'. Please, don’t do that. It is acceptable for things like indexes ('i','j') because that’s a common representation of indices (see what I did there?) in maths and programming.
Things like math formulations are also right for me (one of the cases where you could write a), for example, the quadratic equation:
But that’s ok. It’s a formula. As long as you tell me that you are using this formula, and name the variables accordingly everybody should be fine.
But what is totally misleading is doing something like the following:
var n = "the name of something";
var o = "the output of something";
var r = "the result of something";
This has a couple of side effects:
- Clear syntax, not clear semantic (what does it mean
r = o + n?). - I can’t search all the uses of that variable!. probably the most infuriating part
But here’s the scoop. Long identifiers are also not the best (that’s why probably people call variable naming an “art” sometimes).
var NameOfThePerson1 = "";
var NameOfThePerson2 = "";
var OutputOfCommand = "";
Not too long, and not too short. 😀
More often than not, every company/group/project has an style guide, or follows something like PEP8 (for python). If that’s not the case, find/create one and stick with it. Different programming languages may have different approaches for standard notation (Camel Case, hyphen separators, Hungarian notation etc).
Be consistent, stay consistent.
Castells 