|
|
|
|
|
by peterwaller
3380 days ago
|
|
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. |
|
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.