Hacker News Reader

Comment by CWuestefeld | Hacker News Reader

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 failed to account for the fact that some numbers have intrinsic meaning that should allow their use directly. But to be compliant with the standard, our C code had this boilerplate up near the top:

  #define zero 0
  #define one  1

This, of course, only served to make every page of code harder to read. And it didn't really even solve the problem it was meant to. We once found in some source code:

  #define thirteen 13

which of course did nothing to show us why that particular value was relevant.

View on HN

An application I touched a few weeks ago has a DB column named 'type' with values 1,2,3. So on to the source code we go:

  enum RecordType {TypeOne(1),TypeTwo(2),TypeThree(3); RecordType(int dbValue) ...}

As it happens, I know an end user of this particular beast, so I show her some record IDs of each type and ask in what way they differ. She looks a few seconds, then says: 'This is clearly a type one record, the next is a type two, and here you have a type three'. After a little back an forth, it turns out even our internal course for new personnel talks about 'records' with different rules to follow for 'type one/two/three'. The end users have no other word to describe these entities than 'records' each with its own numbered type, and think about it as completely natural. The application is based on an older COBOL application, and the terminology just stuck around.

Clearly, the application is well-written: The enum uses the terminology used by the business. Another of my flabbers just got ghasted.

This part looks like those people formed a neural network. They are able to learn to act quasi-intelligently, but when you peek inside, the internal model is just a bunch of numbers.

Edit: scratch that neural network. They just made one neuron so far.

Three categories? That kind of complexity requires at least two artificial neurons.

One benefit there is that you don't get left with only context for what type one records used to be like before some evolving. The only baggage kept is by people aliasing that name in their own memory.

You don't get screwed because you called something apple to start with, but it now represents a race car

Sometimes people just can't think of a better term and it sticks. It makes sense if there's some ordering implied but in quite a few of these there's none:

https://en.wikipedia.org/wiki/Type_1

https://en.wikipedia.org/wiki/Type_2

https://en.wikipedia.org/wiki/Type_III

https://en.wikipedia.org/wiki/Class_1

https://en.wikipedia.org/wiki/Class_2

https://en.wikipedia.org/wiki/Class_3

etc.

https://en.wikipedia.org/wiki/Hierarchical_database_model

This was pretty common on mainframes, before db2 and other SQL databases

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)

Using NULL for the integer 0 requires a cast in C (because NULL may have a pointer type). That doesn't break the GP's rule, however neither does `!I` or `I-I`.

For extra fun, put it into the code like this, including the `...` instead of the actual values. (Make it compile by commenting that line out.) Then define IV somewhere else but make sure to use III before every use IV so someone unfamiliar with these constants see the “right” definitions first.

    iv = secrets.randbits(IV)
    plaintext = "Text for encryption"
    aes = pyaes.AESModeOfOperationCTR(key, pyaes.Counter(iv))
    ciphertext = aes.encrypt(plaintext)
    print('Encrypted:', binascii.hexlify(ciphertext))

The Roman numeral for ‘0’ is (nonclassically) ‘N’; there are attestations going back to the early 6th c. It stands for “nulla” or “nihila”.

Or, just program in INTERCAL (https://en.wikipedia.org/wiki/INTERCAL)! Integers are input in English (e.g. THREE FIVE NINE) and output in Roman numerals.

> There is no zero in roman numerals

    #define X_MINUS_V_MINUS_IV_MINUS_I 0

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.

It's "obvious" if you take into account the corporate culture I guess. The rule of 'no magic numbers' is generally good, but then one has to remember that some numbers (like 0 and 1) are not magic.

0 and 1 can be magic if the context depends on them being arbitrarily 0 or 1. eg.

// this byte is unused and always 0

#define UNUSED_CONSTANT_FIELD_VALUE 0

bytes = {HEADER, UNUSED_CONSTANT_FIELD_VALUE, [...]}

Let me tell you about the system where null and 0 are treated as equal because in some programming languages will coerce null to 0. It just so happens that for an important business type in this system:

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

When formulating the rule, they didn't understand the point of it. They think "naked constants === bad" is equivalent to "no numbers in source".

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)

> 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;

"What do you get if you multiply six by nine?" = 42

until someone runs a spellcheck on this code and changes all locations to fortytwo

Fourtytwo: a number equaling four amounts of ten plus two singular amounts.

Fortytwo: a defensive fortification with a nickname. See also Boaty McBoatface.

The use case I'm familiar with is when the fn you're calling requires a pointer. Common for ioctl(..., &one) calls.

If you look later in the code that's exactly what is happening here.

  #define zero 0

is just bad programming, barring some philosophical code which cares about "zero-ness". Names need to reflect what they represent, not their precise values. Are we looking up the first index? Then how about

  #define first_index 0

? Are we summing up values which are coerced to zero when empty? Then how about

  #define empty_value_integer 0

  #define additive_identity 0

Yes, that means there might be more than one variable with a value of zero, and that's completely fine since we now have several megabytes available for both source code and for compilation.

To be clear, I'm not endorsing the rule, just saying that there are more productive ways of dealing with it.

>barring some philosophical code which cares about "zero-ness"

But that is the intrinsic meaning OP was talking about. Plenty of mathmatics deals with 0 or 1 as important constants. If you have a function that mods by a parameter, you need error handling for zero. Calling it value_that_causes_undefined_behaviour isn't going to improve code clarity. Beyond that;

for (i = 0; i < IMPORTANT_QUANTITY; i++)

, or some variation thereof, is very idiomatic C.

My point is, if you had to pull `0` in that `for` loop into a variable, would you call it `zero` or `first_index` (or something else actually relevant to the loop)? I'd certainly prefer something relevant to the loop rather than `zero`.

'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 clear and concise name--which is an art.

Heh, try for

     #define 0 0

  > #define 0 0

That actually works on some implementations (the preprocessor grabs a token without checking that it's a identifier). I've seen:

  #define $ SOME_LINE_NOISE
  #define && HACKY_GARBAGE
  x = &&(y $ z);

as well.

We have something similar in my my organization's Fortran code. We have constants KI1, KI2, KI3, ... etc corresponding to (k)onstant integers 1, 2, 3, ... etc. Someone got the idea that hard-coded numbers were bad. All it does is make code harder to read to anyone unfamiliar with these conventions.

Did you have an automatic static code analysis tool to flag non-compliance? This is the sort of thing I see and use to warn people away from blindly spending money on this sort of thing, installing the tool, and calling it good.

Reply on news.ycombinator.com