Specific variable names! Make it clear what they are. Not just something random!

I'm working on a Python course now. One of the tasks was to write something that can tell if a year is a leap or not. I had the code. The math was exactly matching the algorithm I found. Kept being wrong. Over and over. I was about to put my hand through the wall.

Turned out I was using the same variable to store my True/False as I was collecting my input statement. Why?

I used a for my input statement. Without thinking I just used it again for my bool. I had a all over the place without realizing it. Had I named the bool something like yesno or some such. and the input as year_input or something... I wouldn't have spent the last 30 minutes raising my blood pressure beyond acceptable limits. It would have been obvious from the start.

A litprog tool can help -- when naming a variable, take a quick look at your index of variable names.

Ha ha!
I did a very similar thing a few days ago and I've been in this game over 25 years!
Some people never learn.

Graduated in Computer Science in '86 ... Yes, make your variable names 'mean' what they are in use for. You do have up to 256 chars (usually) to work with in modern languages of today. Doesn't mean you have to use all 256, but you can be a bit more verbose when needed (unlike back when we were using Fortran and early C we were limited to at most 8 chars. We had to get creative sometimes). One of the rules we implemented was variable names should be at least 3 chars long, unless variable name is of a 'common' type. Like coordinates x, y, z are acceptable. Otherwise, row, col, cnt, amps, vars, watts, etc. should be used. Also use camel case or use underscores to separate words in your variables. Example: thisIsAVariable or this_is_a_variable. Up to you. Readability is important in understanding. Also all 'Constants' (or variables treated like constants) should be in uppercase. like PI or MAX_ROW.

(Chuckle ... can I have a "raise of hands" here right now?)

No matter how "smart" you are, the computer will always make a fool of you. The closest "emoji" that I can find on this site is either or ...

Especially important, in the case of variable names, is: (1) the "scope" of the variable-definition's "reach," and (2) whether the language will "simply, accept" variable-names that it has never yet seen before. In both cases, programming languages prove themselves susceptible to "a simple tpyo," which is especially hard to take when it has just happened to you ...

Full disclosure: The very first computer program that I ever wrote: (1) was eight lines long; (2) took me six months to write; and (3) had a bug in it. And that was (mumble, mumble ...) years ago.

As the saying goes, there are two hard problems in Computer Science: Cache coherency, naming things, and off-by-one errors. You've just touched on an extremely important and also much neglected aspect of not only programming but anything computing-related: Naming conventions.

Having a variable called "i" in a counting loop is fine, but having "i" hold the number of the order currently being processed is most likely not a great idea. "orderNum" would probably be OK, but if you also find "orderNum2" and/or "newOrderNum" in the code, it's a sign that someone didn't really think this through.

And should a variable name also indicate its type (iFoo, bBar etc), especially when using a dynamically typed language? It might make it easier to avoid or catch subtle errors due to dynamic typecasting, as long as the convention is strictly adhered to. (I remember seeing an article on The Daily WTF many years ago where some genius had defined an enum literally called "Bool", with three possible values: "True", "False", and "File Not Found".)

Same goes for networking and servers: "server01" and "gw1" certainly aren't very good server or router names respectively, but what does a good device name look like? Should it reference function, asset number, customer, location, hardware, OS, or perhaps a combination of some or all of the preceding? What about VMs? Switches? Access points? Printers? Barcode scanners? Keycard readers?

It's well worth the time spending a few minutes defining a naming scheme that you'll be comfortable with, and then stick to it. As always, take a look at other people's code and borrow liberally any good ideas that you find. Regardless of your choices, you'll certainly run into situations where your convention will turn out to be suboptimal, but that's fine; you can always revise it for your next project.

(And if you're collaborating on a larger project, follow the existing naming convention with religious fervour, regardless of whether you like it or not.)

I bulk a bit at this because 'i' is harder to search for when looking for where the variable is used. Better to use 'cnt', 'idx' or 'index' unless it is in a very 'tight' loop. Another reason to be a bit more verbose ... searching.

1 members found this post helpful.

That's fair. My point was that a counting variable in a small loop is pretty much the only example I can think of where a nondescript variable name can be justified. And "i" has somehow become a de facto standard name for an integer counter.

But as you say, if the variable is used for fetching items from an array or something similar in the loop, pretty much any name other than "i" would be preferable.

Fortran II was developed in the heyday of the IBM 7090. It was a 36-bit word machine, variable names were limited to 6 characters. The first character determined Integer or Floating Point. Devising meaningful variable names was challenging, especially in large programs.

Been there, done that, paid those dues!

Daniel B. Martin

.

Attached Thumbnails

 

Even Fortran 77 which I used... implicit variables starting with the letters 'i' to 'n' are integers. It was recommended not to rely on this, but to always declare your variables. Still in a lot of code I saw plenty of just i, j, k variables! Still 6 char character variable names. Luckily I was introduced to Fortran at college, but never had to write much of it in my career. I did help maintain Fortran code for plasma research (for vehicle re-entry from space) and a few other places but that is it. 'C' was the language we used a lot at work for real-time applications for SCADA projects.

I remember reading a suggestion somewhere to use 'ii' because of that, but I think most editors are able to search for a whole symbol easily enough anyway.

Two things, I think, especially “vex” software today. First, that we continue to use “source-based interpretive languages,” which literally must re-compile the source code with every oncoming request. (I have no idea how this strategy “won,” nor why cockamamie “solutions” to “deal with it on the client side” continue to be taken seriously.)

Second: “typelessness.” Yes, Microsoft probably canonized it with their variant “type.”

Maybe three: “variable declarations.”

Plenty of us still remember when languages were actually “compiled,” even into pseudocode (such as Java), and “strong typing” protected you from yourself.

Lately, I helped a client resolve a very serious problem which literally de-evolved into this ”d-oh!!” situation: (watch the underscores …) ”ii”

The interpreter didn’t see this as “a tpyo.” Merely as the introduction of a brand-new identifier. In a “better language,” this would have instantly been caught as a “compile error.” Instead, it cost my client many thousands of real Dollars. None of which can ever be recovered.

“The language system is always the agent that is in the best position to protect you from yuorself.” (Did you just catch that syntax error?)

1 members found this post helpful.

I used to force explicit declarations by including "IMPLICIT LOGICAL*1" at the top of Fortran code. The compiler complained mightily if variables hadn't specifically been declared to be integers, reals, etc.

In a truly-compiled language (particularly ...) the concept of local variables is very important. A variable such as "i," first of all, must be declared. (This would have immediately caught the "ii" problem aforementioned.) But it can also be declared to be "local" to a particular function or subroutine. Even if other routines use the same name, it is not the same variable.

Also, if the routine is recursive, which means that "it can call itself," each instance has its own copy of the local variable.

And then there is parallel processing. Effectively, all variables within a thread must be local. Otherwise, you are liable to get collisions.
I can read from a global variable, but variables which will be written to must be strictly defined within each parallel thread.