> But none of this matters in the big picture. What matters is all this code is wrapper in a function that goes like "getFirst42Bits(int)"
I disagree. Imo, `getFirst42Bits(snowflake)` is worse than `snowflake >> 22` — not only is it longer, but it also hides away the implementation in a way that could obscure bugs/require `jumpToDefinition` debugging.
Abstraction is often useful, but this seems like a textbook case of over-abstraction.
I disagree with your disagreement. I don't know what 22 is and how that is related to the initial requirements: get the first 42 bits. (Non-)ironically the requirement matches the suggested function name.
What I see is just a rare operator and a magic number.
This is quite obvious if you have spent some time using bitshift operators, just like inheritance and traits and all that are quite obvious if you have spent some time with OOP. If you have never programmed in C or C++ or the likes then you probably don't have a strong intuition about 8,16,32,64 and the bit operators. You probably don't know how to express a couple of common numbers in hexadecimal either.
Different programming. Not better or worse.
For the record, I had no fucking idea what that code snippet in the article was supposed to be doing had I not know the objective or function name beforehand.
I think they knew that. Their point was probably that it's better for code to directly express the requirements rather than meet the requirements through the expression of other data that isn't immediately obvious to be related at a glance. In this case, it isn't obvious that the 22 is related to the 42 in the requirements until you notice that the int size is 64. `snowflake >> ((sizeof snowflake) * 8 - 42)` is better. Even better would be putting the 42 in a descriptive constant.
Not to brag but to me it was obvious. You just kind of get an intuition for these things. It's okay to use that intuition to program more expressively.
You realize I used this placeholder name just as an example, since I have no idea what function this code was a part of.
That said, a one-liner function that's semantically specific to an app (where 42 bits is important for some reason) is absolutely harmless. The compiler will inline it, while for you it represents an opportunity to refactor this in one place. Because the assumption is you call a function at least twice, or it wouldn't be a function in the first place (some exceptions but mostly it's the rule).
I disagree. Imo, `getFirst42Bits(snowflake)` is worse than `snowflake >> 22` — not only is it longer, but it also hides away the implementation in a way that could obscure bugs/require `jumpToDefinition` debugging.
Abstraction is often useful, but this seems like a textbook case of over-abstraction.