Hacker News Reader

Comment by libria | Hacker News Reader

I thought the whole single-char-var thing was for very short-lived variables.

I very much prefer

    for c in internalProductCategories
       p = fetchProductsInCategory(c.id)
       m = getAccountManagerName(c.id)
       results.append({categoryName: c.name, products: p, manager: m.name})

    for internalProductCategory in internalProductCategories
       products = fetchProductsInCategory(internalProductCategory.id)
       manager = getAccountManagerName(internalProductCategory.id)
       results.append({categoryName: internalProductCategory.name, products: products, manager: manager.name})

They're both clear, neither needs comments, but one is unnecessarily verbose.

View on HN

While that's definitely better than single letter variables everywhere, I still think an explicit variable name is better.

In general, I follow a rule of "If I can't search the file for this variable and find it easily, it's a bad name".

Isn't this the standard argument for making names more specific as the scope where they are visible gets larger?

Something only used within a short function, so it only ever appears within a few lines of where it's defined, can probably be very short or even a single letter, and that conciseness can be beneficial.

Something used elsewhere in a file should probably have a more descriptive name, so it can be easily distinguished and located.

Something exported from a module and used elsewhere in the program should probably have both the more descriptive element and then, one way or another, some further way to identify that it's the version from that particular module that is being used.

I get what the argument is saying, but there might still be times where I want to find every mention of a variable within a 3-line block. If that variable is a single letter, and possibly a letter that's used 10-20 times in the code in that block, I would consider that block confusing.

Ultimately, I don't think there's any hard rule or standard, just an evaluation of how easy it is to understand the code. Sometimes a single-letter variable will be fine, sometimes not.

But I'd bet a 4-letter variable will always lead to code that is easier to understand.

What if the references are all [i] or [i + 1]?

Put a comment block at eof defining them and their usage. Use these variables in such a way that ctrl,f replace all with a descriptive name doesn't break anything except the line count and pretty print.

If you want to get really clever, write a script that automatically renames everything and reflows the file on commit.

Damn it. Now I need to make this...

> "If I can't search the file for this variable and find it easily, it's a bad name"

Like parent mentions, this is about scoping. My rule about short variables is that I have to see their _full_ use (including declaration) in only a few lines on the screen.

Personally I prefer single letter variables especially in lambdas for consistency (x, y, z).

The latter requires you to read the assignment to figure out what the variables mean.

This is true, it is classic data denormalization - in the latter example, if all we want to gloss is the results appending, we need to read less

On the other hand, the former is much more scannable, so maybe that doesn't matter.

I don't understand what this means.

Just that the shorter names make for a more concise presentation, which in turn is quicker to scan than having to see and parse all the long names to reach the same conclusion.

Strongly disagree there. If there was a crash at line 4, in the first example you would only see this:

> results.append({categoryName: c.name, products: p, manager: m.name})

In the second example you would see this:

> results.append({categoryName: internalProductCategory.name, products: products, manager: manager.name})

Do you know what the error would be? Probably that you're assigning the manager's name to a property called `manager` ;)

Reply on news.ycombinator.com