> You want names to be short, so you easily write and read them. Especially if you use them a lot, it's useful to use abbreviations, like x, e, i, z.

when I look through older C codebases (Python, Linux), I often notice the extremely short and cryptic names. I wonder whether this practice is an artefact of a time before auto-completion & automatic refactoring?

These days, you can use meaningful names without much typing. From a reading perspective, I believe that longer names (within limits) are easy to parse. Humans see words, not characters.

--

E.g. When I first understood that argc means "argument counter" and that argv stands for "argument vector" it was a little revelation to me.

This has probably been said a dozen times already, but short symbol names are indeed acceptable in various situations, including but not limited to:

- Where they are actually correct, such as dimensions (x, y, z) or vectors (j, k, l, u, v, w).

- Other mathematical symbols (N, M, e, t). Maths is also a special case in which I'm personally willing to do away with usual variable naming conventions, for example when translating formulas from a scientific paper into program code.

- Very short code, e.g. lambdas (lambda x: x2), list comprehensions ([p.title for p in posts]) or simple loops.

If you look at SQLite, you'll notice that most variable and struct field names are short and cryptic, and that library is still considered a high-quality piece of code.

Regardless, I don't understand all the downvotes you're getting.

IMO short names are perfectly acceptable and even preferable as a local variable names withing short functions, when context is obvious and everything fits onto one screen. I would prefer

    for (int i = 0, len = string.length(); i <= len; i++) {
        char c = string.charAt(i);
        if (c == '\t') {
            return true;
        }
    }
    return false;

rather than something like

    boolean tabFound = false;
    int stringLength = string.length();
    for (int characterIndex = 0; characterIndex <= stringLength; characterIndex++) {
        char character = string.charAt(characterIndex);
        if (character == '\t') {
            tabFound = true;
        }
    }
    return tabFound;

Naming a variable solely after its type is never particularly useful. A name like `currentChar` would probably enhance readability. Of course if your code is just 2 lines long, `c` works just fine (that's not usually the case though).

You should probably abstract away some of that logic though (and `string` isn't a great variable name either):

    boolean tabFound = includes(line, '\t');

How would you name an abstract string without any implied meaning?

If the functionality you're writing is truly that abstract, an abstract variable name is fine. Your example didn't include the method signature though, so I assumed it was a part of some larger (concrete) code block.

> list comprehensions

Yes. Very much yes. My personal rule is to _always_ use single-letter names for Python comprehension indices, because line length is the biggest enemy of readability there.

In my experience, one-character variables are serviceable, even preferable, when you're piping data, like Streams in java, or all the equivalent functions in rust. So long as the starting input's type is clear, the "capturing" variable can be just the first letter of the type.

> When I first understood that argc means "argument counter" and that argv stands for "argument vector" it was a little revelation to me.

I was today years old... :|

Some of the oldest C compilers had a hard limit of 8 characters for identifiers. Those limits were removed decades ago but old habits die hard.

I personally prefer short and cryptic names for things that are used very often, but don't shoot the messenger. My main point are the trade-offs.

Some of that is from mathematics, for example (random code from the Internet):

   reverse2 xs     = go [] xs
       where
       go ys []     = ys
       go ys (x:xs) = go (x:ys) xs

In general, more abstract you get, the less important it is to devise long names, because things are going to be abstract anyway. Often, all you can tell about the object is already encoded in the type system.

Even in current practice, people prefer "log.info(..)" to "centralizedLoggingSystem.informationalMessage(..)". They prefer "Exception e" to "Exception unexpectedlyFailedToWriteAccountingFileException". We also prefer to write "a * b" instead of "a.multiplyBy(b)".

Sometimes simply the global consistency trumps the local context.

> E.g. When I first understood that argc means "argument counter" and that argv stands for "argument vector" it was a little revelation to me.

This is something every hello world tutorial should point out, but obviously most of them leave a lot to be desired. Or "argument count," as I know it, not "counter".

To me, most abstraction used in computing is done to provide way for a reductionist view of something. Abstractions don't have to be reductions but in practice, that's what they're typically used for.

Because of this, whenever you're reducing something you inherently peel off information and it's lost to 'simplify' something. This is where all sorts of forms of documentation come in handy: they provide a venue to retain and share some of that lost information you think might be critical and explain those 'simplification' assumptions.

In the above, information for reductionist abstractions often get lost over time when people make assumptions and don't share them in some form. Once you understand the original meaning--information that was lost, often times if well designed, everything falls into place for understanding fairly quickly.

I recently saw a post somewhere explaining why "uppercase" and "lowercase" described characters due to historical context where on printing machines, what we know as uppercase letters were stored in the top of the case while what we know as lowercase letters were stored in the bottom of the case (hence the upper and lower cases). Most my life I just assumed "upper" meant "bigger" and lower meant "smaller." In this particular case, that lost nomenclature information didn't add much value (although interesting). In some cases, it does (like the argc and argv information pointed out). Choosing what information to reduce and carry forward is an art form. You also have to be careful when teaching about what assumptions you take for granted that most don't start with.

I'm a believer in understanding at least one level beyond what an abstraction system is doing for me. It's not the most efficienct thing, but it demystifies the abstraction and when you run into hurdles introduced because the structure of that abstraction, you know why and often can devise ways to fix it. It's not always possible and in some cases isn't worth it.

Most modern software development has so many high level abstractions that understanding even one level down is typically impossible for any sane person given typical resource constraints for a given API. Because of this, we run into all sorts of messes where were drowning in abstractions (that aren't very standardized or widely adopted, instead composed together in case by case basis) we don't understand (i.e. complexity). That's all well and all until those abstractions fail and you're the person responsible to repair/mend them back into usefulness for a particular case--then it's a nightmare.

Personally, I can stand abbreviations so long as they're pronounceable. I think phonetic syllable-granularity abbreviations are an optimal tradeoff. argumentVector is silly to be writing in full all the time but argv is infuriating.

When I parse code I'm mentally reading to myself, so argv is deplorable gibberish that has to be translated to "arg-vee". It's like traveling over rocky ground, one step is easy enough but over a distance it really slows you down. argvec saves almost as many letters, is way more readable, abbreviates both words down to the same scale, carries more semantic meaning through for a newbie, etc.

Some English words can't be phonetically abbreviated and I think those are better off written in full.

> and that argv stands for "argument vector"

Huh wow, I've never actually been taught what argv stands for and have gone my whole life (post learning C) assuming it means Argument Values.

x is a variable name I still use quite a lot. Because it is quite meaningful as 'a meaningless parameter that is just a variable'. Same with y and z, though less often.

I'd also say that short names are sooner a product of line-length limitations than refactoring. Having to spread out every single statement over many lines because your reference a 12 character function 3 times in the same line and you are limited to 80 characters sucks.

Maybe it's also time to loosen the 80char limit a little bit, screen resolutions have advanced dramatically and large screens are commonplace.

I'm not a fan of sacrificing readability for some arbitrary screen-width limitation.

Going up to 100 or 120 is already sufficient

Contrariwise, I try to keep my code under 72 columns wide, and impose a hard limit at 80. Long lines are hard to read, no matter what screen they're on.

You'd need to make a case of which value, and why, and why it is better, so that the terminals can standardize on it.

I actually like the limitation, because it makes me use more enters, so that the information ends up not within one line but in multiple. Which mans more lines (and LOC) but better readability.

I guess a good comparison is Twitter's limitation on the characters. It has its pros and cons.

Point taken that it is ok to use i, x, y, z sometimes (eg. when iterating), but the notion 'a meaningless parameter that is just a variable' doesn't really exist... if it's meaningless, why are you saving it?

Only other use case I can think of is doing metaprogramming or some sort of templating where you have a variable, but might no even know what it represents, because it isn't your concern.

What about implementing something like map for lists? You know literally nothing about the values and the function except for their types.

    map :: (a -> b) -> [a] -> [b]
    map f [] = []
    map f (a:as) = f a : map f as

Personally I don't see any reason to use longer names than f, a, and as because you can't add any additional information.

You might say "well I don't write code like that", and I don't have any answer for you. But I find I write a fair amount of generic code.

> you can't add any additional information

Well you could...

    map transforming_function (element:rest_of_list) = transforming_function element : map transforming_function rest_of_list

...but the cost in terms of loss of brevity would far outweigh a benefit that would only accrue to complete beginners, who would be better served by comments and test cases.

> if it's meaningless, why are you saving it?

Because you are writing abstract code.

Odds are that a lot of your code is better done abstract, and only fully specified in a short context.

A variable can be a substitute for a longer expression for which a name/description is unnecessary because the expression itself is self-explanatory. The substitution with a (essentially meaningless) short name just makes repeated use of that expression more readable. Using a long, descriptive name would defeat the point.

I think it's underestimated that you also want names to change.

In simple English: "the car" becomes "your car" and "my car", when you have more than one.

> You also want names to be easy to understood, therefore, longer than few letters. So, "count" instead of "cnt" or "c", in short, no abbreviations.

Yet in cars, BMW is an abbreviation. IBM is also an abbreviation, Microsoft gets abbreviated to MS, and NS to NextStep.

"Nobody" calls BMW and IBM by their full name.

Only people in IT know and/or use the abbreviation MS (which is functioning), and only people into NextStep and macOS use the abbreviation NS (also functioning).

Would you want people to spell out Bayerische Motoren Werke all the time? With or without AG? Or would you want to use the English version, Bayern Motor Works? People all around the world know the acronym BMW; it does not have to be translated. Would you want the API calls to spell out NextStep?

I feel like established abbreviations are perfectly fine, and some people/companies (entities) try to get established.

> "Nobody" calls BMW and IBM by their full name.

In many cases these abbreviations have officially - legally - become the organisation's full name. In Australia, for example, the Colonial Sugar Refinery, known as CSR, officially changed their name to simply CSR (and only CSR) in the 1980's, IIRC.

While I love the sound of Bavarian Driving Machines, it's a translation / transliteration (mostly the former), and doesn't add much value beyond nostalgia.

Also, in Australia, these vehicles are mostly called Beemers anyway. (I'll note that I'm not a fan of Strine vernacular.)

A small nitpick - BMW is not an acronym - it's an abbreviation or initialisation. Acronyms are pronounceable words.

That isn't universally accepted as part of the definition of 'acronym'.

https://www.merriam-webster.com/dictionary/acronym:

"a word (such as NATO, radar, or laser) formed from the initial letter or letters of each of the successive parts or major parts of a compound term

also : an abbreviation (such as FBI) formed from initial letters"

https://en.wikipedia.org/wiki/Acronym:

"The broader sense of acronym inclusive of terms pronounced as the individual letters (such as "TNT"), is sometimes proscribed, but is the term's original and more common meaning"

https://www.dictionary.com/browse/acronym:

"1. a word formed from the initial letters or groups of letters of words in a set phrase or series of words and pronounced as a separate word, as Wac from Women's Army Corps, OPEC from Organization of Petroleum Exporting Countries, or loran from long-range navigation.

2. a set of initials representing a name, organization, or the like, with each letter pronounced separately; an initialism."

> That isn't universally accepted as part of the definition of 'acronym'.

That's the general sentiment of this thread -- that it's not universally accepted.

I'd refer to the Oxford English dictionary, but your citation from the Merriam-Webster contains what I understand is the defining feature:

> "a word ..."

With three examples of words (ie. pronounceable strings).

The addenda of 'also: ... other things' is a bit of a cop-out. This is the distinction between a dictionary that strives to provide definition of language, versus recording popular (mis)uses.

In this case it isn't merely a word; it is a brand.

NATO, radar, and laser aren't brands. NATO is an organization, like FBI. Radar and laser are technologies. IBM and BMW, these are brands.

Though I'm not sure that should make a difference for the definitions I'd say the following:

* An acronym is an abbreviation.

* Not every abbreviation is an acronym.

Example:

* FBI is an acronym and an abbreviation.

* Feds is an abbreviation, but not an acronym.

> Bavarian Driving Machines

It's actually "Bavarian Motor Works" which, coincidentally also comes out as BMW in English.

Oh, thank you - I'd seen this listed as driving machine translation several decades ago and hadn't pursued it more, just assumed that was legit.

Reviewing on Wikipedia I see that:

"Bayerische Motoren Werke [...] This name is grammatically incorrect (in German, compound words must not contain spaces) ..." which is reassuring, given my own general bewilderment with German grammar.

> A small nitpick - BMW is not an acronym

BMW is an acronym for Bayerische Motoren Werke in German (or Bavarian Motor Works in English).

> BMW is an acronym for Bayerische Motoren Werke

To reiterate, an acronym must be able to be pronounced as a word.

Language is 1) defined by its speakers, and 2) should be practical. It's just silly to invent a new word, "initialism", to distinguish between things you pronounce as a word and things you pronounce letter-by-letter. "NASA" and "FBI" are the same type of thing in most people's heads; there's no need to have a separate, awkward word for the second thing.

It’s not a newly invented word. Google books shows both “initialism” and “acronym” to have been in use since the 1800s. Saying we shouldn’t have more specific words because many people don’t know their meaning doesn’t make a lot of sense to me.

Actually according to Wikipedia:

> ... the first known published use of the term in English [is] from 1940

That published use is as follows [1]:

> Pee-gee-enn. It's an acronym [Ger. Akronym], that's what it is. That's what they call words made up of initials.

In other words, the very first recorded use we have of the word "acronym" is actually what some people insist on calling an initialism. I don't know who, afterwards, decided that "acronym" had to mean that it had to be pronouncable, or why, but I didn't vote for them.

[1] https://www.oed.com/view/Entry/1844

> Saying we shouldn’t have more specific words because many people don’t know their meaning doesn’t make a lot of sense to me.

I didn't say it was because people didn't know their meaning; I said it was because as far as most people are concerned, they're the same thing. I know what "initialism" means, but I choose not to use it, because as far as I'm concerned "NASA" and "FBI" are fundamentally the same thing. It's a waste of brain cells to figure out when to say "acronym" vs "initialism".

As an example where I think such a distinction is important, I do consistently write "MiB" when I'm talking about 2^20 bits. I only saw it the first time maybe 10 years ago, but it immediately seemed to be to be both practical and useful to make that distinction.

On the other hand, I never correct or ask clarification of people who use "MB", unless the difference becomes important. (Nor do I say "mebibyte", which is the proposed pronunciation of "MiB", because it's impossible to pronounce fluently.)

1. I'm not 100% convinced language is, or more importantly should be, defined by the speakers -- or rather be defined indiscriminately by all speakers, regardless of their qualifications or credentials. It tends to result in a convergence of similar words, weakening the strength of language and variety of expression available for people who understand the (original) distinctions.

2. I'm an English language speaker (and writer) and you seem to be discounting my right to define language. Or just to maintain the definition of certain words because they contradict a weakened but popular & recent redefinition.

3. I'm not advocating initialism - it's not a word I recall ever using. But I'm not sure it's reasonable to claim that it's silly to invent new words to describe new things. I'd advocate abbreviation for an abbreviation you can't pronounce as a word, and acronym for an abbreviation you can.

> I'm an English language speaker (and writer) and you seem to be discounting my right to define language.

Fair enough -- you have a vote; but when you "vote" for something from a minority usage point of view, you should make it clear that you are advocating for minority usage, and why. What you did instead was to assert that the "right" way to use the word was X, when in fact the initial usage was Y, and most people still use it as Y.

I don't object to people thinking carefully about how a language should work and then advocating for it; that's what I do myself. Nor do I object to correcting common "minority" usages that I think are going in the wrong direction. But a lot of people advocate changes which are more "pure" but are clunky and unhelpful.

For example:

* Using 'they' as a singular of unknown gender; i.e., "I have an appointment with Dr. Smith; when will they be free?" English has need for such a usage; 'they' is simple and understandable; and it's been in use since the 1400s. I'm a fan.

* Using "literally" as a meaningless intensifier; i,e., "My head literally exploded." I strongly object to this usage, and I will continue to object to it as long as it's practical to do so, even if I become a minority. The reason is that we already have hundreds of intensifiers, but we don't have very many ways to say, "I am not exaggerating or speaking metaphorically, this actually happened."

* Switching from "negative agreement" to "double negative == positive". In French, to say you've never done something, you say "Je n'ai jamais faire rien", which literally translated would be "I not have never done nothing". But it's not called a "triple negative", it's called "agreement": if any part of the sentence is negative, the whole sentence has to have negative forms. If you go back to Henry VIII's time, that was the officially correct way to say things in English too. but at some point, some people came in and said, "Well, if we make all negatives contradict the other negative, we can say things like 'It's not nothing.'" Then educated people got rid of agreement, and started telling less educated people, who were speaking the same way English had been spoken for hundreds of years, that they were speaking English "wrong". I think the new way is better, but I think it was kind of a jerk move to change it.

> I'm not advocating initialism - it's not a word I recall ever using. But I'm not sure it's reasonable to claim that it's silly to invent new words to describe new things. I'd advocate abbreviation for an abbreviation you can't pronounce as a word, and acronym for an abbreviation you can.

I didn't say it's silly to invent new words to describe new things. I'm saying that for most people, NASA and FBI are not different things. FBI is a word pronounced "effbiyaye". If people really thought of FBI and NASA as different things, then it would be easier to give them different words.

On the other hand, when people hear "abbreviation", they think more like "st" for street (or saint), "dr" for doctor, and so on. FBI is more like NASA than "st" or "dr". So it makes sense to call FBI and NASA by the same word.

If you personally think that making that distinction is useful, then by all means do so in your own writing. And if you think it's important for people in general to make that distinction, then go ahead and advocate for it. I'll continue to advocate against it, and people on the whole will decide. :-)

You seem to be claiming two somewhat contradictory positions:

1. that I can not conveniently claim acronyms should be words and abbreviations are a superset that also includes non-words -- because the alleged original meaning of acronym was as a synonym for abbreviation, and

2. the initial meaning of 'literal' as something that was strictly true, but which has since moved via common usage to simply be yet another synonym for metaphorically, but you don't want it to change.

FWIW I also rail against literally being used for things that aren't literal, I don't dislike 'not unlike' and similar despite Orwell's (et al) protestations, I'm happy to co-opt 'they' as a third person personal pronoun (or restructure sentences to avoid needing to uncomfortably alternate and track he and she), I vehemently defend the difference between alternate and alternative, myriad is not a collective noun (don't precede with an article, or follow with a preposition), I never use decimate as a synonym for devastate, etc.

I suspect most misuses are from people who've heard or seen a word they weren't familiar with, failed to understand or research the meaning or part of speech, believe using it will imbue some much needed gravitas to their communication, and then expect the world to adopt their befuddlement.

As we seem to agree, the ultimate outcome of all this is a weakened language for sophisticated users.

When I need to describe an abbreviation that's pronounceable, I evidently now need to call it an abbreviation that's pronounceable. This is a retrograde step for me, despite the word 'abbreviation' already being appropriate, well known, and understood by world+dog.

> On the other hand, when people hear "abbreviation", they think more like "st" for street (or saint), "dr" for doctor ...

How comprehensive was the survey group behind this claim?

You seem to have missed the main point I was trying to make:

"Vote" for a language which is useful and practical.

I specifically said that if you think it's useful to say that NASA is an acronym but FBI isn't, then go ahead and do so. Just be prepared to give a justification of why you think it's better.

"That was the original meaning" isn't valid, because it wasn't the original meaning. "That's what all the dictionaries say" is a weak argument. I didn't elect them and I don't agree with their decision.

Indeed. It is all about the produced sound. There's a format for that, but I'm not accustomed to it, so say phonetically there's "Ef Bee Eye". You could call the organization "Efbee Eye" or whatever, but why would you? "FBI" and "Feds" both work; they're both well accepted as it is.

It is pronouncable as a word, just not in English. It sounds approximately like 'beh-ehm-weh'.

I suppose something like Beh-Ehm-Dubya? Though I just learned "dubya" is Texan accent.

I can't find any support for that restriction on the various dictionary sites.

Same with SGN in Scotland

>You want names to be short, so you easily write and read them.

Hmm, I don't think short names are easier to write or read than a "medium length" ones, at least not for me. I mean naming something with a 30 character string is another matter, but names composed of a few words are not getting in my way during development/review.

I don't understand why would anyone find underscores ugly. Underscores are basically spaces. And we use spaces in our language to separate words. May be text editors should draw underscores with more subtle way?

Now-dashes-are-ugly.

Underscores are difficult to distinguish from underlining. That's just one issue.

Underscores_make_full_highlighting_easy

Dashes-make-single-highlighting-easy

It's also a use case thing. Double click on each sentence and note the behavior. It depends on which one you want. We use snake case in our urls because you can copy something from the documentation and easily highlight a portion to change.

English is a dash-using language, not an underscore_using one. Maybe that's why many of us prefer dashes to underscores?

Does any language use underscores? They seem like a purely technical thing to me. In a sentence you are certainly correct the - is much better. But as for the name of something in code, I would personally prefer _.

I have attributes, properties, metas, and values. And somehow each of those things can mean different things.