1. 6
  1. 2

    there is something to be said for “useless” replacement of pseudomagic numbers like BYTES_PER_KBYTE, which is that there’s a single, well-labelled place you can check that you have not typoed the number, and the compiler will catch typoes in all other references to it.

    1. 1

      It also makes thing easier when the inevitable happens and the “constant” changes.

      1. 1

        that was the OP’s point; bytes_per_kbyte is not a “magic number”, it’s a constant that’s not going to change and should be obvious from context. i’m arguing that even given that, there’s value in having a compiler-checked token for it.

        1. 1

          Fair enough.

      2. 1

        I actually think it’s better to have these so-called “magic number”s in your code if they’re only ever used in one place and they’re not logically related to anything else whatsoever (i.e. they’re arbitrarily chosen). I think it actually conveys their purpose better and the code becomes easier to read overall.

        With these unique magic numbers, there’s no danger, really. If you need to change it, you just change it, and if you need it somewhere else, then you give it a name.

        1. 3

          Everything starts out being used once. The trick is to discover when you are adding a 2nd instance of it.

          1. 1

            I expected a comment along these lines :) The point is, even you name your constants, you still need the same trick to discover that someone else has already done that.

            1. 1

              Good point.