1. 51
  1. 9

    I used to think that this convention was “right”; over the last few years I’ve changed my mind somewhat. I now think that most code ought to use this convention, but certain types of project should probably use some of the naming tropes listed.

    There are reasons that mathematicians use single-character variables. One it is that it lets you see more concepts at once. In code, this is partly evident in the fact that long names force you to wrap more lines. Steve Yegge has a classic post on the related phenomenon of comments-to-code ratios.

    1. 9

      The problem with this is names get too long. Eventually you have Java source with findAllWithUppercaseAndOrLowercaseIgnoringIndentation as a function, people need the common sense to not do that.

      I like this Ken Thompson take on the subject:

      Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: “I’d spell creat with an e.”

      1. 8

        Maybe the problem with your Java example is not the name though. Such long names are a good prompt to reconsider your design. Maybe ‘case’ should be a parameter, for example?

        This implies we should encourage long names because it makes design smells more visible.

        1. 4

          I agree. You could just call it findAll and have the rest be paremeters, like findAll(term, within, withUpperCase?, ignoreIndentation?).

        2. 3

          I pretty much agree with the article and programming would be a better place if people followed it, because having some variable names that are too long is less harmful than some variable names being too short.

          One additional reason is consistency: There is usually more than one way to shorten a term, but usually only one “full” spelling.

          Sadly the pendulum is still hanging pretty much in favor of short names.

          My personal rule is that nothing gets abbreviated until the abbreviation has

          • become almost a word of its own, and
          • the abbreviation is so commonly used that many people might have issues expanding it.

          So it’s fine to use HTTP, HTML, etc. but not much else.

        3. 4

          One reason why variables have been abbreviated is because we quickly get bored of typing long names. These days I see more people using longer names with the advent of auto completion. One thing that is not mentioned is how much of a problem this is when a developer is familiar with the abbreviations used.

          1. 2

            I have been using autocompletion in text editors and IDEs for 15+ years. You make it sound as if this is a new development.

            1. 1

              Of course it’s not a new development, but it has vastly improved in the last 5 years and I believe people have been using it more across many languages.

          2. 4

            I was slightly disappointed when I read the title, because I thought this was about giving german names to terms in computer science first (I had a professor who loved to “verdeutschen” almost all the terms he used, allegedly going as far as creating a german version of C.

            But regarding the actual points made, I think there are worthwhile exceptions to be made, even if one would want to peruse this naming convention, especially when it comes to common variables with common usages, where the name signifies the conventional usage, such as i, j, k for counters, x, y for coordinates, or other context specific values. Replacing these with firstlLevelCounter, secondLevelCounter is not only cumbersome but very unusual, and might even lead to more confusion.

            Another other “issue” might be that long variables lead to long lines, and possibly also the need to spread actually short code over multiple line, which might (!) be harder to read under some circumstances. But that’s maybe just my aversion to spread code vertically speaking ^^

            1. 2

              Ah, the good old Anwendungsfaden and the Direktzugriffsspeicher, how I missed thee! (user thread, RAM)

              1. 1

                Thanks for linking the dictionary. I had a similar Professor. At first, the germanized words sounded strange; now, I kind of like them. There’s even a book Technisches Schreiben (nicht nur) für Informatiker that has a chapter on Denglish. (It has many other tips on writing of technical texts.)

                1. 2

                  Yes, there are a few. I know Schröder-Preikschat (see zge), Goos (emeritus for a while), and Tichy.

                  My favorite is Tichys “Zwischennetzstöberer”.

                  Goos tried to use the original terms. This means for example “Halde” because apparently a german invented the heap.

                  1. 5

                    My favorite is Tichys “Zwischennetzstöberer”.

                    On that topic I have to say that the most counter-intuitive example I know is “Entkäfern” for debugging. It kind of reminds me of how weird but normalized these terms are in the first place.

                    1. 1

                      Lately I realized that this internalization of word meaning still happens even when the language stays the same.

                      I remember people giving me a weird look when I read Automatic Garbage Collection on a train until I realized “oh … they think it’s a book about … garbage collection”.

                    2. 1

                      I still have (mild) nightmares from Snelting’s “Verschattung”. :-)

                2. 3

                  What I like to do, roughly speaking, is then try to simplify those names by removing as many words as possible from the name, while still keeping the essence of the meaning. I seem to be able to get down to 1 word fairly often; 2 words is also not bad. Very rarely 3+; this always feels bad, but sometimes seems just unavoidable.

                  Also, I do use 1-character variables in quite some circumstances. Apart from the common i, j, k and x, y, z, I do that reasonably often when naming of the “foreach” element iteration variable, at least when the loop body is short - i.e. “foreach e in events”, “foreach p in paths”, etc. Esp. if the body is longer, or nested, I usually go for the longer “foreach event in events”. Other than that, in Go, I tend to use 1-letter names for the method receiver (i.e. what’s named “this” or “self” in many other languages). Don’t remember many more cases for 1-letter, but it happens from time to time.

                  Back to words removal, I like to assume that there are a few elements of mental context you can reasonably take for granted as known by the reader. And thus always remove them from the name. Specifically, in Go, those would be: name of the current package, name of the struct (when writing a method, or naming a field), name of the function. Examples:

                  • in package printer, name the type Parallel, not ParallelPrinter;
                  • then, name a method Start, not StartPrinter;
                  • then, name a parameter (or field) config, not printerConfig or parallelPrinterConfig;
                    • for a method named ProcessEvent, a parameter with Event type may then thus become a strong candidate for a 1-letter name e; though event may need to be considered too. An e is surprisingly nice, in that it’s usually the ~only one-letter variable on the function body, which makes it distinctive as referring to the main thing the function is working with.

                  That’s not all that’s there, there’s a reason for the adage that “naming things is one of the two hardest problems in Computer Science”. But those are some rules I find to be a fairly good baseline.

                  Ah, one more thing: when I have trouble naming a function (and also fairly often when I think I don’t), I try to write a godoc comment (a.k.a. documentation comment). More often than not, after I’m reasonably happy with it, the first sentence of the godoc magically contains words that just make a perfect name for my function.

                  1. 3

                    This kind of long winded prosaic convention is standard/cultural in Common Lisp, except using hyphens between the words.

                    1. 2

                      Oh, I do this too (and I’m also german) :D It really is a good name for it.

                      I usually stick to a kind of internal guideline that variable names should not have fewer characters than lines the variable is used in (with the rare exception of a loop index used so often it would make lines unreadably long), which served me well over a few projects.

                      In my experience, mathematically trained programmers tend to like/use either really short or greek names, most often directly adapted from the variable names used in papers.

                      1. 1

                        I agree with “German” naming for top-level functions and their arguments (but I don’t bother with it for local variables - hopefully those are elucidated by the German-named context they’re in), but I wouldn’t use “isomorphic” naming if I can avoid it. It’s redundant (the types are already there) and removes the information of why the argument is necessary.

                        1. 1

                          The “isomorphic” (I don’t like overloading that term for this – linguists tend to use Greek instead, and I’d happily call this homophonic, homonymic or homographic) convention suggests that “IndexedExpressionTable” and “indexedExpressionTable” should refer to very different things. Although that’s frequently the best we can do in practise, I don’t agree with the idea in general. Perhaps that’s just my experience with non-case sensitive languages speaking.

                          Edit: homophobic -> homophonic. Holographic -> homographic.

                          1. 1

                            I especially like it because when you grew code, you know you don’t have to try all the combinations.

                            1. 1

                              I hate this shit. For an antidote see the section on variable names from this paper: http://doc.cat-v.org/bell_labs/pikestyle

                              Finally, I prefer minimum-length but maximum-information names, and then let the context fill in the rest. Globals, for instance, typically have little context when they are used, so their names need to be relatively evocative. Thus I say maxphysaddr (not MaximumPhysicalAddress) for a global variable, but np not NodePointer for a pointer locally defined and used. This is largely a matter of taste, but taste is relevant to clarity.

                              1. 1

                                Write throwValidationError and not throwVE

                                Slightly irrelevant, but I believe the Germans actually quite like abbreviating their compound nouns. e.g. WG (Wohngemeinschaft), GmbH (Gesellschaft mit beschränkter Haftung), U-Bahn, S-Bahn, and so on.

                                1. 1

                                  While I agree that a longer name which explains exactly what it is is usually better, I find that excessively long names are often (though not always) a “code smell”, where either:

                                  • The code is excessively specific and a more general function could be abstracted out: addOneToSix() instead of add(1, 6)
                                  • The code doesn’t make proper use of context/namespacing, so repeats the context unnecessarily, e.g. Triangle::areaOfTriangle instead of Triangle::area.