• (disco)

    I actually had this in my code:

    Set(OPEN_CURLY_BRACE={);
    Set(CLOSED_CURLY_BRACE=});
    Set(DOLLAR_SIGN=$);
    

    And a few more. Used to get around AEL parser's stupidity.

    Found a convoluted syntax that made it obsolete though.


    Filed under: Fucking Discourse and it's posting shortcuts

  • (disco) in reply to Onyx

    What if your code gets converted to RTL?

  • (disco)

    I couldn't believe how long it took to scroll to the bottom. I think I reached "that is a hilarious amount of constants" about a quarter of the way through and they just kept coming.

  • (disco) in reply to garaden

    It's not just a load of constants. It's a shitload of constants!

    And all in one file too. I bet the developer uses those constants by making everything inherit from implement that interface too, so now there's a gigantic coupling god class too. Because every class needs to know the secret key… That's still cracking me up, hours after reading it. When I find something that low wattage, I use it on my Christmas tree instead of normal fairy lights to reduce power consumption.

  • (disco)

    Ok, how many of you hit CTRL+F and typed "password" in when seeing this giant list of constants?

  • (disco)

    It's a good thing they made the constructor private. Wouldn't want someone instantiating the class and wasting memory.

  • (disco) in reply to chubertdev
    chubertdev:
    WHY DOES NO DEVELOPER KNOW HOW TO SPELL THIS!?!?!?!!?

    public static final String E = " E ";

    shouldn't that be SPACE_E_SPACE?

    That one is oddly specific. I'm not sure where you would ever use it.
  • (disco) in reply to xaade

    It's an interesting structure, created by IBM. SQL is bracketed in the COBOL source by "EXEC SQL" and "END-EXEC" block markers. Those are extracted and processed by an SQL preprocessor, and replaced by data blocks and calls to external processors. The resulting effect is that the SQL statement is executed inline with the code, just the way it's written.

    It's much more convenient then a lot of the code nowadays, which tends to have separate code and SQL implementations.

    Sorry I broke your mind.

  • (disco) in reply to CoyneTheDup

    If only they could create a better....link....between the two.

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    It's much more convenient then a lot of the code nowadays, which tends to have separate code and SQL implementations.

    I think you'll find that some languages do that sort of thing even now. It's just a matter of whether the language can simply embed another language syntax.

  • (disco)

    This is just incompetence, not mendacity. The seventh circle of the inferno is reserved for developers who arrive at this code, and decree that all these constant strings are a "dependency" and therefore have to be injected one at a time into every class via 30+-argument constructors.

  • (disco)

    public static final String FRIST = "FRIST!";

  • (disco) in reply to akatechis

    Pure constants like this are inlined into the target class so you don't even have to ship that class, which would make it very hard to instantiate ;-)

  • (disco) in reply to BernieTheBernie
    BernieTheBernie:
    public static final String FRIST = "**83rd**!";
    FTFY.

    Now that's the second time a "frist" post appears with great delay in this thread; I wonder why?

  • (disco) in reply to Julia

    I assumed it was malicious compliance with a "No Magic Constants" rule.

  • (disco) in reply to BernieTheBernie
    BernieTheBernie:
    public static final String **FIRST** = "FRIST!";

    FTFY

  • (disco)

    Yeah, I recall one compiler of yore, where the machine had 6-bit characters and 60-bit words. They guy that wrote the local FORTRAN compiler defined a constant:

    BCDBIT EQU 6

    ... for the number of bits in a character. Now realize that there was no imaginable way of changing this and having the compiler run on a different character set, since in most cases it was used to shift and mask characters in 60-bit words. Thousands of uses of it, and all instances basically useless for anything other than giving you the idea "oh, they're looking for a 4-character operator, maybe like ".OR.".

  • (disco) in reply to CoyneTheDup

    It makes sense. That's the syntax idea of linq. However, linq builds statements by resolving enumerables instead of resolving by preprocessor.

  • (disco)

    hoooboy. This was written by a fortran programmer.

    The 9999 error code gives that away. Fortran programmers use 9999 in a return value to indicate that there was a problem. If your problem was that the answer really was 9999, well, now you have two problems.

    public static final String JAVA_EXCEPTION_CODE = "9999";

  • (disco)

    The goggles, they do nothing!

    ...

    Maybe this is just a masterful obfuscation strategy?

  • (disco) in reply to coyo

    Pedantic Dickweedery Alert:

    coyo:
    If your problem was that the answer really was 9999, well, now you have two problems[ a semi-predicate problem][1].

    FTFY

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    SQL is bracketed in the…

    In C++ (requires C99 variadic macros, fortunately even MSVC++ 7+, though otherwise not supporting C99, has them) I quite SQL using this definition:

    #define SQL(...) #__VA_ARGS__
    

    It mangles whitespace outside quotes (but it is not significant in SQL), requires matched parenthesis (but so does SQL) and clang complains about weird tokens when using empty strings (''; well, it's just a warning; it can be turned off). This form does not expand macros in the SQL, but this one does:

    #define SQLX(...) SQL(__VA_ARGS__)
    

    and now you can even use symbolic constants (though only those #defined and not enums and const whatevers) in your SQL.

    Given that the code processing the result of the query is closely tied to the query, having the query anywhere else than right at the beginning of that code makes absolutely no sense and this is an easy way to have a nice long properly indented string literal.

  • (disco) in reply to John_Imrie
    John_Imrie:
    public static final String secretKey = "mE3BrW5B";

    Not so secret any more

    We had something similar in an inherited mortgage LOB app once, an external audit flagged it up, the client didn't want to pay to fix it properly, so it was just renamed

    public const string thisIsNotTheKeyYouAreLookingFor
    

    The auditors got the joke, the client never prioritised it and it was never heard of again (the client collapsed in quite spectacular fashion)

  • (disco)

    I just don't see the WTF in the article. Things like this are quite common. You don't expect people to create strings when they need it. Reusing strings is the way to go.

    Can someone explalin the WTF here is ?

  • (disco) in reply to minuSeven
    minuSeven:
    I just don't see the WTF in the article. Things like this are quite common. You don't expect people to create strings when they need it. Reusing strings is the way to go.

    Can someone explalin the WTF here is ?

    You.

  • (disco) in reply to chubertdev

    The front page trolls are starting to show up. There goes the neighborhood.

  • (disco) in reply to antiquarian

    Hey, I'm a front page troll!

  • (disco) in reply to chubertdev

    You wish. Actually, it's @minuSeven.

  • (disco) in reply to chubertdev

    Care to mention a bit more and help out an ignorant guy

  • (disco) in reply to minuSeven

    Because you obviously need constants like A_TEXT whose content is A, because you're obviously going to reuse that everywhere and you might suddenly redefine A_TEXT to mean something that isn't A.

    public static final String A_TEXT = "A";
    

    Or B, C, D, E, F, G, I, M, P, R, S or T.

    Or you might decide that you need to handle different kinds of case in different fashions:

    public static final String CHECKED = "checked";  
    public static final String UNCHECKED = "unchecked";  
    public static final String UNCHECKED_C = "UNCHECKED";  
    public static final String CHECKED_C = "CHECKED";  
    

    Because you might also redefine what checked means, of course.

  • (disco) in reply to minuSeven

    No thanks.

  • (disco)

    I think I wrote something like this about 20+ years ago as a junior programmer, but there was reason behind the madness that most people won't know about.

    Big corporate engineering company I worked for decided the old Fortran app we used for structural analysis had to go. Selected a replacement app written in C (with some core parts written by F2C). 16-bit app running on MSDOS, that we were going to use as a base for a 32-bit OS2 app (but ended up 16-bit on Windows in those pre-NT days).

    Soon as we started to extend the app,we ran into a compilation failure; Borland C back in those 16-bit days used to stick all string literals (and a bunch of other resources) in a single 16-bit Data segment in the .EXE. One we exceeded that, it just would not compile. We did a couple of things to reduce size, but one quick and dirty solution was to move all string literals into C consts.

    I remember it, as it was my first introduction straight out of university, to using Awk and Regex as tools. I extracted all strings out of the large C code base and wrote a largely machine generated header file. Looked like something like the one in the article, (at least from what I recall many years later, though mainly longer descriptive strings like 'press any key to continue'). Any change to that file caused a rebuild of every C file that included it, so I remember updating it at night, then recompiling it which would take about 20+ minutes on my flash new 386DX33... All worked, so I then got the job of moving everything to resource files and supporting i18n with the windows version.

    Of course this WTF is in Java, and if hand written sometime this century.... well, yeah, WTF.

  • (disco) in reply to Arantor
    Arantor:

    Because you might also redefine what checked means, of course.

    Actually in HTML...you could do checked="unchecked" and it would be the same as just checked.

  • (disco) in reply to delfinom

    That depends on whether it's HTML or XHTML since checked="unchecked" certainly used to have interestingly unpredictable effects if the browser was actually being strict.

Leave a comment on “The Constant Bomb”

Log In or post as a guest

Replying to comment #:

« Return to Article