Hacker News Reader

Comment by lmm | Hacker News Reader

> In general (not all the time, but often), things that look different should be different

Case-sensitivity is the opposite though: it's making two things that look the same be different. I could maybe support a rule (or even just a linter) that each variable had to be written in a consistent case throughout the project, but two different variables that differ only in case should definitely be disallowed, IMO.

> It would certainly be easier for beginners, but I imagine that it would produce worse drivers; for example, you couldn't drive anyone else's car.

I don't think people buy their cars on the basis of how easy they make it to drive someone else's car, and nor should they.

View on HN

> Case-sensitivity is the opposite though: it's making two things that look the same be different.

No it isn't. fooBar and foo_bar have the same words in them, but they look very different.

Well, sure, because one is before the "and", and one is after it. Not the difference you meant? There are all kinds of differences, but kids usually learn to mostly ignore casing (in English) for meaning when learning to read, and programming makes them unlearn that rule. There are three exceptions (that I think of offhand): starting a sentence, trademarks and acronyms, and proper nouns. The first two don't usually change the meaning much or at all, and the last is pretty much Python's class/instance rule (except reversed).

The thing is, variable names are more akin to proper nouns. They're not words, they're names.

> Case-sensitivity is the opposite though: it's making two things that look the same be different.

I can see why you would say that, but (as my comment suggests) I'm with wtetzner (https://news.ycombinator.com/item?id=10932471) on this one: I think that `variable` and `VARIABLE` look different. I am willing to believe, though, that this may just be a result of my training (as a mathematician); my students often genuinely see no difference between `h` and `H` (as variables), for example, and will interconvert freely.

> I don't think people buy their cars on the basis of how easy they make it to drive someone else's car, and nor should they.

I agree, but people often learn to drive with someone else's car, and I think that's the relevant analogy here.

I think the point in the "variable"/"VARIABLE" difference is that, although they visually look very different, their meaning does not. In a more practical case, if I read some code which has two variables within the same score with names "last_value" and "LAST_VALUE", I would not be able to tell what should they contain: one has the last value in a sequence (which one?), and the other... what?

I agree that, in that example, it's hard to think why one would want both. I not infrequently find it happening (that I want the same name with different capitalisations to mean different things) in TeX, but that's probably not a good example of programming practice (and I can't think of a recent example anyway). It is probably most prevalent in mathematics, where, for example, one will often use `a` for the length of the side of a triangle opposite the angle labelled `A`. Again, though, it's fair to argue that good mathematical practice in naming variables is not good programming practice!

> I could maybe support a rule (or even just a linter) that each variable had to be written in a consistent case throughout the project, but two different variables that differ only in case should definitely be disallowed, IMO.

By the way, it occurred to me several hours later that this sounds a lot like HFS's "case preserving" approach, where case is ignored when matching (so that you cannot have a directory with separate files `a` and `A`), but preserved when displaying (so that a file created as `a` will never display as `A`, and vice versa). I don't want to speak for everyone, but my understanding is that this behaviour is regarded as a wart.

> By the way, it occurred to me several hours later that this sounds a lot like HFS's "case preserving" approach, where case is ignored when matching (so that you cannot have a directory with separate files `a` and `A`), but preserved when displaying (so that a file created as `a` will never display as `A`, and vice versa). I don't want to speak for everyone, but my understanding is that this behaviour is regarded as a wart.

That behaviour's very surprising because it means you can e.g. open a file by name, then check its name, and get a different name from the one you opened it under.

What I'm suggesting is equivalent to: variable names are case-sensitive, but it's an error to ever have two variables in scope that differ only in case (maybe only applied when you actually access one - depends on your views on wildcard imports).

Reply on news.ycombinator.com