alt Hacker NewsIndex, Count, Offset, Size
Comments
As @SkiFire correctly observes[^1], off-by-1 problems are more fundamental than 0-based or 1-based indices, but the latter still vary enough that some kind of discrimination is needed.
For many years (decades?) now, I've been using "index" for 0-based and "number" for 1-based as in "column index" for a C/Python style [ix] vs. "column number" for a shell/awk/etc. style $1 $2. Not sure this is the best terminology, but it is nice to have something consistent. E.g., "offset" for 0-based indices means "off" and even the letter "o" in some case becomes "the zero of some range". So, "offset" might be better than "index" for 0-based.
Relatedly, a survey of array nomenclature was performed for the ISO C committee when choosing the name of the new countof operator: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3469.htm
It was originally proposed as lengthof, but the results of the public poll and the ambiguity convinced the committee to choose countof, instead.
Using the same length of related variable names is definitely a good thing.
Just lining things up neatly helps spot bugs.
It’s the one thing I don’t like about strict formatters, I can no longer use spaces to line things up.
Really like this. I'll follow this practice from now on.
Is there any reason to not just switch to 1-based indexing if we could? Seems like 0-based indexing really exacerbates off-by-one errors without much benefit
Could not approve more a I use near identical naming convention in my C codebase. Not using the standard C library to avoid inconsistencies and the awful naming habits of that era.
With modern IDE and AI there is no need to save letters in identifier (unless too long). It should be "sizeInBytes" instead of "size". It should be "byteOffset" "elementOffset" instead of "offset".
The 'same length for complementary names' thing is great.
The invariant of index < count, of course, only works when using Djikstra's half-open indexing standard, which seems to have a few very vocal detractors.
So many arguments could have been avoided if the convention was to use o instead of i in c-like for loops.
Is there any other example of "length" meaning "byte length", or is it just Rust just being confusing? I've never seen this elsewhere.
Offset is ordinarily just a difference of two indices. In a container I don't recall seeing it implicitly refer to byte offset.
I can't read the starts of any lines, the entire page is offset about 100 pixels to the left. :) Best viewed in Lynx?
Or learn an array language and never worry about indexing or naming ;-)
Everything else looks disgustingly verbose once you get used to them.
Banning "length" from the codebase and splitting the concept into count vs size is one of those things that sounds pedantic until you've spent an hour debugging an off-by-one in serialization code where someone mixed up "number of elements" and "number of bytes." After that you become a true believer.
The big-endian naming convention (source_index, target_index instead of index_source, index_target) is also interesting. It means related variables sort together lexicographically, which helps with grep and IDE autocomplete. Small thing but it adds up when you're reading unfamiliar code.
One thing I'd add: this convention is especially valuable during code review. When every variable that represents a byte quantity ends in _size and every item count ends in _count, a reviewer can spot dimensional mismatches almost mechanically without having to load the full algorithm into their head.