61–70 of 175 posts
"Where does this idiom come from?" you might ask. Well, if I recall it's mostly due to languages like Fortran which implicitly typed identifiers starting with I through N as integers.
Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…
I too abhor single-letter variable names. My personal convention: minimum identifier length==2. {i,j,k}->{ix,iy,iz}, c->ch.
"rather than the elliptical vagueness of Romance languages like English" - what?
I had a few problems with that, too. English isn't a romance language (it stole a lot of romance vocabulary, though). I guess that the author eventually gets around to explaining what he means: too much vocabulary that doesn't break down into simpler, understandable words. It reminds me of the linguistic contortions you need to do in order to write like the Thing Explainer.
> iterating through a for loop using i is a well-established idiom that everyone instantly understands. Give that count was useless anyway, i is preferable since it saves 4 characters. "Where does this idiom come from?" you might ask. Well, if I recall it's mostly due to languages like Fortran which implicitly typed identifiers starting with I through N as integers.
Since when is English considered a romance language? I thought it was majority Germanic in origin.
A good guide, but I didn't like this part: Avoid Over-used Cliches In addition to not being Teutonic, the following variable names have been so horribly abused over the years that they should never be used, ever. val, value result, res, retval tmp, temp count str Cliches? If you are trying to communicate, these names are well known ways to do that. If there is something more specific to put in there, by all means, bu…
I guess what he's getting at here is that these variable names don't convey what the variable holds. Let's say you're writing C and you want to return status information from processes as integers. Instead of: > return retVal; where retVal could be 0, -1 or -2 to indicate success or failure of the function, how about: > return functionStatusCode; ? Or be even more specific (let's say the function tried to parse some…
But, sometimes I use generic names on purpose, so that I can factor the code into something general.
const int timeout = strtol(argv[2], NULL, 10);
send_and_waitfor(&msg, timeout);
If instead I see
const int timeout_ms = strtol(argv[2], NULL, 10);
send_and_waitfor(&msg, timeout_ms);
[EDIT add paragraph: Simonyi's overarching idea was to implement a novel solution to a familiar problem which I'll try to state as succinctly as possible: if two programmers are independently given the same programming task, and they turn out to write down the exact same code, you have won. Maintenance and working on other people's code is now solved if it's the same code you would write yourself. That's the problem he is trying to solve while also, incredibly, speeding up the process of independently writing code.]
https://msdn.microsoft.com/en-us/library/aa260976(v=vs.60).a... (please read past dr. dimento's introduction)
Pay particular attention to his notions of "type" that lead his naming system quite logically to very opposite conclusions as OP. He's not talking about underlying implementation types, he's talking about the properties of the abtract types that you keep in your head and only attempt to capture in code. Absolutely DO encode them in the name of the variable so it is completely unambiguous what you mean, so it's a contract you will live up to; not for communicating to the compiler, for communicating to other human beings: your compiler talking to other human beings is not that effective.
As a simple example, how many times have you said to your coworker "you need to pass me the file" to which they'll respond, "the file handle (by which they mean POSIX), the file name, the file path, relative, absolute, socket, URI, or do you mean the FILE pointer?" These are all notions of type that are best resolved with a shorthand unambiguous (and yes, local) language which is precise about type.
It helps you track meaningful distinctions and shed meaningless.
Bear in mind that this system comes from "the age of C"; as such, it helps make simple concepts that many programmers find disturbingling confusing: if "ch" means "it's a character", and p- as a prefix means "it's a pointer", then a "ch" and a "* * ppch" will have the same type. What are the attributes of that character type? You need to learn them or define them; I never said it was a C char and you shouldn't think that either; it will be only if those are the type attributes that are useful to your abstract type.
A good guide, but I didn't like this part: Avoid Over-used Cliches In addition to not being Teutonic, the following variable names have been so horribly abused over the years that they should never be used, ever. val, value result, res, retval tmp, temp count str Cliches? If you are trying to communicate, these names are well known ways to do that. If there is something more specific to put in there, by all means, bu…
I have mixed feelings. For a return value, retval et al are completely appropriate. Same for count. Tmp/temp borrow meaning from whatever they are a temporary for. These are all fine. But "value" is horrible. You really don't know what it is? You might as well name it "variable". "Str" is in the same boat, unless it's short for "tmpstr".