71–80 of 105 posts
Earlier quoted context omitted.
When unsigned three = 1; is accompanied by unsigned five = 5; unsigned seven = 7; what would be the sane conclusion?
These are variables that will change anyway, so the initial values are probably not that relevant to their name?
Earlier quoted context omitted.
Why is the reason for doing this obvious? I can't see any benefit. I get why you would prefer to name constants for their use, like `numIterations=3` or whatever, but renaming every integer seems senseless.
> but renaming every integer seems senseless. 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;
Earlier quoted context omitted.
If I was code reviewing this, I would almost certainly insist on a different name to make the WTF go away. I’m not going to suggest one here despite having read the other code comment, as doing so would be bikeshedding — not my codebase and I have no skin in this — the only point I will insist on is that I cannot believe that “three” is a sensible choice of name for whatever it does. Not even what the comment implies…
Or at least require a comment explaining it, before someone needs to dig through the code. Powers of three, five, and seven sounds a little bit like Totvald's very own little FizzBuzz game hidden in ext4's file-system source code.
What's that?
Earlier quoted context omitted.
Yeah, maybe calling them pow3, pow5, pow7 would be a bit clearer? But a 10s search for a comment cleared it up, so I don’t really see the problem...
The problem is not that it isn't clear. The problem is that it is extremely clear in a way that makes you confidently think something totally wrong.
Earlier quoted context omitted.
Not really. Nobody sane would think other sane developer with any expeirience would call a simple variable according to what it initially contains. You'd expect either name related to what is the meaning of the contents, or meaningless name.
When unsigned three = 1; is accompanied by unsigned five = 5; unsigned seven = 7; what would be the sane conclusion?
Many years ago in an age of klocs and flowcharts, at a large three-letter computer company, there were iron-clad coding rules that must be obeyed, no questions allowed. In general you could see their reasoning, but such bureaucratic reasoning doesn't pay off. One example of this was that all numeric values used in a program must be factored out as symbolic constants. The reason for doing this is obvious, but it faile…
'zero' and '0' are the same label, for the digit 0. There is no advantage to re-defining it, in fact, it does the opposite. It's a good practice to define labels for magic numbers to promote more maintainable code through the DRY / single source of truth principle, document the magic number through the label name, and improve code archeology by enabling searching by label. These principles hold when the label given a…
#define 0 0Earlier quoted context omitted.
If I was code reviewing this, I would almost certainly insist on a different name to make the WTF go away. I’m not going to suggest one here despite having read the other code comment, as doing so would be bikeshedding — not my codebase and I have no skin in this — the only point I will insist on is that I cannot believe that “three” is a sensible choice of name for whatever it does. Not even what the comment implies…
Totally agree, it would definitely be better to rename it, but I read in another comment that the kernel is loathe to rename things. So then it makes you wonder, who allowed 'number_noun = N' in the first place? "Three is the number of the counting, and the number thou shalt count to is three"
It's in the repository of a certain "torvalds". Better check twice next time what this guy's doing :)
I once spent two days debugging confusing behaviour in a serial command interface before discovering the line: #define CR_LF "\n"
It's in the repository of a certain "torvalds". Better check twice next time what this guy's doing :)
I once spent two days debugging confusing behaviour in a serial command interface before discovering the line: #define CR_LF "\n"
Many years ago in an age of klocs and flowcharts, at a large three-letter computer company, there were iron-clad coding rules that must be obeyed, no questions allowed. In general you could see their reasoning, but such bureaucratic reasoning doesn't pay off. One example of this was that all numeric values used in a program must be factored out as symbolic constants. The reason for doing this is obvious, but it faile…
I would do this: #define I 1 #define II 2 #define III 3 ... #define XIII 13 There is no zero in roman numerals, but you can use NULL for extra fun! (yes, I am a bad person)
#define X_MINUS_V_MINUS_IV_MINUS_I 0