1. 28
  1. 19

    There’s a surprising number of languages without case sensitivity. SQL is probably the most used, also Ada, Fortran, Pascal. I write my SQL without capitalizing the keywords and it freaks people out but it sure looks better to me.

    1. 6

      I write my SQL without capitalizing the keywords and it freaks people out but it sure looks better to me.

      I generally do the same (although if I’m editing an existing script / query then I take a “when in Rome” approach). The reason, though, is that I can never figure out what EXACTLY is supposed to be capitalized! Some people capitalize only statements, others capitalize operators, etc. Since it’s not case sensitive, “capitalize nothing” is just less cognitive load.

      1. 6

        In SQL specifically I prefer to have (only) the keywords capitalized because it makes the names stand out better.

      2. 18

        With Japanese we could still write variable names in Hiragana, Katakana or Kanji 🤔

        1. 6

          Also the Roman alphabet and Arabic numerals! Plus emoji, Japan’s orthographic gift to the world 🎏🗿💮

          1. 5

            FULL width is also a thing 🤭

            1. 4

              ハンカクカナモアルンデス。

            2. 2

              Didn’t we have emoticons like a decade before emoji became popular (in the west, anyway)? Weren’t those functionally emojis (albeit not part of unicode, but I’m guessing the earliest emojis weren’t either). Anyone know for sure?

              1. 1

                The first emoji were made for Japanese cellphones in 1997, by which time English emoticons had existed for a decade or so. Japan even had their own variations on emoticons like ^_^.

                1. 2

                  What I remember from that time is being mind blown by how Japanese had taken emoji to a whole new level, breaking free of the idea that eyes were always “:” and that faces were always sideways.

                  1. 1

                    I remember chat clients and forums would let you put actual smileys inline with text. It wasn’t ascii.

          2. 15

            This reminds me of the argument that saving 3 minutes on a daily commute will lead to billions of dollars in economic growth. Of course the real world doesn’t actually work that way.

            1. 4

              Agree. It’s interesting to think about exactly where the logic is wrong.

              1. 2

                I’m sure we could find alternative things to complain about without case. Like Hungarian notation!

              2. 12

                Nim is case-insensitive with an exception for the leading character, and that makes some people angry https://lobste.rs/s/uyv16t/nim_v2_get_rid_style_insensitivity

                1. 9

                  As someone who speaks Hindi, English, and Punjabi, I actually like the UPPER/lower case distinction in English. If you encounter an unfamiliar word in Hindi or Punjabi, it’s impossible to tell if it’s a proper noun or just a regular word unless you look it up in a dictionary. Sometimes things are clear from context, but not always.

                  In the case of Hindi, this is made even harder by the fact that there’s no real agreement on what Hindi even is (unless you’re the government, an academic, or dangerously nationalist). It liberally borrows from Sanskrit, Persian, Punjabi, Arabic, Urdu (which is basically the same language), and a bunch of other less widely used languages and dialects. Dictionaries are have strong opinions on what words should be considered “proper” Hindi, which means most of the time I’m just searching the Web to see if a word is a place name or just some obscure adjective 🤷🏽‍♀️

                  1. 7

                    How many man years are wasted with conflicting C naming conventions?

                    1. 8

                      The one that bugs me most is when you’re working in a language that allows dashes in identifiers and then you have to interoperate with json or database field names from a language that doesn’t. So many headaches just because of arbitrary stupid restrictions in mainstream language rules.

                      But I can just imagine how batshit it seems coming from a language without case (nearly every non-latin writing system in the world) and being like “wait, you literally have duplicate copies of every single letter in your entire alphabet, just for proper nouns and beginning sentences? whyyyyy”.

                      1. 3

                        But I can just imagine how batshit it seems coming from a language without case (nearly every non-latin writing system in the world)

                        Not the same as case but Hebrew (and Arabic, I think?) has separate letters for ending words.

                    2. 6

                      D for limits.mMaxTextureSize:

                      __traits(getMember, limits,
                          "m" ~ enumMember.drop("GL_".length).split("_").map!capitalize.join)
                      
                      1. 3

                        sed in your Makefiles also works.

                      2. 5

                        Common Lisp is an interesting case. My understanding is that identifiers are technically case sensitive, but the reader normally flattens case, so the language looks case-insensitive unless you go out of your way.

                        I’m a CL newbie, though, so this comment could be slightly wrong.

                        1. 2

                          Exactly correct. |ThIsIsASymbolWithMixedCase| and '|ThisQuotesSuchASymbol| and so on. It’s the reader that reads This as |THIS|.

                          1. 2

                            You forgot | this is a symbol with spaces in it |

                            ;)

                            1. 1

                              Quite right.

                          2. 2

                            It works similarly in PostgreSQL, which tripped me up when a table had a title case name. When you have an identifier in your SQL query without double quotes, it will be lowercased, and then PostgreSQL complained that the table did not exist.

                          3. 4

                            I once implemented the same feature in three different codebases, and learned something from it: Things like naming convention consistence matter, but the visibilitty of any lapses is far greater than their real importance. After that I wrote: «Proper engineering has its value, but perhaps not as much as common wisdom says. Moderately clean code offers almost all of the value of really clean code.»

                            I don’t see any reason why importance of a software defect should scale linearly with its visibility. This suggests to me that it doesn’t. That some defects are easy to see even though they have little effect on the function of the code or the productivity of its maintainers, and other defects are difficult to see even though they have a major impact on either function or maintainer productivity.

                            It’s easy to be sidetracked by high-visibility defects. If you allow that to happen, you end up with a year of no functional improvement. In fairness, I do remember a case where I solved an important bug by cleaning up naming conventions (the cleanup revealed that something was calling a private helper inside another module, breaking internal assumptions). It happens.

                            1. 4

                              I endorse this post as a native Korean speaker whose native writing system lacks case distinction.

                              1. 4

                                If we didn’t have case to distinguish between different types of symbols, we would just do something else. Naming conventions like foo_t for types, foo_c for constants, or whatever.

                                You’d still need to transform between different naming conventions. I’m not remotely convinced that capitalization-based naming conventions are any worse than whatever else we would invent in their place.

                                1. 1

                                  Some of these are of fairly dubious value, but using upper case for macros in C/C++ is a very good idea. Macros that look like identifiers can have side effects when you read them. Macros that look like functions may evaluate their arguments more than once. Upper case is a great way of flagging ‘you need to make sure that you know what this does!’. I believe Rust uses an exclamation mark when instantiating a macro, which makes this even more explicit.

                                2. 3

                                  Yes, you lose time, but you also gain some time and clarity as well.

                                  only exists because of man made style guides

                                  This is mainly an issue with C and C++, or other case sensitive languages which existed before consistent usage of auto-formatters and linters.

                                  I spent about a year working in Ada, which uses case insensitive names. Most names, of classes, variables, functions, etc. get written in Pascal_Case_With_Underscores, since due to case insensitivity Foo is the same as foo, and this format allows separation in case someone (for some reason, like their terminal is from the 1980s and doesn’t show upper/lowercase) does PASCAL_CASE_WITH_UNDERSCORES.

                                  You lose clarity sometimes trying to come up with inventive variable names or just using single letter variable names, e.g.

                                  const Limits& limits = getCurrentContext()->getLimits();
                                  

                                  wouldn’t be allowed, and instead you’d have something like:

                                      L : constant Limits := Get_Current_Context.Get_Limits;
                                  

                                  There’s a huge benefit of programs like gofmt and rustfmt which enforce naming conventions. I very seldom have to worry about variable names in Rust code due to consistently programmatically enforced rules since very early in those languages, so nearly everything “looks right.”

                                  1. 1

                                    Python has mostly solved this with “just run black on it”, but I do still occasionally run into codebases that followed Google’s Python style guide, which was different than the main Python style guides. Fortunately that was never adopted by a huge percentage of the Python community.

                                    1. 1

                                      Does black rename your variables? I am pretty sure that gofmt does not.

                                  2. 3

                                    That depends on what other issues those languages would have brought with them. The status quo suffers from the availability bias, which is why the grass always seems greener on the other side.

                                    1. 3

                                      Different people will name things differently, and combining namespaces that used different names for the same concept can be awkward. Case (and underscore) differences are just part of that, and not the biggest one. So I see this post as kind of naive.

                                      1. 3

                                        As someone who doesn’t write C++, I find the necessity(?) of prefixing of some variables with ‘m’ because the compiler doesn’t help you distinguish which namespace a name comes from to be way more odd than which character set they’re written in…

                                        1. 3

                                          There’s no necessity, it’s just a convention. Think of it as Hungarian notation for scope instead of type (and I’m sure there are people who do both).

                                          1. 2

                                            This is a tooling issue. Good IDEs change the color of variable names, so it’s possible to differentiate between a variable and a field. In such case, writing m shouldn’t be necessary.

                                            1. 1

                                              A few reasons:

                                              It tells the reader that this is a field. An identifier in a C++ program may be resolved via various scopes:

                                              • A local in the current lambda
                                              • A local in the current function
                                              • A field (member) in the current object.
                                              • A variable visible in an anonymous namespace in the current compilation unit.
                                              • A global variable in one of the current namespaces.
                                              • A global variable with no namespace.

                                              For extra fun, these all shadow the later ones, so an identifier can (in the worst case) appear as all of these, with different meanings at each level[1]. By adding a prefix such as g on globals and m on fields, you disambiguate these and don’t need to rely on an IDE to tell you which you mean (not a great idea if, for example, people might need to read your code in the GitHub web view).

                                              Additionally, C++ puts member functions (methods) and member variables (fields) in the same namespace. If you want to have a public method called foo that returns some state then you can’t call the field that backs it foo. Some people prefix private members with an underscore to avoid this.

                                              [1] My favourite example of this is that UNIX defined a function called index, which is always present in a *NIX libc. You get really interesting interactions with the linker in C if you declare a mutable global called index, though thankfully modern linkers will now scream at you if you do.

                                            2. 3

                                              One of the reasons why Lisp immediately felt like my perfect home. everything-is-hyphen-case.

                                              1. 3

                                                I would guess that far far less than the incredible amount of human energy that is wasted on Chinese. That said, the Korean writing system seems pretty awesome.

                                                1. 2

                                                  I have seen code uses CapitalizedCamelCase classes that wrap uncapitalizedCamelCase functions that wrap snake_case functions that dispatch using a switch on ALL_CAPITAL enums. You get to live in a different world if you work in a particular level.

                                                  1. 1

                                                    Was the code written in Python? I’ve seen a lot of Python code that uses PascalCase for type names and snake_case for variable names (and ALL_CAPS for constants).

                                                  2. 1

                                                    Simple solution: use the Haskell naming convention (TitleCase for types, camelCase for non-types) and enforce it.

                                                    1. 2

                                                      Does Haskell enforce it?

                                                      1. 1

                                                        No.