• my name (unregistered)

    INT_FORTY_TWO is missing, too

  • Bogolese (unregistered)

    Full disclosure: I'm so damned old I started out programming in (clutch pearls) . . . COBOL! Because of the way the compiler that particular language structured its object code, all declared variables were at the top, all opcodes were in the middle, and literals were stuffed at the end (in the "literal pool"). Therefore "best practice" at the time was to declare all literals as variables (so called WORKING STORAGE back then), so something like this was de rigeur. And the stuff of nightmares!

  • (nodebb)

    Interesting that they have both FLOAT_TEN_HUNDREDTH and FLOAT_ONE_TENTH. Brain fart, or a tiny glimmer of context for how these constants might be used?

  • L (unregistered) in reply to jkshapiro

    FLOAT_TEN_HUNDREDTH has an extra zero at the end.

    if it actually matters somehow, that's another different WTF

  • RequiredName (unregistered)

    I hope that they don't use the FLOAT_TWENTY_FIVE_THOUSANDTH value, because it'd normally be 0.025f - not 0.0025f.

  • Tim Ward (unregistered)

    Perhaps a slightly extreme response to a "no magic numbers" coding standard.

  • Hanzito (unregistered)

    And so neatly alphabetically sorted. How helpful!

  • (nodebb)

    To me it smells of malicious compliance.

  • noOne (unregistered)

    Some names are even different from their values: public static final float FLOAT_ONE_DOT_TWO_TENTH = 1.2f; public static final float FLOAT_TWENTY_FIVE_THOUSANDTH = 0.0025f;

    I would read the names more like 1.2 / 10 = 0.12 and 25 / 1000 = 0.025

  • Scott (unregistered)

    I come here for INT_TWO reasons: to learn from the mistakes of others and to boost my ego by realizing that no matter how badly I've screwed up I have never done THAT stupid thing. Today's installment falls into the 2nd category.

  • TheCPUWizard (unregistered)

    Just for fun, I would have used literals in octal, hex, or binary with the names representing the decimal quantity.....

  • Jorge (unregistered)

    I am afraid I have used certain linters and code "quality" tools that would not allow you to commit the code unless you did something as atrocious as this :( So - maybe the author has some excuse

  • (nodebb) in reply to Jorge

    The intent was surely to encourage you to add meaningful symbolic names. Replacing the magic numbers written in digits with magic numbers written in words doesn't seem to be a useful use of anybody's time.

  • Argle (unregistered)

    Well, the old programmer in me needs to point out that once had practical meaning for me. Language? ForTran. Processor? TMS9900, the one that went into that little TI home computer back in the late 1970s. It was the first 16-bit machine marketed to the home. It wasn't very successful, but Lear Siegler put them in some of their avionics hardware. (More details here: https://thedailywtf.com/articles/keeping-busy). The code we did in ForTran had lots of constants named ONE, TWO, THREE, TEN, etc. The logic was simple: Back in 1978, the amount of memory was likely to be 8K or so. Having a crap-ton of global constants saved bytes over using constants.

  • Bananafish (unregistered)

    So .... magic constants?

  • (nodebb)

    Or, maybe, Magic Constance -- Paula Bean's brillant cousin?

  • MrBerryK (unregistered) in reply to my name

    INT_FRIST is missing too!

  • Aitkiar (unregistered)

    I love when this happens with a db. I've seen the same everything must be a coinstant aproach aplied to table names, column names, ...

  • (nodebb)

    At least the numbers match the text... let me remind you of this... https://thedailywtf.com/articles/what-you-don-t-see

  • Splatmandeux (unregistered)

    Seen this sooooo many times, almost always caused by a 'coding standard' document someone with a title of "Process Manager" or some such copy/pasted from a google search of "best software practices". Probably not the dev's fault.

    "There shall be no naked constants, ever" for (int i = ZERO; i < len; ++i) {} Yes, it's a real thing.

  • dpm (unregistered) in reply to Steve_The_Cynic

    How to code malicious compliance:

    public static final int INT_8 = 8; public static final int INT_11 = 11; public static final int INT_1900 = 1900; public static final int INT_0_0025f = 0.0025f;

  • (nodebb)

    Well this:

    public static final float FLOAT_TWENTY_FIVE_THOUSANDTH = 0.0025f;

    would confuse the heck out of me, because I'd mentally parse the name as 1/25,000. That looks like it should be called FLOAT_TWENTY_FIVE_THOUSANDTHS. The S is very important.

  • Lőrinczy, Zsigmond (github)

    Some 30+ years ago I also heard about a Cobol-programmer who was told not to use 'magic literal values', so he defined LT_ONE as one. (That might come handy when it should be changed to two or three.)

  • (nodebb)

    We have plenty of that nonsense in our Fortran Code base, though the list isn't as long.

    It makes sense to have

    real(dk), parameter :: pi = ! Something with ATAN

    It does occasionally help to have

    real(dk), parameter :: pi2 = 2.0d0 * pi

    It definitely makes sense to have such definitions for physical constants.

    It never makes sense to have

    real(dk), parameter :: zero = 0.0d0
real(dk), parameter :: one = 1.0d0
  • (nodebb) in reply to R3D3

    At least not in Code that was written in the 2000s for simulations, that probably needed more than just a beefy desktop PC when the first versions were released.

  • (nodebb)

    Gosh, it's like C didn't invent enums like decades ago some times :-) Don't get me wrong, they weren't perfect cause they weren't scoped in their declaration but still... we are talking 70s here, I wasn't even born yet and when something is older than me, it's pretty much ancient.

  • Oracles (unregistered)

    Should have just added a couple macros:

    #define INT_WITHOUT_MAGIC(i) i #define FLOAT_WITHOUT_MAGIC(x) x

    so instead of replacing 0.59f with FLOAT_FIFTY_NINE_HUNDREDTH, you could just say FLOAT_WITHOUT_MAGIC(0.59f) and be done with it.

  • Tom (unregistered)

    The very first O is actually a 0. Off to a great start!

  • (nodebb) in reply to R3D3

    I remember making a piece of (theoretical physics?) FORTRAN code compile back in 1992 by factoring out the very large number of places in the expression that used pi and e so that they'd compute them once instead of over and over. This meant that the compiler stopped choking on the expression...

  • (nodebb)

    I like FLOAT_0NE_HUNDRED_FIFTY. It's a nice touch to replace the O with a 0. It reminds me of the likely apocryphal story of a contractor who on learning hew was not having his contract renewed, numbered all the variables sequentially then replaced their names with vn where n was their assigned number then converted the numbers to binary and replaced all the 1s with Os so you might have

    v0O0O = vO000 + vOO00;
  • (nodebb) in reply to Lőrinczy, Zsigmond

    I worked on project where a programmer did almost exactly that. She had a constant named WC_FIVE (working storage constant five) which was defined as 5.

  • Duke of New York (unregistered)

    I'm guessing this is from an Android project? Layout dimensions ... request codes ... date stuff

  • Duke of New York (unregistered)

    I've had the pleasure of working with developers who, when they needed a name for a constant, why, they'd just look through the entire constant table for a name that was already defined to that value, whatever it might be, and reuse it. So the width of a widget in one screen would be set with the name of the height of another widget on a completely different screen. Think of the space savings!

  • (nodebb)

    These code snippets are pure gold. It's like stand-up comedy. Improv surprise!

    Anyhow, that's the typical "there are rules, comply or be fired!". Done. The best way to comply with a by-the-book rule is a by-the-letter answer.

  • (nodebb) in reply to Duke of New York

    they'd just look through the entire constant table for a name that was already defined to that value, whatever it might be, and reuse it

    That's arguably much worse than

    #define THREETWOZERO 320

    because it turns the previously semantically meaningful

    #define LICENSE_WINDOW_WIDTH 320

    into a bad name for the magic number 320.

    So: Congratulations. Your coworkers took the already stupid-enough-that-it-should-be-only-a-joke misinterpretation of "no magic numbers" and made it much, much worse.

Leave a comment on “Constant Adventure”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article