I get why you would prefer to name constants for their use, like `numIterations=3` or whatever, but renaming every integer seems senseless.
I get why you would prefer to name constants for their use, like `numIterations=3` or whatever, but renaming every integer seems senseless.
Which, of course, is wrong. They're not the same. Same bastardization happened to Hungarian Notation, IIRC. It was meant to add some information to variables, like `iterN` for a counter, or `lenX` for a length, but someone somewhere decided that you were meant to prefix with the most primitive of type info, so you get stupid shit like `intN` and `intX`, and aren't much more informed. (Especially with an IDE showing the type info)
// this byte is unused and always 0
#define UNUSED_CONSTANT_FIELD_VALUE 0
bytes = {HEADER, UNUSED_CONSTANT_FIELD_VALUE, [...]}
the range of the type is the non-negative integers up to (2^32)-1
semantically, the value cannot be null
when the value is 0, the code treats it as a special case
null is treated as 0
If you look later in the code that's exactly what is happening here.
When the integer itself is self-explainatory but you can't just assign the integer as a name.
For example:
constexpr int 42 = 42; // compiler error
So instead: constexpr int fourtytwo = 42; // yay!
However the obviousness of what 42 means is debatable. int universe = fourtytwo; // why?
int sum = fourtytwo; // sum... of what?
int magic = fourtytwo / 7;Fortytwo: a defensive fortification with a nickname. See also Boaty McBoatface.