Why some single letter variable names looks ugly to me, for example: c, i and j (and even k) are the most used (mostly in for loops) but does not look ugly.. why?

Ugly
for (int a = 0; a < 10; ++a)

Not ugly
for (int i = 0; i < 10; ++i)

Probably because we're used to them

Single letter variables should only be used in textbooks to make it easier to whiteboard. They should not be used in production code.

It's the convention, which gives a hint as to the nature of the variable e.g. as here, 'an incrementing integer value'

'a' and 'b' are often used to denote unknown, but constant, values that aren't necessarily integers. So not a good choice for the places 'i' and 'j' are the convention, e.g. programming loops.

@spongegeoff i don't think 'i' means 'increasing' it just means 'index' ^^
And that's why it's totally fine even in production code, if used this way imo.

@nitwhiz I don't think 'i' means 'increasing' either. Know anyone who does?

Maybe you internally don't read "i" as "i" but as "index". "j" becomes "inner index" or something like that.

If that is the case, you most likely like the first variant more than the second:

(a, b) => a + 5 * b

(i, j) => i + 5 * j

It's called metasyntax. i implies an index or iterator. j and k have similar meaning a because second and third degree indices and iterators are common. None of this needs an actual word association, the names have a meaning of their own.

The way I see it, if i,j or x,y,z aren't enough, that means my loops are too nested.

By the way, a,b,c are terrible variable names for the same reason i,j,k are great; they carry no meaning, neither explicit nor implied. There are countless 1-3 letter names that are great in context, and even essays that restate all that context can be underspecified variable names if they fail to mention why it's different from all the other locals.

Familiarity bias

Although I have to say, short variable names can look very nice. I mean compare

let add a b = a + b;;

with

let add first second = first + second;;

@nitwhiz i thought i stood for iteration

"i" may stand for index, integer, iterator, iteration, etc. It's nice to be used in a small loop, consisting of less than 10 lines. For a huge block, using "index" is probably better.

While some other letter such as "x" is very bad, because "x" usually stands for an unknown.

yo, i haven't used one letter variables in a looong time, and don't miss them. Like at all.

A single letter is the least descript variable name you can use, why the hell would you do that? At this point you can use a fucking underscore for everything, because you apparently don't care about naming things properly anyways.

and if you're in your infinite wisdom think, that one letter variables in loops are just fine, then pull yo ass out of the last century and start using foreach, for .. in, range based loop or whatever the fuck there's out there in practically any language except for C.

@thebiochemic Sometimes there really is no need for a descriptive name. And the underscore is reserved for marking arguments and parts of a pattern as intentionally unused.

@Oktokolo i know about the underscore thing, this was on purpose.

as you have seen in the previous comments though there are atleast several meanings to one letter variables, which is a shame, because a program is not supposed to have space for interpretation. Like at all.

@thebiochemic The programm obviously has no space for interpretation (at least if the language doesn't allow undefined behavior).

Like in natural languages, it is all about context. That the same name has different meaning in different environments is a perfectly normal and expected property of a name.

If you see an i in the body of a loop, it is either the loop counter/index or a bug.

If you see a signature like (a: T, b: T) => T, a and be aren't expected to be special in any way. They are just some values of type T.

if you see (a: T, b: T) => boolean, that most likely is some sort of equality or identity operator. And it will not become more clear by renaimng a or b.

You know what k and v are in the generic foreach ((k, v) in descriptivelyNamedCollection) {}.

One-letter variable names are often bad - but also often they are perfectly fine. Naming something generically conveys a meaning too.

@Oktokolo yes, but what about naming stuff properly

the equality thing is not obvious at all for me, does it mean identity, partial equals, regular equals, not equal? naming stuff is so fucking important.

Assuming context is bad, because you never can guarantee, that whoever is working on the piece of code understand, what you meant by this totally obvious thing. That includes yourself + 6 Months aswell btw.

the k, v thing already breaks apart, as soon as you use more than one loop.

saying one letter names are not bad in some cases is analog to using pointers sometimes. Yes you can do that no problem, but not everybody is you.

@thebiochemic Have to say I'd expect a counter in a loop to be called 'i' and a secondary counter to be called 'j'. It's pretty much a convention and makes code clearer because the other, less constrained, variables stand out more prominently e.g. print($i, '. ',$firstName,' ',$lastName,"\n")

@thebiochemic I delibereately left the name of the function out because we don't disagree there. But what would be appropriate names for a and b and would they actually depend on whether the check is for equality or identity?

Obviously, if you nest loops (which is to be avoided but sometimes it is the best option), k and v aren't appropriate names. Not disagreeing there.

And using pointers (in the languages that have them) is just a question of performance. You can just pass values and return changed values if needed. From a functional point of view that would even be the only true way of doing it because of pureness. But in some languages, passing something by value means it actually gets copied even if it isn't mutated inside the function. And if you actually want the mutation to propagate to everywhere where this object has been stored, passing by reference is the most lightweight way to go.

@thebiochemic k means "key of collection". What key and collection mean are to be inferred. "keyOfCollection" is not an inch better than "k". If the variable can't be distinguished in any way other than being a key, k is as descriptive as any other name. "i" means "index into list" or "iterator over collection". Because these have different types in any language where the distinction exists, it need not be specified. If there's nothing you can say about i other than that it is an index or iterator because everything else is implied by context (eg. the collection it belongs to), then i is as good as any other name. In a function called " findMatchingStrings, "indexIntoStringArray" is not an inch better than "i".

@lorentz i'm pretty sure, you have missed the point.

for entriesFromList in stringListWithNames

is exactly as shit as

for e in n

for fucks sake, i'm just telling you to name shit properly and do stuff like

for name in names

i can mean index, interface, iterator. And none of them are really compatible with eachother.

while i agree, that k is rather unique, v can mean value, variant, virtual, variable and a bunch of more stuff

what about e for error, exception and event?

i don't see any reason whatsoever to use one letter variables in this day and age.

there was actually quite funny read on that and other topics on javascript.info called ninja code

It's worth a look.

@biochemic "for fuck's sake, I'm just telling you to name stuff properly..."
Here's the news: other people have different opinions on what constitutes 'naming stuff properly'. Personally, I'd use i and j for counters and I'd expect the vast majority of devs to think that was optimal/good.

@spongegeoff fair enough.

Your naming is shit then.
If you care about my opinion or not is up to you.

@thebiochemic Nope, my naming is absolutely fine and much the same as that of other experienced devs. Best of luck with $myCounter and $myNestedCounter