5 ms·

Case sensitivity in any programming language is crazy. I can't for the life of me see a valid engineering principal that accepts IsTheOne() and istheone() being

by rbobby 10y ago

Case sensitivity in any programming language is crazy. I can't for the life of me see a valid engineering principal that accepts IsTheOne() and istheone() being different bits of code. Oh sure at a technical level the computer has no problem with... the problem is restricted to those oh so error prone humans. Can anyone here honestly say that if they were doing a code review they'd agree that solely a difference in case would get their approval? And don't even get me started on filenames that only differ by case. If that's a good idea then I think trailing whitespace should be significant too!!!

jsprogrammer 10y ago
IsTheOne() and istheone() are different bits of code.
- kartickv 10y ago
  That's a circular argument. They are different only because the language says they are different, while the post you've responded to says (correctly) that that's bad language design.
  - jsprogrammer 10y ago
    The bit representation is different.
    - kartickv 10y ago
      Which is irrelevant, since languages are a medium of human expression, not a way to store bits on the disk.
      - jsprogrammer 10y ago
        Irrelevant to what? The two words literally are represented with different bits (code).
        baby 10y ago
        Assuming you are not trolling: yes they are indeed represented with different bits, which doesn't matter since these bits are not the bits executed by the CPU in the end. The "words" and not the bits are interpreted or compiled into machine code. Which is where bits matter.
- roblev 10y ago
  clearly case sensitivity is a decision by the language designers. Many languages are case-insensitive. from https://en.wikipedia.org/wiki/Case_sensitivity https://en.wikipedia.org/wiki/Case_sensitivity Some computer languages are case-sensitive for their identifiers (C, C++, Java, C#, Verilog, Ruby and XML). Others are case-insensitive (i.e., not case-sensitive), such as Ada, most BASICs (an exception being BBC BASIC), Fortran, SQL and Pascal.
kartickv 10y ago
I don't know why you've been downvoted, but anyone who disagrees with you needs to explain in what situation it would make sense to have two different functions or files with names differing only in case. I upvoted you.
- wnewman 10y ago
  I have used all-uppercase to make a distinction like class vs. instance in variables (in case-sensitive languages in which the class might be an ordinary held-in-a-variable value, like Javascript), and I might do it again. But it's very unusual, and it's also the kind of practice that is more suitable for a 1KLOC project that will receive 100 hours of effort from a single maintainer over its lifetime than for a bigger project with many maintainers and a highly motivated community of attackers. I don't think there was ever a case when I was tempted to name two functions with different cases, but if I ever had to write a modest-sized 1-maintainer system in which many functions came in exactly two different flavors, I might be tempted. (Perhaps threadsafe locked vs. raw? or some C++-like distinction between raw functions and closure-like class instances which can be used in a function-call context? or raw functions vs. wrappers with the extra plumbing required to let them be invoked from a scripting language?) afterthought: And now that I think of it, in old C code I think I vaguely remember working with macro vs. function implementations of the same operation distinguished by capitalizing the name, and I don't think the name convention was an urgent problem. C macros can breed various errors, but I think bitbang_macro vs. bitbang would breed pretty much the same errors as BITBANG vs. bitbang.
  - kartickv 10y ago
    In those situations, it would have been much more readable to have classFoo vs foo, foo() vs nonThreadSafeFoo(), etc. The bigger point is that while you can come up with creative ways to take advantage of case-sensitivity, it's not that you would have missed it if the language was case-insensitive. From that point of view, case-sensitivity has no benefit, but only a cost: leads to irritating errors from the compiler, or runtime errors in dynamically typed languages. If something has no benefit, and only a cost, we should get rid of it.
- 10y ago
pmontra 10y ago
There are languages that use lowercased names for constants (Erlang's atoms) and uppercased Names for variables, which are immutable and quasi constants anyway. This is uncommon but many other languages use uppercase for classes (Person) and lowercase for variables such as Person person = new Person(). That last example is one reson for having case sensitive languages. I can't think of any language I used in the last 30 years that was case insensitive. Maybe some BASIC interpreters on home computers in the 80s? But not all of them had upper and lower case characters to start with. Linux has a notoriously case sensitive file system, with trailing significant spaces (they are not special characters). Mac and Windows also have case sensitive file systems but that feature is turned off by default.

by rbobby 10y ago

jsprogrammer 10y ago

IsTheOne() and istheone() are different bits of code.

kartickv 10y ago
That's a circular argument. They are different only because the language says they are different, while the post you've responded to says (correctly) that that's bad language design.
- jsprogrammer 10y ago
  The bit representation is different.
  - kartickv 10y ago
    Which is irrelevant, since languages are a medium of human expression, not a way to store bits on the disk.
    - jsprogrammer 10y ago
      Irrelevant to what? The two words literally are represented with different bits (code).
      - baby 10y ago
        Assuming you are not trolling: yes they are indeed represented with different bits, which doesn't matter since these bits are not the bits executed by the CPU in the end. The "words" and not the bits are interpreted or compiled into machine code. Which is where bits matter.
roblev 10y ago
clearly case sensitivity is a decision by the language designers. Many languages are case-insensitive. from https://en.wikipedia.org/wiki/Case_sensitivity https://en.wikipedia.org/wiki/Case_sensitivity Some computer languages are case-sensitive for their identifiers (C, C++, Java, C#, Verilog, Ruby and XML). Others are case-insensitive (i.e., not case-sensitive), such as Ada, most BASICs (an exception being BBC BASIC), Fortran, SQL and Pascal.

kartickv 10y ago

I don't know why you've been downvoted, but anyone who disagrees with you needs to explain in what situation it would make sense to have two different functions or files with names differing only in case. I upvoted you.

wnewman 10y ago
I have used all-uppercase to make a distinction like class vs. instance in variables (in case-sensitive languages in which the class might be an ordinary held-in-a-variable value, like Javascript), and I might do it again. But it's very unusual, and it's also the kind of practice that is more suitable for a 1KLOC project that will receive 100 hours of effort from a single maintainer over its lifetime than for a bigger project with many maintainers and a highly motivated community of attackers. I don't think there was ever a case when I was tempted to name two functions with different cases, but if I ever had to write a modest-sized 1-maintainer system in which many functions came in exactly two different flavors, I might be tempted. (Perhaps threadsafe locked vs. raw? or some C++-like distinction between raw functions and closure-like class instances which can be used in a function-call context? or raw functions vs. wrappers with the extra plumbing required to let them be invoked from a scripting language?) afterthought: And now that I think of it, in old C code I think I vaguely remember working with macro vs. function implementations of the same operation distinguished by capitalizing the name, and I don't think the name convention was an urgent problem. C macros can breed various errors, but I think bitbang_macro vs. bitbang would breed pretty much the same errors as BITBANG vs. bitbang.
- kartickv 10y ago
  In those situations, it would have been much more readable to have classFoo vs foo, foo() vs nonThreadSafeFoo(), etc. The bigger point is that while you can come up with creative ways to take advantage of case-sensitivity, it's not that you would have missed it if the language was case-insensitive. From that point of view, case-sensitivity has no benefit, but only a cost: leads to irritating errors from the compiler, or runtime errors in dynamically typed languages. If something has no benefit, and only a cost, we should get rid of it.
10y ago

pmontra 10y ago

There are languages that use lowercased names for constants (Erlang's atoms) and uppercased Names for variables, which are immutable and quasi constants anyway. This is uncommon but many other languages use uppercase for classes (Person) and lowercase for variables such as Person person = new Person(). That last example is one reson for having case sensitive languages. I can't think of any language I used in the last 30 years that was case insensitive. Maybe some BASIC interpreters on home computers in the 80s? But not all of them had upper and lower case characters to start with. Linux has a notoriously case sensitive file system, with trailing significant spaces (they are not special characters). Mac and Windows also have case sensitive file systems but that feature is turned off by default.