3 ms·
> 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 varia
by JadeNB 11y ago
> 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.
- lmm 11y ago> 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).