7 ms·
Yeah, I used to go by this advice, and I found the maintainability of my code dramatically increased when I typed out full names. I don't even use "i" for loop
by pcwalton 8y ago
Yeah, I used to go by this advice, and I found the maintainability of my code dramatically increased when I typed out full names. I don't even use "i" for loop variables anymore. If the length is a problem, invest in an editor with autocomplete.
Well-known abbreviations are fine, like "iter" and "prev", but single-letter variable names notoriously impede readability for me.
- dilap 8y agoI feel like I have the opposite problem. If the name is more than a few characters long, it starts to become non-instantaneous to recognize it. Things get much easier to follow with visually-instantly-recognizable symbols. So in conditions where a variable is used over a short area in the code (or where it's used _constantly_ over a wide area), I prefer short variables.
- hackinthebochs 8y agoTotally agree. If you have to scroll up to be reminded what some variable means, a longer name is good. But if its usage is a few lines away from its declaration then there's no reason to add visual noise to your code.
- shaan7 8y agoIts easier said than done though. We started following this few years back but then while it was "few lines away" originally, code evolved and now there are parts where its 20+ lines away. This means that short var names need to be continuously "enlarged". Well, then why not start with a "medium" name and avoid all that headache? ctx is a good enough compromise between c and context. (c can be client, config, context, certificate ... you get the point).
- Cthulhu_ 8y agoWell as the article states, one-lettered variable names should only really be used in tight loops; `ctx` is a better name for e.g. a function argument.
- yawboakye 8y agoRarely do you have a case where a variable outgrows its simple name (and value) and you keep it the same. Even when a function adopts new characteristics it's advisable to change it's name or make a new one. If you initially had variable `i`, created and destroyed in 5 lines of code but that has grown to 20+ lines, I'd recommend you (1) not add the 15+ if it could be put in a function (you get to name that section of the code), or (2) rename the variable. But a 5-line code that becomes 20+ lines is both strange and interesting.
- burke 8y agoThis wouldn’t likely be hard to write a linter for: is the name 1-2 letters other than a method receiver, “i” or maybe “j” and is referenced more than 5 lines from where it’s declared? Lint warning.
- lugg 8y agoI tend to agree here but I limit that to block scope as a general rule, I also only bother with really common concepts. id identifier i loop counter j inner loop counter c general purpose non loop counter a, b, comparator methods k, v, key value setters, array iteration e, event, error or exception. Contextual rule but rarely collides. Other than those I pretty much always write entire full word names. If it's abbreviated or shorthand it likely sounds funny in my head, or it leads to ambiguation. If I need to even ask / recall for a split second it's not good enough. Programmers incorrectly place far too much weight on time to type. I write like ten lines of code on a good day. It's just not important. I want readable code that is clear and concise as possible. Every branch, block or shorthand variable raises a question I have to think about before moving on. Clever code is why I call ten lines of code a good day. It sure as shit isn't my typing speed.
- wnevets 8y agoFor me Config just isn't one of those cases, HackerNewsOnYCombinatorMessageBoard on the other hand becomes an opaque mess to eyes when it is mixed with other variables of similar length and complexity.
- mntmoss 8y agoDense code that benefits from dense variables(which describes a lot of "pure algorithms" work) I often approach by aliasing the variables to shorter ones. It's all in the same body so the context is not especially hard to lose.
- ivanhoe 8y agoIMHO short is OK as long as the name makes sense and is easy to connect to the real meaning. For instance "msg" is perfectly valid name for a message var, and even "m" in some short snippet of code is obvious, but calling it "a" or "x" or something completely unrelated like that is a bad idea. In matter of fact calling it something too neutral like "data" can also be as bad if it's not clear which data you mean. Context is everything in making it easy to understand.
- Cthulhu_ 8y agoI think you're identifying the core issue here, that is, frequently vs infrequently read code. I'd argue that if you've spent enough time in go, variables like `i`, `conf` and `ctx` will become very recognisable and easy to skim over, if they're always used in the same context. If it's less "boilerplate" code, I'd go for more descriptive names. I think. I like the sorta described "rule" in this document; the longer the variable is used, the more descriptive it should be.
- apoorvgarg 8y agoRegarding single-letter variables, mathematical functions might be an exception. I think writing func gcd(a, b int) int {...} is better than other alternatives. There is simply no need to assign any more meaning to the arguments other than their type.
- bnolsen 8y agono, it's not. bigger deal is that single letter vars make it much harder to search for variable usage in files using arbitrary editors.
- apoorvgarg 8y agoWhat would be the signature of your gcd function ?
- base698 8y agoNumerator, denominator?
- coldtea 8y agoGood luck with any bigger equation then
- mrgriffin 8y agoFor GCD? I would find those names very misleading since semantically the order of the arguments to GCD is irrelevant (even if in the implementation you typically mod by b there's no reason you couldn't mod by a).
- sacado2 8y agoThis is not mathematically correct. Those names would be pretty misleading, actually.
- coldtea 8y agoDon't use arbitrary editors, or editors that don't support "search for standalone identifier" (e.g. surrounded by space, in (), with ; after etc.".
- solarkraft 8y agoIn short Go functions I tend to like single letter variable names. Maybe because it makes me closely consider the behavior of the program instead of trying to assume by the variable names.
- PavlovsCat 8y ago> I don't even use "i" for loop variables anymore. Yeah, I noticed that for myself, too. so instead of i I might use frame_index, or whatever it "actually is". Up to a certain length it seems faster to just read what is there, without an additional mental translation step. But to be honest, I just do it because I like it.
- Gibbon1 8y agoI do that off and on, mostly because with the editor I use, it's harder to highlight single letter variables.
- zbobet2012 8y agoI generally find if you need multi letter variable names it means your function or scope is to long, or manipulating to many things. It's a nice little red flag for me. Up to four or five single letter variables is pretty trivial to remember. Especially when three of those are i, j, and k. More than 6 or 7 rapidly becomes painful. But if you are manipulating 6 or 7 variables _in the same scope_ you are doing to much. I also agree with Pikes comments about typography here: http://doc.cat-v.org/bell_labs/pikestyle http://doc.cat-v.org/bell_labs/pikestyle
- pcwalton 8y agoI could not disagree more. When I'm skimming code, I want to immediately know what a variable means. I don't want to go cross-reference elsewhere.
- zbobet2012 8y agoIf you have to go "cross-reference" elsewhere you are modifying something "to far away" from you. That's a giant sign of spaghetti code. Also names vary with there contextual scope. Larger scopes mean longer names generally. Russ Cox gives a succinct description here: https://research.swtch.com/names https://research.swtch.com/names A name's length should not exceed its information content. For a local variable, the name i conveys as much information as index or idx and is quicker to read. Similarly, i and j are a better pair of names for index variables than i1 and i2 (or, worse, index1 and index2), because they are easier to tell apart when skimming the program. Global names must convey relatively more information, because they appear in a larger variety of contexts. Even so, a short, precise name can say more than a long-winded one: compare acquire and take_ownership. Make every name tell. Variables should generally have short scope (we don't want a lot of global, or even package level variables). So _variable names_ in particular should be short.
- bpicolo 8y ago> For a local variable, the name i conveys as much information as index or idx and is quicker to read This is only true because i is a specific, common abbreviation for index. When writing arbitrary glue code, a single letter variable would be a meaningless abbreviation without shared context. If you encounter "i" and it doesn't mean "index of a for loop", you're going to be taking additional time parsing meaning.
- eternalban 8y agoI think 'k' and 'v' are fine for iterating over maps.
- ori_b 8y agoReadability is a problem -- long variable names are harder to skim, and rapidly begin to blur together for me.
- bdamm 8y agoAgreed. Step through the code in a debugger if you really want to understand what it's doing. Even unreproducible problems with production code can succumb to raw understanding gained from stepped test cases.
- coldtea 8y agoWell, for most things ok, but i is so well established, than if you don't use it for loop indexes you you probably impede the readability of those reading your code
- pjmlp 8y agoI am fully there with you, the only exceptions are still using "I" in short for loops, e for WPF/Forms event handlers due to convention and typical math symbols like x,y,z.
- dnautics 8y agoI stopped using "i" when I had it in a context where it could be easily confused for "imaginary constant".