Hacker News Reader

Comment by leetrout | Hacker News Reader

Code like this is interesting to me whenever I see it:

const g = [['', '', ''], ['', '', ''], ['', '', '']] // grid

Why not just be descriptive and call it `const grid`? It's like we're all playing some game to be as terse and obscure as possible with variable names in all languages.

View on HN

Author here - I did put a warning in guys :-)

  Lots of the code looks pretty code-golfy - I promise I don't do stuff like this at work, neither should you

Happy to s/g/grid/ - writing the whole exercise felt a bit golfy TBH.

>> if you change the state, it runs the function again, this returns a new virtual DOM

What do you mean by "change the state"? How do you do that? By calling some function, or perhaps by assigning a value to some property of a state-object? OR by calling the function again with a different state-object?

Thanks

I have no problem with abbreviations over a limited scope but looking at this code[1] I can't figure out what the author meant by 'm' and that makes me wonder if the author does know what he's doing.

[1]: https://github.com/leontrolski/leontrolski.github.io/blob/ma...

edit: Ok, I should have read the article first. It's probably for https://mithril.js.org/

Using m or h as VDOM constructors are mithril/hyperscript-isms, I guess that's not obvious if you not worked with those or similar libraries, sorry!

yep, I figured that out by reading the actual article instead of straight jumping to the source and my edit was too slow. I'm sorry ;-)

Totally agree.

Code should be stupidly obvious so that reading it consumes as less cognitive resources as possible.

Yep, let the minifiers and obfuscators handle the minification and obfuscation.

So many code examples have things like this and worse.

One I saw the other day had about 10 variables created in one part and then these were all placed into another object that had the same names as all the variables.

You also see a lot of examples with loads of other irrelevant code in them.

Just keep it simple please!

"Code golf"

https://en.wikipedia.org/wiki/Code_golf

If that grid was going to be used in a single loop or something I may write it like that but any larger scope and it would definitely have a descriptive name.

It wouldn't annoy me so much if they hadn't put the comment. I can clearly see it's a grid.

cries in golang

For small functions / blocks and descriptive types I’m ok with it in Go BUT I always use descriptive names anyway. So much easier to keep context in my head.

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.

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.

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).

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` ;)

Comments in code are almost always an indication of poor naming choices. I don't get it either.

He saw grid in his head and thought g was fine since he was doing a minimal poc. It's not something that's hard to understand.

Aesthetically, it's consistent with the article.

Technically it's consistent with ordinary practice. e.g.

  import naughtsAndCrosses as nan

I'm not sure this is "ordinary practice", especially as `nan` often refers to "not a number" as an error category.

Typing full words doesn't take that much longer than acronyms, and results in more readable code (although this is well enough established at this point that I don't think I need to go over it).

Bugs are ordinary practice. Importing naughts and crosses is not. I giggled mischeviously when I wrote it. Particularly since it looked Pythonic. YMMV.

Reply on news.ycombinator.com