Hacker News Reader

Comment by alimbada | Hacker News Reader

It's 2017 and developers are still abbreviating variable names ('err', 'resp', etc. in the article). It's tragic that readability is still not seen as a priority by so many people.

View on HN

While I agree readability is key, you may find people who disagree about what constitutes "readable". I think the Go community in particular may be partially inspired by the philosophy outlined under "Variable names" in Rob Pike's "Notes on Programming in C":

https://www.lysator.liu.se/c/pikestyle.html

Quoting:

"Ah, variable names. Length is not a virtue in a name; clarity of expression is. A global variable rarely used may deserve a long name, maxphysaddr say. An array index used on every line of a loop needn't be named any more elaborately than i. Saying index or elementnumber is more to type (or calls upon your text editor) and obscures the details of the computation. When the variable names are huge, it's harder to see what's going on."

I don't agree with everything written therein, and it was written circa 1989. But in practice single letter variable names are used diligently and frequently in Go, they're convenient and don't break readability if you understand the (simple) convention.

We've learned a lot since 1989. And while clarity is more important than length, clarity has more dimensions than length.

For example, maxphysaddr we now write: max_phys_addr. And when it comes to loop indices, using single letter 'i' isn't practically searchable.

Also, our notion of iterators has progressed in the last 27 (gulp) years. Arrays these days are generally too abstract. There's a reason a block of values has been assembled. If they're pixels or bananas, the index can represent that, e.g. for( banana_idx = 0; banana_idx < bananas.num; banana_idx++ )

This is doubly important in blocks of code where multiple types are used, for example, a uint8_t for one index, a unit16_t for another. They need different variable names anyway, so make name them germane to their function.

"Amount to type" and especially "calls upon your text editor" are irrelevant to clarity.

Maybe it's because I program Go, but I don't find the use of err and resp diminish readability. I don't feel any cognitive hurdle when reading those code examples.

Just like everything else, moderation is key.

* err, i, req, resp are so common in a lot of Go codebase that they become a convention themselves. So it's not that hard to read. Another example: Javascript's function(e) {}

* If a name is too long, it impedes readability as well, e.g. SimpleBeanFactoryAwareAspectInstanceFactory.

Andrew Gerrand did a great talk a while back (I'll try to hunt it out) in which he talked about naming conventions. One of the things that stuck out for me, was when he said, if you're declaring a variable that is only going to be used very locally (i.e. within the next few lines or around there), then using a short name is preferred. So instead of 'response', you would simply use 'resp'. However if you're declaring something that may be used in a different part of the file, or Go package itself, go with something more verbose as to not confuse someone seeing it for the first time with no prior context. Also `error` is meaningful in Go, so `err` is used pretty much all the time.

'error' is a protected keyword in Go.

Nitpick: Syntactically speaking, it's not a keyword. But it is a universally defined type name, which means you can't use it as a variable name.

That's what I meant. If I didn't say it, it was because of a typo.

Then use another word; 'defect' and 'fault' are two acceptable synonyms I managed to look up in less than a minute.

I mean... is using 'err' really that big of a deal?

Given that errors and error handling itself is a very normal thing to come across in most projects, would the abbreviated `err` not seem more familiar than defect or fault, to you?

This is actually common convention for Go. One letter variables are used throughout the canonical examples, coupled with very short functions that cause this to make more sense.

Common convention doesn't make it automatically readable.

Every modern language should strive to be user friendly. Gone are the days when we were constrained by hardware limitations which caused us to adopt such practices in the first place.

One letter variable/parameter names is a despicable trend. Abbreviated function names are also rather vile in my eyes.

Those names are conventions. Same as in languages like Haskell/Scala where type heavy code will have type names A, B, C, D.

It's a matter of getting used to, leater it's easy and fast to read.

Abbreviations I can think of right now are: w writer, r reader/request, i, j, k, ctx context, resp response, req request, err error, cli Client

'response' is too large. Having too large lines is not great for readability.

I don't know about other people, but I read symbols not characters, and having those symbols be actual words makes them easier to parse.

In this case, it sounds like resp is commonly used, so that's not necessarily a problem. But in general, if a line is long enough that shaving a few characters off a symbol helps, it probably should be split up regardless.

I don't know why you were downvoted for this. I, for one, completely agree.

Go programmers have no trouble reading err and resp, since they're so standard.

The article is from 2014

That's besides the point. Go and Rust developers still use abbreviations unnecessarily everywhere.

When programming in Go, err and resp are inarguably more readable than defect/fault or response would be.

Reply on news.ycombinator.com