Note for people just getting into programming of any kind.
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?) :D
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 :banghead: or :doh: ... 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. |
Quote:
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.) |
Quote:
|
Quote:
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. |
1 Attachment(s)
Quote:
Been there, done that, paid those dues! Daniel B. Martin . |
Quote:
|
Quote:
|
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?) |
Quote:
|
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. Quote:
|
All times are GMT -5. The time now is 03:50 PM. |