4 ms·

How is that a basic mistake? I think having two distinct identifiers that differ only by case sounds like a mistake!

otherme123 5y ago
What I found useful is that even if some author uses snake in his library, it doesn't spread to your code, so you can still adhere to the standard.
IshKebab 5y ago
Various programming languages (and file systems!) have had some form of case insensitivity and it always turns out to be an absolutely terrible idea: * It makes searching for identifiers harder. For Nim you can't even use case insensitive search because of the underscore thing! Better practice your regexes. * The case insensitivity rules are usually super complicated and don't apply to everything, so now it's an extra thing you have to mentally compute when coding. This is probably the biggest problem and I'm sure it has led to bugs, e.g. in SQL. * Do you enjoy the tabs vs spaces debate? How about single quote Vs double quotes? Ugly inconsistently styled code? Well you'll love this! * Unicode case insensitivity is actually really really complicated (this mostly applies to filesystems). You're basically opening yourself up to an array of annoyances and gotchas for essentially no benefits. I've literally never seen anyone use two identifiers that only differ by case, but if that were actually a big problem it could be solved just by making that illegal. You don't have to resort to the insanity of case insensitivity.
- haxscramper 5y ago
  > Do you enjoy the tabs vs spaces debate? How about single quote Vs double quotes? Ugly inconsistently styled code? Nim solved tabs/spaces debate by allowing only spaces. Single/double quote are also completely separate, so there is no inconsistency as well. About "inconsistently styled code" - due to style insensitivity, effects are not viral. If you depend on a library that uses `get_name` but your project adopted `getName()` your don't need to suffer. > Unicode case insensitivity is actually really really complicated Which is why nim only handles case insensitivity for ASCII identifiers and not Unicode. Which makes sense because 99.9% code is written in ASCII. > The case insensitivity rules are usually super complicated and don't apply to everything Quoting from the manual - "only the first letters are compared in a case-sensitive manner. Other letters are compared case-insensitively within the ASCII range, and underscores are ignored." Unicode is not handled in style-insensetive manner, so the rule is pretty simple. > It makes searching for identifiers harder. For Nim you can't even use case insensitive search because of the underscore thing! Technically true, but in reality this comes up so rarely, I didn't have any issues with this ever. Nim projects usually adopt camel/pascal case. For some reason, people often assume that allowing style insensitivity instantly throws the whole language ecosystem in complete disarray and everyone starts writing code mixing every possible style of writing at once, swapping styles on every second identifier just for their amusement.
  - IshKebab 5y ago
    > so the rule is pretty simple So it's only identifiers, what about keywords, compiler directives? And only ASCII characters... And it doesn't affect the first character randomly. Sure very simple. > If you depend on a library that uses `get_name` but your project adopted `getName()` your don't need to suffer. Yeah because nobody ever imports code from other projects, copy/pastes from StackOverflow etc. /s > Nim projects usually adopt camel/pascal case. So why do you need case insensitivity??! Trust me this is a decision they will regret.
    - haxscramper 5y ago
      It does affect identifiers, built-in keywords and type names in the same manner, though it is completely beyond me why anyone would write 'tY_PE Position = tUPLE[x, y: iNt]'. If we are going to dismiss any nontrivial behavior as "sure very simple" then sure, having two distinct incompatible ways to write get_name (or getName) looks better. It does not "randomly" not affect first character. Most style guides for camel/pascal case treat first character differently, with types being capitalized and regular variables starting in lowercase. Making whole identifier style-insensetive would significantly reduce number of possible names. So this rule makes 'building' and 'Building' different, but at the same time does not differentiate between 'get_name' and 'getName'. > Yeah because nobody ever imports code from other projects, copy/pastes from StackOverflow etc. /s I don't understand your point (even considering /s) - if I do import code from my other projects or copy-paste it from somewhere it simply doesn't matter to me what style they used - I'm not required to fix copied code, or adapt to the style my dependencies use. > So why do you need case insensitivity??! If their code gets into larger ecosystem it will not affect anything else, or at least it's effects would be minimized. It is a win-win solution - library author uses their preferred style, I (and everyone else in the ecosystem) stick to common convention, and everyone bis happy. > Trust me this is a decision they will regret. I've been using nim for multiple years now, and I have never seen anyone actually regretting this. Of course, when new people come to the language they sometimes are really surprised by this, but rarely ever complain about this in the long run. EDIT: forgot to mention that nim is more than a decade old language, and "decision they will regret" should have happened years ago, yet it does not seem to be the case.
- nimmer 5y ago
  > For Nim you can't even use case insensitive search because of the underscore thing! Better practice your regexes. Not at all, unless you decide to mix different styles in the same codebase.
deleted 5y ago
[deleted]

What I found useful is that even if some author uses snake in his library, it doesn't spread to your code, so you can still adhere to the standard.

IshKebab 5y ago

Various programming languages (and file systems!) have had some form of case insensitivity and it always turns out to be an absolutely terrible idea: * It makes searching for identifiers harder. For Nim you can't even use case insensitive search because of the underscore thing! Better practice your regexes. * The case insensitivity rules are usually super complicated and don't apply to everything, so now it's an extra thing you have to mentally compute when coding. This is probably the biggest problem and I'm sure it has led to bugs, e.g. in SQL. * Do you enjoy the tabs vs spaces debate? How about single quote Vs double quotes? Ugly inconsistently styled code? Well you'll love this! * Unicode case insensitivity is actually really really complicated (this mostly applies to filesystems). You're basically opening yourself up to an array of annoyances and gotchas for essentially no benefits. I've literally never seen anyone use two identifiers that only differ by case, but if that were actually a big problem it could be solved just by making that illegal. You don't have to resort to the insanity of case insensitivity.

haxscramper 5y ago
> Do you enjoy the tabs vs spaces debate? How about single quote Vs double quotes? Ugly inconsistently styled code? Nim solved tabs/spaces debate by allowing only spaces. Single/double quote are also completely separate, so there is no inconsistency as well. About "inconsistently styled code" - due to style insensitivity, effects are not viral. If you depend on a library that uses `get_name` but your project adopted `getName()` your don't need to suffer. > Unicode case insensitivity is actually really really complicated Which is why nim only handles case insensitivity for ASCII identifiers and not Unicode. Which makes sense because 99.9% code is written in ASCII. > The case insensitivity rules are usually super complicated and don't apply to everything Quoting from the manual - "only the first letters are compared in a case-sensitive manner. Other letters are compared case-insensitively within the ASCII range, and underscores are ignored." Unicode is not handled in style-insensetive manner, so the rule is pretty simple. > It makes searching for identifiers harder. For Nim you can't even use case insensitive search because of the underscore thing! Technically true, but in reality this comes up so rarely, I didn't have any issues with this ever. Nim projects usually adopt camel/pascal case. For some reason, people often assume that allowing style insensitivity instantly throws the whole language ecosystem in complete disarray and everyone starts writing code mixing every possible style of writing at once, swapping styles on every second identifier just for their amusement.
- IshKebab 5y ago
  > so the rule is pretty simple So it's only identifiers, what about keywords, compiler directives? And only ASCII characters... And it doesn't affect the first character randomly. Sure very simple. > If you depend on a library that uses `get_name` but your project adopted `getName()` your don't need to suffer. Yeah because nobody ever imports code from other projects, copy/pastes from StackOverflow etc. /s > Nim projects usually adopt camel/pascal case. So why do you need case insensitivity??! Trust me this is a decision they will regret.
  - haxscramper 5y ago
    It does affect identifiers, built-in keywords and type names in the same manner, though it is completely beyond me why anyone would write 'tY_PE Position = tUPLE[x, y: iNt]'. If we are going to dismiss any nontrivial behavior as "sure very simple" then sure, having two distinct incompatible ways to write get_name (or getName) looks better. It does not "randomly" not affect first character. Most style guides for camel/pascal case treat first character differently, with types being capitalized and regular variables starting in lowercase. Making whole identifier style-insensetive would significantly reduce number of possible names. So this rule makes 'building' and 'Building' different, but at the same time does not differentiate between 'get_name' and 'getName'. > Yeah because nobody ever imports code from other projects, copy/pastes from StackOverflow etc. /s I don't understand your point (even considering /s) - if I do import code from my other projects or copy-paste it from somewhere it simply doesn't matter to me what style they used - I'm not required to fix copied code, or adapt to the style my dependencies use. > So why do you need case insensitivity??! If their code gets into larger ecosystem it will not affect anything else, or at least it's effects would be minimized. It is a win-win solution - library author uses their preferred style, I (and everyone else in the ecosystem) stick to common convention, and everyone bis happy. > Trust me this is a decision they will regret. I've been using nim for multiple years now, and I have never seen anyone actually regretting this. Of course, when new people come to the language they sometimes are really surprised by this, but rarely ever complain about this in the long run. EDIT: forgot to mention that nim is more than a decade old language, and "decision they will regret" should have happened years ago, yet it does not seem to be the case.
nimmer 5y ago
> For Nim you can't even use case insensitive search because of the underscore thing! Better practice your regexes. Not at all, unless you decide to mix different styles in the same codebase.

deleted 5y ago

[deleted]