• b0tt0mc0d3rzzz (unregistered) in reply to TopCod3r
    TopCod3r:
    One of the great things about this site is having the opportunity to educate young developers as they start out on their career.

    Constants are something you should use to make your code more readable, and it is a good idea to keep them all in a central location.

    I am not a Java programmer (although I am sure it would be easy for me), but I have chosen to go into the more lucrative field of Visual Basic, since it is higher demand and has more room for promotion. Anyways...

    In VB, I like to put constants anywhere that the value could change. For example, in our ordering system, I have all the sales tax codes as constants, so if they change, all I need to do is whip open Visual Studio, make one change, recompile and I'm finished, no big deal.

    If you are a DBA, and not a developer, you might ask why do I store them as constants rather than in a database (and beleive me I have had to fight this fight), the answer is it takes less time to re-compile my application, than submit a database change request and wait for the DBA union to run my update script.

    So the lesson I want to leave you with, it is often best to store data as constants or variables in code that YOU CONTROL than it is to store it in a database that you have no control over.

    Tongue in cheek, I hope?

  • Mike D. (unregistered)

    What would be awesome is if there were a program that could generate this Constants file for you... hmmm...

    Well, no, it wouldn't, but the idea of a single constants file with business logic named "Constants.whateversuffixyouuse" is lame. The file that has the business logic should be named something no lamer than "BusinessConstants.whateversuffixyouuse". All those other things should go live in their own private .hell files.

    P.S. Alex: that CAPTCHA thing just used black text on a background gradient fading from dark blue to black with a tinge of red.

  • (cs) in reply to Bombe
    Bombe:
    jared:
    No, good practice would be defining a constant with value 14 whose name indicates what it means. _GREATER_THAN_OR_EQUAL14 is no different than typing >=14. Neither tells you anything about why you are comparing to 14.
    NO SHIT, SHERLOCK.
    What's that thing they say about irony detectors, again?
  • St. Mary's Hospital for the True Image (unregistered)

    Groaaaaaaaaaaaaaaaaaaaaaaaaaaaaan!

  • bshock (unregistered)

    Honestly, has anyone ever worked on software where all the business rules were known? Everywhere I've ever been, there was never even verbal lore about business rules. Everything had to be inferred.

    The other day I was working on a stored procedure that formed the heart of our product's data storage capability. I noticed dozens -- maybe hundreds -- of lines of SQL that seemed to churn the data around from one temp table to another in no useful way. Just for the fun of it, I went to our data access expert and asked him what all of this was supposed to accomplish.

    "Beats the hell out of me," he answered. "Hey, I didn't write this. But don't take out anything -- there's no way to tell what you might break."

    It's not really a WTF -- more like Business As Usual.

  • Gruesome Grue (unregistered) in reply to vman
    vman:
    APH:
    Am I the only one who caught the Zork reference? Seriously, isn't ANYBODY going to be eaten by a grue?
    Of course not, they're in a sunny meadow. Everyone knows that the grue only eats you if you enter a dark area without a light.
    I think the expression was "It is pitch black."
  • cra99yk0d@r (unregistered) in reply to b0tt0mc0d3rzzz
    b0tt0mc0d3rzzz :
    Tongue in cheek, I hope?

    Are you pointing out the fact that constants should be, um CONSTANT, and variables, should be, um VARIABLE?

  • Gruesome Grue (unregistered) in reply to jared
    jared:
    No, good practice would be defining a constant with value 14 whose name indicates what it means. _GREATER_THAN_OR_EQUAL14 is no different than typing >=14. Neither tells you anything about why you are comparing to 14.
    #define ONE_THIRD_OF_FORTY_TWO 14
  • Gruesome Grue (unregistered) in reply to jared
    jared:
    No, good practice would be defining a constant with value 14 whose name indicates what it means. _GREATER_THAN_OR_EQUAL14 is no different than typing >=14. Neither tells you anything about why you are comparing to 14.
    #define ONE_THIRD_OF_FORTY_TWO 14
  • fuzzylollipop (unregistered)

    the REAL WTF is none of these are marked "final" they can all be changed at runtime! So much for "constants"!

  • benjamin (unregistered)

    If the first 6 months of your project are spent defining constants....

    and your bosses are OK with this....

    then I say "Go For It!".

  • A. Cube (unregistered) in reply to krupa
    I'm calling "Shenanigans" on this one. No one would work with shit like this.

    private _2 whoTheHellKnows = new _2();

    Yeah, right.

    Except, as misguided and insane as this code is, that isn't how _2 would be used. Instead, it would be something like this:

    if (input.Equals(_2._A))
// do stuff

    Stupid? Absolutely. But you would not instantiate _2.

  • Ralph Loizzo (unregistered) in reply to APH

    The reply is "Nothing happens."

  • Jeff (unregistered)

    Wow this really reminds me the code I'm forced to maintain right now (It's a giant WTF). There's this lovely hierarchy of constants stuffed into interfaces, so EVERY class in the codebase implements the interfaces. It looks something like this:

    XMLConstants: 300 constants CRMServerConstants: 100 constants CRMServerXMLConstants(CompanyName): 3000 constants

    They also love to use constants to build sql queryies, so we get these lovely things like:

    String sql = SELECT + STAR + FROM + DBSchema.TABLENAME.COLUMNNAME + WHERE + DBSchema.TABLENAME.COLUMNNAME + EQUALS + FLAG_NO

    it's very readable...

  • Gruesome Grue (unregistered) in reply to TopCod3r
    TopCod3r:
    I am not a Java programmer (although I am sure it would be easy for me), but I have chosen to go into the more lucrative field of Visual Basic, since it is higher demand and has more room for promotion. Anyways...
    You're sitting alone in a peaceful meadow. There is some beautiful flame bait here.
  • (cs) in reply to DaveAronson

    The real WTF is all the totally incorrect code that some of you are throwing about:

    Tom:
    The REAL WTF here is that the author didn't use the constants in defining the other constants. He should have written them like this:

    public static String _GREATER_THAN_OR_EQUAL14 = _GREATER_THAN_OR_EQUAL + "14";

    WRONG! What if the value of 14 changes? It SHOULD be:

    public static String _ONE = "1" public static String _FOUR = "4" public static String _FOURTEEN = _ONE + _FOUR

    public static String _GREATER_THAN_OR_EQUAL + _FOURTEEN

    Even this is only a interim solution. The real way to do it would be to define every PRIME number as a string, and then define every other number as the sum of those primes (casting them back to int, of course)

    public static String _TWO = "2" public static String _THREE = "3" public static String _FIVE = (String)((int)_TWO + (int)FIVE)

    DaveAronson:
    All you really need is the correct indices to get the proper substring out of public static String _PI_COMPLETE.

    And on the same heels, wtf are you doing putting this all in one string? What if some of those numbers change? What if someone doesn't have access to substring?

    public static String _PI_COMPLETE_FIRST_DIGIT = _THREE public static String _PI_COMPLETE_DECIMAL = _DECIMAL public static String _PI_COMPLETE_FIRST_DECIMAL = _ONE public static String _PI_COMPLETE_SECOND_DECIMAL = _FOUR public static String _PI_COMPLETE_THIRD_DECIMAL = _ONE public static String _PI_COMPLETE_FOURTH_DECIMAL = _FIVE

    And so forth. If you really NEED a single _PI_COMPLETE variable, we can accomidate you in the meantime:

    public static Array _PI_COMPLETE _PI_COMPLETE[_ZERO] = _PI_COMPLETE_FIRST_DIGIT _PI_COMPLETE[_ONE] = _PI_COMPLETE_DECIMAL _PI_COMPLETE[_TWO] = _PI_COMPLETE_FIRST_DECIMAL _PI_COMPLETE[_THREE] = _PI_COMPLETE_SECOND_DECIMAL

    And so forth. If you want NEGATIVE PI, well, that will be in a future revision. We can't perfectly rely on the runtime to provide us with truly accurate negative values for pi because of the extra bit. For now just take your value, convert it to a string, and append

    _MATH_SYMBOLS_NEGATIVE_MINUS_SIGN

  • NH (unregistered)

    Personally I have figured out that many "constants" never are and are better off in a database table.

    But excessive constantification of general rules and values is often outright stupid and doesn't improve on the code at all.

    However sometimes I do use the following:

    public final static String CURRENT_USER="CURRENT_USER";

    and then use that when I for example do a session.getAttribute() in a Servlet. This allows me to look for all references to the constant instead of doing a search for the string and maybe end up with a bunch of false matches.

  • (cs) in reply to Bob

    I worked for 2 months at a place where I had to maintain an awful system like the one in this story. The guy who created it had a 5k line class called "ConstantsAndGlobals.java". As soon as I saw that I knew that I was in trouble.

    A constants class in Java really has no place. If you cannot figure out how to create an OO pattern that will allow you to place the necessary constants in the Interface/Abstract class then retire.

  • (cs)

    So beautiful... Can't... open eyes...

  • (cs)

    It looks to me like The Real WTF is that these constants are defining arithmetic operators and numbers as strings. The only way that even remotely makes sense is if this is some kind of code generator and those need to be printed frequently.

    My guess is someone thought a Java String was equivalent to #define in C.

  • t (unregistered) in reply to Someone You Know
    Someone You Know:
    Java's Double class treats -0.0 and 0.0 as different numbers.

    No they are equal but internally are stored differently, this is common with floating point numbers where the sign is stored as a bit.

    (-0.0 == 0.0) results in: true

  • Andrew (unregistered) in reply to Walleye
    Walleye:
    Zap Brannigan:
    A frustrated COBOL programmer acting out?

    It must be. COBOL is the only language that I know of where it's possible to have a negative zero. (And, yes, it does not equal zero!)

    public static String _AUTO_STTS_OIE = "-0";

    The decimal hardware allows negative zero, where COBOL often runs. Ones-complement binary also has the negative zero problem.

    COBOL systems do run on x86 hardware, with software decimal arithmetic. See the IEEE-754 standard, which has a singel zero (as I recall).

  • (cs) in reply to Andrew
    Andrew:
    Walleye:
    Zap Brannigan:
    A frustrated COBOL programmer acting out?

    It must be. COBOL is the only language that I know of where it's possible to have a negative zero. (And, yes, it does not equal zero!)

    public static String _AUTO_STTS_OIE = "-0";

    The decimal hardware allows negative zero, where COBOL often runs. Ones-complement binary also has the negative zero problem.

    COBOL systems do run on x86 hardware, with software decimal arithmetic. See the IEEE-754 standard, which has a singel zero (as I recall).

    It was on a System/390 that I first discovered this. Micro Focus COBOL on x86 hardware also demonstrated the problem. I think that it could probably happen on any system that implements packed-decimal numeric fields.

    It's been a while since I used COBOL, so this is from memory. Define an 8-digit packed-decimal numeric field. Then redefine the storage as two four-digit packed decimal fields. Set the 8-digit field to a negative, with zeroes in the uppper four digits, then set the second of the four-digit fields to zero. The 8-digit field now has the value of -0.

  • EMan (unregistered) in reply to akatherder
    akatherder:
    public static String _GREATER_THAN_OR_EQUAL14 = ">=14";

    This is just good practice. It completely removes the ambiguity of the magic number 14 in your code. _GREATER_THAN_OR_EQUAL14 is much shorter than typing out >=14 EVERY TIME you want to do a comparison to 14. This will also ensure that I don't punch the programmer in the ear when I find out who wrote it.

    You do realize that's a string, right? So it's not being used to compare anything to 14... It's probably included in the app's output.

    If you really wanted to keep from typing the code (not the string) >=14 a lot, you should make a function.

    Last but not least, WTF is up with putting a number in the constant name like that? The constant name should describe the MEANING of the constant, not its contents. Like, what is 14? The number of days in two weeks? One more than a baker's dozen? That code is not even close to good practice.

    I pray to Allah that you are just kidding.

  • Anonymouse (unregistered)

    Your daily grind is over. You're no longer maintaining a huge application that your whole team hates. You're sitting alone in a peaceful meadow. There is a small mailbox here. Your computer is in front of you, and your favorite IDE is loaded up on the screen. You're starting a new project — a project in which you will guide the overall design. Your business rules are well-defined and you know them like the back of your hand.

    open mailbox

    Opening the mailbox reveals a leaflet.

    read leaflet

    This leaflet contains the most recent MFD update. Your eyes immediately melt, followed by the skin on your face. It's not like you were using those, anyway.

    Your score is 0 (total of 350 points), in 2 moves. This gives you the rank of WTF.

  • Dave (unregistered)

    Hey, at least that bug would only have to be fixed in one place ;)

  • methinks (unregistered) in reply to cra99yk0d@r
    cra99yk0d@r:
    b0tt0mc0d3rzzz :
    Tongue in cheek, I hope?

    Are you pointing out the fact that constants should be, um CONSTANT, and variables, should be, um VARIABLE?

    As they say:

    Variables don't.

    Constants aren't.

    :o)

  • (cs) in reply to t
    t:
    Someone You Know:
    Java's Double class treats -0.0 and 0.0 as different numbers.
    ...

    (-0.0 == 0.0) results in: true

    True, but that is not what I said. The primitive double values -0.0 and 0.0 are equal. However, the equals method on the Double wrapper class treats Double objects created with those values as being different. For example, if you have:

    Double neg = new Double(-0.0); Double pos = new Double(0.0);

    Then neg.equals(pos) == false. Try it.

  • methinks (unregistered) in reply to brazzy
    brazzy:
    (...) actaully a "constants interface", a practice considered a WTF in itself by some (...)

    No, not in itself. Using an interface (or an abstract class) for constant definitions is much better than a concrete class (like in today's WTF), at least in the absence of enumerated types.

    The problem with such interfaces are dumb people who implement these interfaces in classes where they intend to use the constants, only to save themselves typing the interface's name to qualify those constants, thus completely defeating the purpose of the interface concept.

    This is the reason for the new and shiny (and also completely redundant) "static import" feature in Java 5+. Dumb developers are the reason for dumb language additions, most obviously ;o)

  • Kate Ebneter (unregistered)

    The twisted, masochistic part of my brain would love to see the whole file for some reason.

    ...I must be sick.

  • (cs) in reply to APH
    APH:
    Am I the only one who caught the Zork reference? Seriously, isn't ANYBODY going to be eaten by a grue?

    If that source code was in the mailbox, I would have offed myself with the Troll's axe.

  • (cs)
    You're starting a new project — a project in which you will guide the overall design. Your business rules are well-defined and you know them like the back of your hand.

    You create your database and set up the rest of the initial configuration. You're ready to write your first code file.

    Nice fantasy, but I would actually create some documentation for the design before writing that code file. This will help if another programmer joins the project later and/or becomes its maintainer.

  • LEGO (unregistered) in reply to JUST ANOTHER WTF
    JUST ANOTHER WTF:
    gabba:
    public static String _AK = "AB";

    This is not a bug -- actually, it demonstrates the power of the technique. Obviously, new application needs have necessitated redefining the string "AK" to "AB". This way it only has to be changed at one place. Duh.

    Actually I just think it means that whoever they were trying to mail stuff to moved from Arkansa to Alberta. So not a WTF

    WTF? Arkansas == AR.

    Alaska == AK.

    _AK = AB

    Obviously Alberta has been annexed by Alaska. Hey wait, I can see Russia from my house...

    -Lego.

  • methinks (unregistered) in reply to Someone You Know
    Someone You Know:
    t:
    Someone You Know:
    Java's Double class treats -0.0 and 0.0 as different numbers.
    ...

    (-0.0 == 0.0) results in: true

    True, but that is not what I said. The primitive double values -0.0 and 0.0 are equal. However, the equals method on the Double wrapper class treats Double objects created with those values as being different. For example, if you have:

    Double neg = new Double(-0.0); Double pos = new Double(0.0);

    Then neg.equals(pos) == false. Try it.

    Not without reason - if you'd have read the relevant API docs, you would not have been surprised by this ;o)

    Snip from java.lang.Double#equals' API doc:

    "(...) Note that in most cases, for two instances of class Double, d1 and d2, the value of d1.equals(d2) is true if and only if

    d1.doubleValue() == d2.doubleValue()

    also has the value true. However, there are two exceptions:

    • If d1 and d2 both represent Double.NaN, then the equals method returns true, even though Double.NaN==Double.NaN has the value false.

    • If d1 represents +0.0 while d2 represents -0.0, or vice versa, the equal test has the value false, even though +0.0==-0.0 has the value true.

    This definition allows hash tables to operate properly."

  • some coder (unregistered)

    I used to come here for the articles... these days though I come here for topCod3r's awesome trolls.

    (Seriously, google his replies)

    Can I flag him as 'friend' somehow and insta-mod his posts to blue status a la slashdot?

  • Boogaloo (unregistered) in reply to JUST ANOTHER WTF

    Yet another product of the American education system.

  • Peter-Frank Spierenburg (unregistered) in reply to TopCod3r

    Wait a minute! Sales tax is a constant? In what economic universe?

    And who would store pi in a database? I mean, unless it was strawberry...

  • Peter-Frank Spierenburg (unregistered) in reply to Gruesome Grue

    Really, that should be:

    #define ONE_THIRD_OF_THE_MEANING_OF_LIFE 14

  • (cs) in reply to methinks
    methinks:
    Note that in most cases, for two instances of class Double, d1 and d2, the value of d1.equals(d2) is true if and only if

    d1.doubleValue() == d2.doubleValue()

    also has the value true. However, there are two exceptions:

    • If d1 and d2 both represent Double.NaN, then the equals method returns true, even though Double.NaN==Double.NaN has the value false.

    • If d1 represents +0.0 while d2 represents -0.0, or vice versa, the equal test has the value false, even though +0.0==-0.0 has the value true.

    This definition allows hash tables to operate properly."

    I have this plan: when I finally get around to dropping acid, I'm going to make sure I have a handy copy of the Java API docs (and whichever version of the "standards" applies at that particular moment) by my side. If I'm going to expand my mind, I really want to expand my mind.

    I don't even understand the point of the first exception, although I'm sure I would if I avoided the brown stuff.

    The second exception is, however, bizarre. Does this mean that the standard Java hash table uses floating point values to represent keys? Or is there some even more mind-boggling reason for this completely counter-intuitive behaviour?

    Implementing a sensible algorithm allows hash tables to operate properly.

    Java.equals(_WTF);

  • (cs) in reply to methinks
    methinks:
    Someone You Know:
    t:
    Someone You Know:
    Java's Double class treats -0.0 and 0.0 as different numbers.
    ...

    (-0.0 == 0.0) results in: true

    True, but that is not what I said. The primitive double values -0.0 and 0.0 are equal. However, the equals method on the Double wrapper class treats Double objects created with those values as being different. For example, if you have:

    Double neg = new Double(-0.0); Double pos = new Double(0.0);

    Then neg.equals(pos) == false. Try it.

    Not without reason - if you'd have read the relevant API docs, you would not have been surprised by this ;o)

    Well, I wasn't actually surprised by it; I was responding (in a quote that seems to have gotten lost somewhere) to someone who claimed that COBOL was the only language that treated -0 and 0 differently.

    And I agree (with someone else I can't be bothered to quote just now because I'm in a hurry) that Java can be trippy. Wrapper classes for primitive data types have long been a gold mine for WTFs.

  • TJ (unregistered) in reply to APH

    its pitch black. you are likely to be eaten by a grue.

  • I walked the dinosaur (unregistered)

    I think TopCod3r's awesome VB skills allow him to make OVER 9000 dollars a year!

  • (cs) in reply to EMan
    EMan:
    akatherder:
    public static String _GREATER_THAN_OR_EQUAL14 = ">=14";

    This is just good practice. It completely removes the ambiguity of the magic number 14 in your code. _GREATER_THAN_OR_EQUAL14 is much shorter than typing out >=14 EVERY TIME you want to do a comparison to 14. This will also ensure that I don't punch the programmer in the ear when I find out who wrote it.

    You do realize that's a string, right? So it's not being used to compare anything to 14... It's probably included in the app's output.

    If you really wanted to keep from typing the code (not the string) >=14 a lot, you should make a function.

    Last but not least, WTF is up with putting a number in the constant name like that? The constant name should describe the MEANING of the constant, not its contents. Like, what is 14? The number of days in two weeks? One more than a baker's dozen? That code is not even close to good practice.

    I pray to Allah that you are just kidding.

    This is an agile technique to streamline the look-up of constants. When I'm looking at code, what good is a variable named $number_of_otters_in_my_pants? It doesn't tell me how many otters are in my pants. I have to count them or go look up the value of this constant. Just put "7" in the code. If one of the otters leaves, all I have to do is a search and replace "7" to "6".

  • (cs)
    • Closes eyes for a moment and turns text-to-speech on *
        tdwtf-csod-constantly-expanding.mp3

    Taste mild, 09:19 in length. Best served warm with a generous helping of WTF.

  • (cs) in reply to some coder
    some coder:
    I used to come here for the articles... these days though I come here for topCod3r's awesome trolls.

    (Seriously, google his replies)

    Can I flag him as 'friend' somehow and insta-mod his posts to blue status a la slashdot?

    I agree completely. However, I wouldn’t classify TopCod3r as trolling. TopCod3r’s clever, sarcastic comments truly add to the fun here. It’s even more fun when you don’t realize at first who posted it – and thus miss the tongue planted firmly in the cheek.

  • (cs) in reply to akatherder
    akatherder:
    This is an agile technique to streamline the look-up of constants. When I'm looking at code, what good is a variable named $number_of_otters_in_my_pants? It doesn't tell me how many otters are in my pants. I have to count them or go look up the value of this constant. Just put "7" in the code. If one of the otters leaves, all I have to do is a search and replace "7" to "6".
    If you have to deal with $number_of_otters_in_my_pants on a day-to-day basis, I'd say you've got worse problems than whether or not to alias a constant. You definitely need to revisit the business requirements.

    Oh ... and get somebody to explain the Use Case Scenarios for you who isn't doing five to ten for Animal Husbandry.

  • Player One (unregistered) in reply to Gruesome Grue
    Gruesome Grue:
    TopCod3r:
    I am not a Java programmer (although I am sure it would be easy for me), but I have chosen to go into the more lucrative field of Visual Basic, since it is higher demand and has more room for promotion. Anyways...
    You're sitting alone in a peaceful meadow. There is some beautiful flame bait here.
    Pick it up
  • (cs) in reply to APH
    APH:
    Am I the only one who caught the Zork reference? Seriously, isn't ANYBODY going to be eaten by a grue?

    No, you're just the only one who thought it was obscure enough to merit a "am I the only one who caught it" post?

    Not knowing that reference would be like not knowing where the term "Good Samaritan" comes from.

  • Mike D. (unregistered) in reply to methinks
    methinks:
    Not without reason - if you'd have read the relevant API docs, you would not have been surprised by this ;o)
    I think I am not alone in saying that math functions not working in expected ways can be called "surprising" and "bad" (maybe even "WTF"), documentation notwithstanding.

    If a class is supposed to act like a primitive, then it should always act like that primitive. "We felt that making == a bitwise operation even though there's a perfectly workable builtin because we don't know better" is just sloppy.

    Zero should frakking equal zero. To do otherwise is a bug. The only place I ever want to see "-0" used in all seriousness is in a limit term, e.g. lim as x -> -0 of 1/x = -inf.

  • Jesus (unregistered)

    Ima call bullshit on this one..

Leave a comment on “Constantly Expanding”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article