Long Names are Long | Hacker News Reader

Long Names are Long

journal.stuffwithstuff.com

149 pointsskybrian80 comments

I think that the most important thing to understanding about naming is how it interacts with scope. Class names tend to be longer because there is no outer scope (unless you have packages or namespaces). Likewise, single character names are fine in very localized contexts like this:

users.map {|u| "(" + u.first_name + ")" }

'u' would be a very bad variable name in a broader context. Here, we can easily see it's a user.

"u" is a terrible variable name in that context also.

Why?

3 extra characters to make the variable user takes no time and makes the code clearer

Does it actually make the code clearer, though? If u is used as a temporary local variable meaning a user from users throughout the code, I think it's quite clear. Consistency seems like the important thing here.

> If u is used as a temporary local variable meaning a user from users throughout the code

Until it isn't. How do you enforce this?

"Please use descriptive variables everywhere, except for when you are iterating over a list of users. Use "u" in that case. Thanks."

"Please use variable names that are more descriptive the larger the scope of their use is."

When the scope is limited to a single line lambda, "first letter of the thing it is" is plenty descriptive enough, especially given that it's a strong convention in ruby.

(In an example of the opposite extreme, I'm currently working int codebase where every non-function local/non-instance variable has to use its fully qualified path name. Extremely descriptive; extremely unreadable.)

All names depend on context. "user" may or may not be description depending on the surrounding context. Single-letter variables are the same.

Your own post provides good examples - you use "it" and "this" because, in context, they are clear and easier to write and read than a longer version.

In the same way you enforce anything else: common sense.

The other direction is the same. If your team doesn't share a "common sense", then someone will end up writing value[axis_x][axis_y][axis_z], because single-letter names are prohibited.

I disagree. It is a great, clear, readable, succinct name, the same way that 'i' is a great name for an index in a loop, or i,j,k can be great names for nested indices. Einstein's multi-index notation was based in the same principles and works great in the contexts where it is used, the same that 'u' works great above.

Why "u"? Why not "a"? Because "u" stands for "user"? Then make the variable "user" and don't add extra mental overhead for me when I read it.

And then you have the similar names "user" and "users" present in the same scope.

There's absolutely nothing wrong with single-letter variable names with miniscule scopes. (Well, never use lower-case 'l' for anything, but the rest are fine.)

> And then you have the similar names "user" and "users" present in the same scope.

So? They are different names and have different types. Maybe this is a ruby specific thing. Are you suggesting since "u" looks more different from "users" than "user", it's easier to tell it's a different type? Usually in non statically typed languages, I thought you make the variable more descriptive to make up for lack of types not less descriptive. For example:

user_collection.each { |user| puts user.name }

Single letters for iteration values are a common convention in a number of languages. In the case of user/users, I'm likely to miss the distinction when scanning the code.

If I've got a bunch of little lambdas, short loops (under 10 lines, perhaps), or list comprehensions, I'm not going to use longer names in them, because the context is clear and limited in scope.

If the variable's got to stick around longer (like throughout a function/method), it'll get a more descriptive name. As the scope grows, the variable loses the context that it came from, and it's more likely to need a longer name to make its meaning clear.

Iterating user for users is also a common idiom. Additionally making others having to look at the context to know what a u is, multiplied by the amount of loops, is somewhat inconsiderate.

FFS, it's on the same line of code. The variable is live for a single expression. This is style wankery at its absolute worst.

Sure but most functions are longer, small functions can grow, and consistency is better.

On a separate matter: you should read the HN guidelines.

> most functions are longer

Irrelevant. This function is painfully short.

> small functions can grow

It's a microlambda passed to a map function. 99% of these will never grow past a single expression. Hell, 95% of these will never even be modified.

> consistency is better

What, exactly, is this inconsistent with?

> you should read the HN guidelines

There's a difference between being uncivil and expressing frustration frankly.

> This function is painfully short.

Irrelevant. Other functions are longer. And needless human minification will undoubtedly creep in there too.

> What, exactly, is this inconsistent with?

Other functions.

> expressing frustration frankly.

Calling someone a wanker isn't exactly a pinnacle of expression.

> Calling someone a wanker isn't exactly a pinnacle of expression.

No, it's not. But you shouldn't confuse your own identity with your coding style preferences, which were what the comment used "wankery" to describe.

I know that it's common. I use it in cases where there are more than a few lines of code, where the reader would have to maintain context. Wider context equates to a more specific variable name.

> multiplied by the amount of loops, is somewhat inconsiderate.

And using the more detailed variable name is misleading. It implies a longer scope, to me.

I recommend skipping both cases of the letter O as well. I'm surprised so many people use it, especially to mean "object". Really, code that uses `my_dict[O]` where the object is a hashmap key or `O1 + O2` demonstrating the wonders of operator overloading even show up in textbooks. No scope is small enough to justify O as a variable name.

Use 'j' and 'k', avoid 'i', especially for loop controls. It's so much easier to find their uses in the loop body with an editor, since they're high-valued Scrabble letters and they don't show up in C++ reserved words apart from "break".

Use an IDE instead of an editor and finding/hilighting usages is just one keypress away. I'm often surprised how many people assume IDE=editor, but with higher system requirements.

In Vim (editor, not IDE), if your cursor is on the i, then * will jump to the the next occurrence, # the previous one. In addition, they all get highlighted if ":set hls" (highlight search) is on, which is the default.

"Don't use 'i' because it occurs often in keywords, making it hard to search for" is the most outlandish thing I've head in a good several weeks, even without the Scrabble reference.

Alternatively, you could search for "int i" or "\<i\>", or "for (i".

More importantly, don't use Notepad or Pico for writing code.

I agree, they should have used '_'.

I disagree. In my experience, _ is used for assignments that will not be reused, basically throwaways. This is not one of those cases.

i'll take 'u' here any day. would never mistake it for anything else

    class Array 
      def method_missing(m, *args, &block)
        self.map {|x| x.send(m)}
      end
    end
    
    users.first_name

using `x` as a variable name is not the reason this code is terrible.

This. So much this.

There are at least two reasons scope is important. First, the larger a name's scope, the more likely it is that short names will end up conflicting with other names at some point. Of course conversely, the smaller the scope is, the less likely it will conflict with something and the shorter you can make the name. And second, if the definition of something is a long ways away, then it becomes harder to find it to figure out the context. But in the example above, `u` has very small scope and its definition `users.map` is right there and makes it very easy to see what u stands for.

It's also important to realize that long names have a cost. Above the obvious small cost of typing time, it is also harder to disambiguate them visually.

> users.map {|u| "(" + u.first_name + ")" }

If you need to specify the "u" in order to re-use it in one place only, then your language is syntactically challenged. Use a better language instead of caring about the names. A more flexible language would enable a predefined name like "it" or "_" instead, e.g:

    users.map{"(" + it.first_name + ")"}

or even provide syntax to do common stuff, e.g. the asterix in:

    users*.{"(" + first_name + ")"}

You may be interested in "Programming Shorthands"

http://research.microsoft.com/apps/pubs/default.aspx?id=6974...

http://lambda-the-ultimate.org/node/2035

In a tight scope like this, `u` is the same thing as the classic "dummy variable", like the `i` in a for loop. "For a user u, do this". Dummy variables must never be given long names, because long names say, "this is not a dummy variable", which is a lie in that case.

>Use a better language instead of caring about the names.

That's not always an option.

Also, I don't find the language OP linked syntactically challenged. C# has a similar syntax and it's much more readable than what you've provided:

people.Sort(p => p.FirstName);

Hungarian Notation is not, and was never, for representing the type of a variable. It's about usage of that variable. "c" represents a change, "w" means width, "x" means horizontal position, "ix" is an index into an array. All of them are `int`s, but "cw" "cx" "ix" and "x" are all different kinds of variables.

http://www.joelonsoftware.com/articles/Wrong.html

Some would say those should be their own types, even if simply aliases to built-in ones.

I strongly agree, but nobody* uses languages that would make it a compilation error to add "cw" and "ix" together.

True. But for documentation purposes it makes more sense than tacking on prefixes to names.

Nobody uses C? https://github.com/torvalds/linux/blob/v4.3/arch/alpha/inclu...

Or C++? http://www.boost.org/doc/libs/1_60_0/libs/serialization/doc/...

(I'd buy "Nobody uses Rust", but I can't resist a "maybe they should.")

de jure != de facto

In practice it was used far more for type.

Still a terrible idea. I agree with the poster below that these should just be their own types.

There are two kinds of Hungarian Notation: Systems and Apps Hungarian: https://en.wikipedia.org/wiki/Hungarian_notation

In Systems Hungarian notation, the prefix encodes the actual data type of the variable.

Apps Hungarian notation strives to encode the logical data type rather than the physical data type; in this way, it gives a hint as to what the variable's purpose is, or what it represents.

Whoa. I finally understand Panda's usage of .ix() for accessing elements of a data frame. I always assumed it was a goofy shorthand for "IndeX".

http://pandas.pydata.org/pandas-docs/stable/generated/pandas...

It's also really useful to add naming conventions that convey how expensive something is. For example:

    myObject() // Returns immediately always
    getMyObject() // Might do some light calculation
    fetchMyObject() // Doh, better cache this!

Names can be extremely useful to convey expected usage as well.

MacOS's Core Foundation API has naming conventions related to object ownership: "create"/"copy" = you own the object returned by the function, you have to release it after you're done with it. "get" = you don't own it.

https://developer.apple.com/library/mac/documentation/CoreFo...

+1. Another one I use is "generateX()", usually for heavy calculations like image processing or PDF rendering.

A lot of the time that type names end up in method parameters, it's due to a lack of support of overloading in the language.

In particular, isn't Dart (the language described here) one such language? It's been a while since I used it, and I never wrote much, but I at least thought that was the case.

You are correct. The feature request for adding type-based overloaded function was denied: https://github.com/dart-lang/sdk/issues/49#issuecomment-1083...

> If you need a different variant of a method, create a method with a different name. ... type-based overloading is a bad idea, creating brittleness and ambiguity.

How about this? They might have changed their minds.. https://github.com/dart-lang/sdk/issues/26488

Yes, overloading is back on the table.

All of the cons with it are still there—it really is a hairy feature—but the pros are real too and might be worth doing. We still haven't figured out whether or not we will and, if so, what the exact semantics will be.

I used to like how overloading lets you call it sort instead of sortRectsByArea but over the years came to the opposite conclusion. Very short and generic names are great for locals or for truly generic functions but generally a function name shouldn't be too generic IMO, both because grep has its uses regardless of IDE support and because it makes it less necessary to look up definitions. mergeTableCells is better than merge even if you know it's passed a list<TableCell> because merge could be merging the cells or the cell contents or who knows what else, and because looking up the type of the argument costs in itself (as it's not always a local declared right near the call and even if it is, the type might not be spelled out in the declaration.)

Also, reusing names through overloading without providing actual polymorphism, either run time or compile time, is IMO bad, as in I don't get what's there to like. If one open function gets a file name and another gets a username and a password, what's so great in that they have the same name?

Rather than ``sortRectsByArea`` I'd rather have a generic ``sort`` that supports a Schwartzian transform, like Python's ``sorted(stuff, key=transform)``.

Function or method names that postfix the mode onto the verb, like "parse_from_file", are usually an indication that the design could be improved by creating a consistent interface for the various modes. Sometimes it's better to provide a handful of modes, but I always double-check when I see myself writing names like that.

[0] https://en.wikipedia.org/wiki/Schwartzian_transform [1] https://docs.python.org/3/library/functions.html#sorted

That depends a lot on your actual architecture and domain.

Some times, you need parse_from_file, and nothing else. Other times it's worth parametrizing everything and just assembly generic code at the top level.

> A lot of the time that type names end up in method parameters, it's due to a lack of support of overloading in the language.

This is true, but that's a code smell if the language supports interfaces (I don't know much about Dart, but it appears that Dart does support interfaces).

com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

http://www.javafind.net/gate.jsp?q=/library/36/java6_full_ap...

I wonder what the most interesting program you can fit in the number of bytes it takes just to represent this class's name is.

> I’m glad we now live in a futuristic utopia where keyboard farts like p, idxcrpm, and x3 are rare.

Perhaps it's the old "fart" in me, but these seem pretty clear.

p: a throwaway pointer, indicating that I'm probably in a C style for loop over an array.

idxcrpm: and index into crpm. What is 'crpm'? Dunno - what is 'window'?

x3: The third, distinct, x value. I see such variables used frequently in spatial algorithm implementations, where 'x' has distinct meaning.

It's more about knowing the idioms of the code you're in than some overarching rule of law.

Even if "crpm" is a contextually known entity, I'd consider "idxcrpm" a terrible identifier.

a) it's two words without a clear boundary – "idx_crpm" would be better (or idxCrpm if your project uses camelCase)

b) it's an unnecessary abbreviation – "index" is only two chars longer than "idx" and legibility trumps raw brevity

c) it's grammatically incorrect (without the "into" preposition that you used), hindering legibility – gramatically correct would be "crpm_index" (or crpmIndex)

Code using single letter variable names and abbreviations makes people up to 15% slower at understanding code [1, 2].

Of course it is possible to determine - bottom up - what a variable is supposed to do or that p is short for pointer, it still slows others down because it requires them to perform mental mapping. This effect, of course, depends on experience. If you write your vars like this all the time your penalty won't be as big.

[1] Influence of identifier length and semantics on the comprehensibility of source code, https://github.com/cessor/bachelor-thesis

[2] Much shorter version published in https://fg-sre.gi.de/fileadmin/gliederungen/fg-sre/wsre2016/...

Upvoted, but I'll add that I'm surprised at how small you found the effect of naming things a,b,c,... with no mnemonics at all. (I skimmed the shorter paper.)

> idxcrpm: and index into crpm. What is 'crpm'?

Are you sure it's not an ID for an XCRPM? :)

Glossed over this but it drives me nuts:

  // Bad:
  String nameString;
  DockableModelessWindow dockableModelessWindow;

See it? Don't dance around reserved words/used names in a space with caps. Arg.

As in the following?

var foo = new Foo();

Totally disagree. I find differentiating between definition and instance via caps very intuitive and clear.

I agree with much of this on principle, however one of the first examples really strikes me as poorly conceived.

One such example is the variable 'name'; there are a lot of other languages and contexts in which 'name' can be a reserved keyword. As a member on an object it's probably OK, but in a larger syntax it isn't quite precise enough. A better variable might be nameDisplay.

This presumes that you are referring to the way that a user prefers their name to be displayed in native output; it does not attempt to make any distinction to name components which may or may not be applicable.

I struggle with naming things, especially in python where we dont have explicit types,i do end up with the "strawberryList" kinds of names.

I work in NLP / machine learning and a lot of us are not first and foremost programmers. It can be hard to come by good code in terms of coding style and naming, so I'll ask here if anybody has good examples or even know of any guides (even little things like a consensus on calling it "targets", "y", "labels" or "gold" would be nice)

PEP8 is a good start, in case you're unaware of it. It contains a bunch of style guidelines for python, including some naming conventions.

> It needs to be clear: you need to know what the name refers to.

> It needs to be precise: you need to know what it does not refer to.

Is there such a generally accepted distinction between the meanings of "clear" and "precise"?

The fact that this is an issue at Google makes me think this is entirely the result of the review process rewarding it. Could they really hire so many highly qualified people with no sense of DRY?

Long variable names have some fatigue associated, but when I'm hacking on 20,000+ line files, those long names really save similar things from being blurred.

> June 2016

> Dart usage inside Google is cranking up

o_0

I am amazed at the number of people who use single letter variable names.

It's almost always better to use a double letter: uu, kk, ii, jj.

It's one of the few code patterns that most people will adopt without even discussing it once they see it.

How is it better? (This is a literal, non-rhetorical question, not a joke about even discussing it.)

Finding it in a sea of text.

Try searching for all the instances of variable "u" or "i" in a file.

Syntax-aware IDE's fail often enough that I have to rely on "search-and-destroy" far more often than I would prefer.

Why would I ever want to find every reference to a loop or lambda variable with a given name in a file? Such variables repeat frequently with distinct meanings, and each has a narrow scope.

In any case, I wouldn't use an IDE that was so glitchy unless I was forced by necessity; I certainly wouldn't adopt a coping mechanism for it into other languages. Also, for a typical compiled language, deleting the declaration gives you all usages as long as you can (attempt to) build.

Are there any other reasons? Edit: Is this advice perhaps intended to be specific to a particular context?

vim: /\<i\>/

Actually, if your cursor is on the variable "i", just pressing * or # will do the trick. I'm pretty sure other editors have similar functions.

If you really want double-letter names, :%s/\(\<[a-z]\>\)/\1\1/g would probably do the trick (well, except that every occurrence of "a" in a comment will become "aa": how to avoid it is left as exercise).

Just tested it in some different editors with some javascript because I care way too much about editors or something.

Sublime Text 3 captures the independent 'i' correctly. Though it also picks it up in comments and strings.

VS Code incorrectly highlighted all instances of the character 'i', even if it was part of another symbol. "Change All Occurrences" affected all instances of the character 'i'.

Atom doesn't appear to have this feature without plugins (though someone should correct me if I'm wrong).

IntelliJ and it's variants handled it perfectly, even understanding the actual variable, rather than just the symbol. "Rename All" would ask if I wanted to affect strings and comments, or just code (if there was an ' i ' in a string or comment, otherwise it wouldn't prompt), and it would only rename the variable within the correct scope. I tried it with both var and let.

I would try more, but I think I'm wasting too much time, haha. But moreover, like others are saying, I can't think of a time where I've ever actually wanted to do that. Renaming all instances of a single letter variable? Generally the single letter is a very common convention I wouldn't change (i,j,k, u, x,y, _), or is in a very small, uncomplicated function where I wouldn't need a text editor's help to rename it because it only occurs once or twice. Anything more advanced than that gets a more verbose name that any of these editors could easily ctrl+F.

Huh. Definitely keeping this one in mind, thanks!

Reply on news.ycombinator.com