5 ms·
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 priorit
by alimbada 10y ago
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.
- fiatjaf 10y ago'error' is a protected keyword in Go.
- LukeShu 10y agoNitpick: 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.
- fiatjaf 10y agoThat's what I meant. If I didn't say it, it was because of a typo.
- alimbada 10y agoThen use another word; 'defect' and 'fault' are two acceptable synonyms I managed to look up in less than a minute.
- fiatjaf 10y ago'response' is too large. Having too large lines is not great for readability.
- aninhumer 10y agoI 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.
- alimbada 10y agoI don't know why you were downvoted for this. I, for one, completely agree.
- yule 10y agoThe article is from 2014
- alimbada 10y agoThat's besides the point. Go and Rust developers still use abbreviations unnecessarily everywhere.
- peterwaller 10y agoWhile 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 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.
- chillingeffect 10y agoWe'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.
- wlll 10y agoMaybe 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.
- tedchs 10y agoThis 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.
- alimbada 10y agoCommon 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.
- artursapek 10y agoGo programmers have no trouble reading err and resp, since they're so standard.
- deleted 10y ago[deleted]
- didip 10y agoJust 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.
- sagichmal 10y agoWhen programming in Go, err and resp are inarguably more readable than defect/fault or response would be.
- hazbo 10y agoAndrew 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.
- cube2222 10y agoThose 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