This article is aimed at the enterprise programmer. It aims to introduce sound practises around the naming of variables, with the objective of making life more productively busy for the maintenance programmer and keeping the technical writers busy enough to hang on to their meaningless little jobs.

Name your variable after your pet

This may seem non-intuitive, but there are very clear and tangible benefits. Right off the bat, the odds that another coder on your team has a mixed breed called Spot is infinitesimally small. What's more, thanks to the magic of namespaces even if that dolt working on the public API has a dog called Spot, the code will still perform as expected. And think of it: when variable names are thus reused, maintenance coders have fewer useless little pieces of distracting information to hold in their heads. They will thank you.

When you expose the name of your pet in the code, you are opening up as a human being to your team members. This helps to build team spirit, and it is common knowledge that it is team work as opposed to alleged competence, knowledge, aptitude, diligence, or hard work which gets jobs done. Your fellow team members will become closer to you, and they will by inference understand that much more about you and your coding style when they learn that your cat is called SlitWhittakersThroatAndDrinkHisBlood, for example. Or Spot. Maybe.

Use a lot of characters which require the use of the shift key, but not in succession

The longer it takes the maintenance programmer to type the variable name you used, the more time he or she has to think long and hard about what they are doing to your carefully crafted code. When you trip up fingers by mixing case indiscriminately you are providing the programmer with some extra time to regret having thought they could improve on what you wrote, or to reconsider their approach.

Bizarre sequences of mixed case and underscores and odd signs contribute to the visibility of your code. When the management team is having a discussion around the watercooler, which variable do you think they will be talking about: $statusOutput or $wHy_bbBabY-_-oHwwHY ? Getting the attention of your superiors is a clear indication of excellence, and as programmers that is what we strive for. Such variable names are also useful in helping your team members understand how you might respond to workplace conflict; if a person is prone to aggression when naming innocent variables, they possess a vast reservoir of "get the fuck off my back you Visual Basic coding shithead"-itude.

Most importantly, difficult to type variable names are to a programmer what pissing on household objects are to cats: a way to say "this is mine, despair all ye who trespass". Territoriality ports well to enterprise programming: if no one else is smart enough to manage your variable names, there's less chance you'll get fired for using them to begin with.

If you are fortunate enough to have deadkeys enabled, you can make judicious use of all manner of remarkable characters assuming your compiler can deal with Unicode. Managers do also talk about who is multilingual and who isn't.

Be descriptive with your variable names

Computer code is relatively dry material; most languages provide facilities for literary embellishment primarily through the ability to assign arbitrary variable names. Tragically, very few programmers make any advantage of this and the few that do ironically try to describe what the variable is attempting to store, thereby defeating the purpose and making the code even more boring.

A variable represents potential literary breakthrough waiting to happen. Most languages provide for ling enough variable names as to easily accommodate a haiku or a short poem. Flow control constructs provide for far greater and potent literary devices than plain old iambic pentameter and para rhyme. Shakespeare could never have dreamt of recursive rhyme with a resonant terminating condition. For loops, judiciously peppered with dynamically assigned variable names in the body take alliteration to the next level.

Code is literature. A variable name does not have to serve the function of the software, it can express a political position or - and this is where you might actually use conditionals - it might provide an aesthetic and colorful narrative around a colleague's ancestry.

Switch variable names often

Secure programming is almost a forgotten art. Very few universities today - and none that I know of - teach undergrad CS students about the dangers of over-reliance on the same variable for too long.

When one variable is given exclusive responsibility for a critical piece of data, the programmer risks variable exhaustion or corruption of this variable. One variable translates to one memory location; when this memory location is used and abused, the physical memory location becomes exponentially more error prone and the integrity of the entire program becomes suspect. Sound defensive programming practises call for frequent variable name reassignments. Given that this can quickly result in a very large set of variables, it is recommended that variable names be kept short.

Start out with a variable named something like $blt. Just before your loop which iterates over the members of $blt, consider that the loop might wear out $blt and therefore assign $frw = $brt. When you exit the loop, if it has been sufficiently long, you may reassign to $blt but this is really an arbitrary decision which is up to you. Many more experienced programmers will consider that they should not impose expectations for the number of loop iterations and would declare $fre = $frw right after the loop.

When you swap out variable names this often, you may have opted for contracted variable names. This actually improves code readability, especially if you have unusually long variable names elsewhere. The human mind is a pattern detecting device: the lucky maintenance programmer will remember which variable was which based on intuited variable length rather than its name, which is faster. For competent maintenance programmers, at least.

Reuse variable names across projects

Variable name proliferation and the lack of standardization creates much confusion in the enterprise programming workplace. The conscientious programmer will keep a portfolio of variable names from a previous project and reapply it, thereby giving a boost to subsequent maintenance programmers in that they won't have to learn a whole new repertoire of names.

It is a little appreciated fact that what the variable is called means absolutely nothing to the compiler and presents no barrier whatsoever to using it for something completely different. It is not a syntax error to recycle $smtp_server_port from that old groupware project and use it to store the marital status of job applicants on the new recruitment portal. It is in fact a considerate gesture.

As mentioned earlier in this article, the variable name may even be reused in the same project, but the careful programmer will, yes, swap it out with other variable names often to alleviate variable name exhaustion risk.