• (disco)

    I kinda like being on the before-everyone-else-gets-it train.... But also a little guilty for those not in the know? TBH I probably would have expected an IF...ELSEIF...END cascade. :fa_thumbs_down: for originality?

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    little guilty for those not in the know

    Nah, this is not exactly secret. If people aren't in the know, it's pretty much their own fault.

    As for the article, itself, there are two explanations, either or some combination of both of which may be involved: 1. Incompetent people are incompetent. 2. Even competent people occasionally write dumb code.

    Filed under: Of course, these explanations apply to most code snippets we see here.
  • (disco)
    Well Jan L. came across this solution to a simple boundary check- if telegramType is between 100 and 199, it is a payment type telegram. 
    boolean isPaymentType = false;
for (int i = 100; i < 199; i++) {
    if (telegramType == i) {
        isPaymentType = true;
    }
}

    If it looks stupid but it works it’s… no, it’s still stupid.

    If by working that means "not matching the spec" then ok....

    That loop only returns true for [100,199), the sentence prior before can only be interpreted as either [100,199] (more likely the intention,) or (100,199).

    This is totally the sort of thing you write at 3AM after a hard night of drinking

    The code or the article? :cheapshot: :laughing:

    <!-- [pjh@thinkpad tmp]$ cat foo.c #include <stdio.h> int foo(int telegramType){ int isPaymentType = 0; int i; for (i = 100; i < 199; i++) { if (telegramType == i) { isPaymentType = 1; } } return isPaymentType; } int main(void){ int tests[] = {0, 99, 100, 101, 198, 199, 200, -1}; int i=0; while (tests[i]>=0){ printf("%d = %d\n", tests[i], foo(tests[i])); ++i; } return 0; } [pjh@thinkpad tmp]$ ./foo 0 = 0 99 = 0 100 = 1 101 = 1 198 = 1 199 = 0 200 = 0 [pjh@thinkpad tmp]$ -->
  • (disco)

    I'm not sure I see the WTF in the '<scr'+ 'ipt' one. Isn't it standard practice when you need to write a script from inside a <script> tag, because otherwise the HTML parser screws you over?

    Of course, dynamically linking to a script from client side might be TRWTF.

    Edit: I've broken Discourse! Corrected by replacing angular brackets with HTML enbreasties.

  • (disco) 
    document.write('<sc'+'ript language="javascript" type="text/javascript" src="' + url + '"></sc'+'ript>');

I can only assume that someone in their organization banned the use of the word “script” inside of a script.

    Actually, this is a well known problem in the html spec reference here

  • (disco)
    We pick on date handling code a lot here, simply because there are so many ways to mess up date related code...

    Most of which seem to be easily fixed by using a suitable library.

    document.write('<sc'+'ript language="javascript" type="text/javascript" src="' + url + '"></sc'+'ript>');
    Sergio_Bastos:
    Actually, this is a well known problem in the html spec...

    Alas, Hanzo'd by 17 minutes.

  • (disco)

    This topic is now listed. It will be displayed in topic lists.

  • (disco)

    On the last one, I'm afraid you're TRWTF for not understanding the problem.

  • (disco) in reply to PJH
    PJH:
    This topic is now listed. It will be displayed in topic lists.

    .... PAULA!

    slacking off on the job again is she....\

    why i aughta make a version of SockBot to take her job from her and work a bilionty times better!

  • (disco)

    First off the bat...

    boolean isPaymentType = false;
for (int i = 100; i < 199; i++) {
    if (telegramType == i) {
        isPaymentType = true;
    }
}

    I don't know what everyone is smoking, but this works (and works and works and works) for 100 through 198. 199 is feeling left out...

    Addendum

    You know what? Not only that, but this just doesn't feel....enterprisey enough. He needs to create an array and put his list of valid values in the array, then do foreach on the array elements. That way, it can be wrong in the enterprisey way.

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    I don't know what everyone is smoking, but this works (and works and works and works) for 100 through 198. 199 is feeling left out...

    It does have the dubious advantage of taking virtually the same amount of time whether the test succeeds or fails. [spoiler]And proving that the creator of the code is a nincompoop.[/spoiler]

    CoyneTheDup:
    He needs to create an array and put his list of valid values in the array, then do foreach on the array elements.

    Perhaps he should also fetch the valid values from a database?

  • (disco) in reply to CoyneTheDup

    This isn't enterprisey enough either.

    (Please imagine the following code correctly indented and without line breaks, didn't find a way to copy and paste and don't have a keystroke simulator handy)

    boolean isPaymentType;
if (telegramType == 100) {
  isPaymentType = true;
} elseif (telegramType == 101) {
  isPaymentType = true;
} elseif (telegramType == 102) {
  isPaymentType = true;
} elseif (telegramType == 101) {
  isPaymentType = true;
/* omitted 195 lines of code - no, the 101 is no typo, it's part of the enterpriseyness */
} elseif (telegramType == 198) {
  isPaymentType = true;
} elseif (telegramType > 200) {
  isPaymentType = false;
};

    Or we could make use of a nested loop, for nested loops are cool

  • (disco)

    Sorry.. no sorry this has to be the biggest WTF piece of code.. ever..

    boolean isPaymentType = false;
for (int i = 100; i < 199; i++) {
    if (telegramType == i) {
        isPaymentType = true;
    }
}

    You have to WANT IT to be that way to come up with this.. its like intentionally put the key in the safe to be sure not to lose it.

    It hurts my brain just to find an excuse for the poor f*ck..

  • (disco) in reply to CoyneTheDup

    No it doesnt work, Coyne. It would work only if the telegramtype is 198. Otherwise, it'll always be false.

  • (disco) in reply to dkf
    dkf:
    fetch the valid values from a database

    Now that's the TRUE enterprise spirit!

    It's the easiest way to enable the user to extend the range by adding a few records to the database. Via a copied and custom-made web interface. No need to worry about SQL injection, of course.

  • (disco) in reply to dkf
    dkf:
    Perhaps he should also fetch the valid values from a database?

    Yes, but they should be stored as strings, complete with handrolled integer to string conversions

  • (disco) in reply to PWolff
    PWolff:
    No need to worry about SQL injection, of course.

    Why would we? Nobody will try to do that? i mean.. right?

  • (disco) in reply to Mario_Levesque
    Mario_Levesque:
    It would work only if the telegramtype is 198. Otherwise, it'll always be false.

    The assignment to false is done before the loop only.

    But you're right in that putting that into the loop would be even more enterprisey. Best like

    if (telegramType == i) {
    isPaymentType = (telegramType == i);
} else {
    isPaymentType = (telegramType == i);
};
  • (disco)

    I came across an if statement a while ago which tested 

    if ( $condition || ! $condition )

  • (disco) in reply to FullPointerException
    FullPointerException:
    complete with handrolled integerfloat to string conversions

    This way it's way more extendable.

  • (disco) in reply to PWolff

    Spot on.. my bad on the false thingy.. but your solution is more elegant.. enterprisey wise.. :smile:

  • (disco) in reply to CarrieVS

    if ( $condition || ! $condition )

    To be or not to be. That is the condition..

  • (disco) in reply to CarrieVS

    As opposed to:

    if ( $condition || $condition || $condition )

    ?

  • (disco) in reply to PWolff
    PWolff:
    This way it's way more extendable.

    Actually, why not roll our own Number class, that way we aren't limited by the precision or ranges of built in types?

  • (disco) in reply to FullPointerException
    FullPointerException:
    why not roll our own Number class

    Done that. It's a lot of work to do right.

  • (disco) in reply to dkf

    At least the actual if statement isn't totally redundant there, only two of the conditions.

  • (disco) in reply to dkf

    In all seriousness, I completely agree.

    Although in the concept of making things as wtf-y as possible, I think it's 100% necessary to do. Like that time my manager wanted me to write my own list implementation, just in case there was a bug in std::list.

  • (disco) in reply to FullPointerException

    That's easy:

    // Because of stupid boss
class MyList : public std::list<MyObject>{};
  • (disco) in reply to Mario_Levesque

    Boring, everyone goes for the Hamlet conditional. Inspired by:

    dkf:
    if ( $condition || $condition || $condition )

    Let's try Macbeth instead!

    boolean condition = Date.daysBetween(Date.now(), targetDate) == 1; // tomorrow?
if (condition && condition && condition) {
    while (true) {
        // To the last syllable of recorded time
    }
}
  • (disco) in reply to Mario_Levesque

    we can speed up the loop with a clever:

    telegramType = telegramType | telegramType == i;

    Still.....

  • (disco) in reply to george_gonzalez
    george_gonzalez:
    isPaymentType = isPaymentType | telegramType == i;

    FTFY…

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    TBH I probably would have expected an IF...ELSEIF...END cascade. for originality?

    I wonder if, in the world of failed "4th and 5th generation programming languages", there is one that might have generated that code. Having seen the dumb queries that Access generates, nothing would surprise me.

  • (disco) in reply to dkf

    Or, for brevity and/or obscurity isPaymentType |= telegramType == i if your language supports it?

  • (disco) in reply to dkf
    dkf:
    Perhaps he should also fetch the valid values from a database?

    create table telegramtype { smallint id NOT NULL PRIMARY KEY, nvarchar(254) id_description NOT NULL, boolean is_telegramtype DEFAULT false, creationdate datetime DEFAULT CURRENT_TIMESTAMP } INSERT INTO telegramtype(id,id_description,is_telegramtype)VALUES(100, 'some significance',true); INSERT INTO telegramtype(id, id_description, is_telegramtype)VALUES(101,'a different significance',true); /code omitted/ .....("SELECT is_telegramtype FROM telegramtype WHERE id = ?",id);

    This is properly enterprisy because it is necessary to test for null as well as false. I am sure a decent system architect could get the telegramtype table up to a lot more fields. How about a modification date and the creator username?

    All added value....

  • (disco) in reply to kupfernigk

    Not necessarily more fields, but a proper "audit trail" table might do the trick

  • (disco)
    boolean isPaymentType = false; for (int i = 100; i < 199; i++) { if (telegramType == i) { isPaymentType = true; } }

    Well, you know, this also checks that telegramType is an integer in the range. Just checking for >= 100 and <=199 would also include values like 123.5. And we can't be having that.

  • (disco) in reply to Vault_Dweller
    Vault_Dweller:
    Not necessarily more fields, but a proper "audit trail" table might do the trick

    Yes, I wasn't thinking Enterprise enough. Also we should log all queries on the table to check for invalid telegramtypes that might need to be added later.

  • (disco)

    Okay, please correct me if I'm wrong. I'm only a moderate programmer, but I learn quickly. I've been hounding my international team for constantly writing:

    if (conditional == true) { // do true stuff }

    Seriously, if it's true, just leave it as the conditional!

    if (conditional) { // do true stuff }

    I would hope the compiler optimizes that out, but it just looks weird to me.

  • (disco) in reply to kupfernigk

    Not enough XML fields in that table...

  • (disco) 
    document.write('<sc'+'ript language="javascript" type="text/javascript" src="' + url + '"></sc'+'ript>');

    There are actually good reasons for this insanity! It all has to do with how browsers parse and interpret the JS. Mostly IE's fault, really...

    Suppose you're writing a 3rd party script for pages, a tracking pixel

    <script>document.write...

    document.write makes sure your next script is injected immediately after current script -- instead of parsing the rest of HTML beforehand (synchronous JS import). It's a bad idea to use this since it will make the page load slower, but there it is.

    Since it's a tracking pixel, you don't want it firing unless the user is actually looking at the page. If you leave the string unbroken, '<script src="...' -- the browser's prefetcher will download the script before your inline script is executed!

    ...so you curse your job for making you create a tracking pixel, and do what hundreds of devs had done before....

  • (disco) in reply to Dragnslcr

    Am I the only one to see what's wrong?

    boolean isPaymentType = false;
for (int i = 100; i < 199; i++) {
    if (telegramType == i) {
        isPaymentType = true;
        break;
    }
}

    FTFY.

  • (disco) in reply to Mikerad1979
    Mikerad1979:
    Not enough XML fields in that table

    Also I missed out a suitably weird collation and a table descriptor.I'm just not trying, am I?

  • (disco) in reply to DJSpudplucker
    DJSpudplucker:
    FTFY.

    But now it won't run in more or less constant time, which may be a desired feature.

  • (disco) in reply to PJH
    Well Jan L. came across this solution to a simple boundary check- if telegramType is between 100 and 199, it is a payment type telegram. 
    boolean isPaymentType = false;
for (int i = 100; i < 199; i++) {
    if (telegramType == i) {
        isPaymentType = true;
    }
}

    If it looks stupid but it works it’s… no, it’s still stupid.

    I can imagine having to do it this way if telegramType is a class that implements operator== but not operator< or operator>, but even so it would be easier to fix this (possibly imagined by me) class instead.

    <!-- sorry for replying to your post, @pjh, you just happened to be the first to quote the code in question. -->
  • (disco) in reply to PWolff
    PWolff:
    /* omitted 195 lines of code - no, the 101 is no typo, it's part of the enterpriseyness */

    But you need to list them all! Otherwise how do you show that you missed 142?

  • (disco)

    It's possible (thought pretty bloody unlikely) that telegramType is an instance of some sort of custom class that defines an equality test with integers, but isn't sortable. I could see it being done for some kind of enumeration class for which greater-than and less-than operators don't make sense. Of course, if that's what this is TRWTF is why such an oddball class doesn't have its own methods for figuring out if it's a payment type.

  • (disco) in reply to machtyn
    machtyn:
    Okay, please correct me if I'm wrong. I'm only a moderate programmer, but I learn quickly. I've been hounding my international team for constantly writing:

    if (conditional == true) { // do true stuff }

    Seriously, if it's true, just leave it as the conditional!

    if (conditional) { // do true stuff }

    I would hope the compiler optimizes that out, but it just looks weird to me.

    A lot of languages will implicitly convert any expression to a boolean, so "if (condition)" will evaluate as true if condition is a non-zero integer, a non-empty string, etc. That's usually what you want, but maybe you actually want to know if the conditional is actually a boolean with the value true and you want it return false for any normally truthy value that's not strictly boolean true. If that's the case though, you probably ought to be explicit about it. "if (type(conditional) == boolean && conditional == true) {...}"

  • (disco) in reply to kupfernigk
    kupfernigk:
    DJSpudplucker:
    FTFY.

    But now it won't run in more or less constant time, which may be a desired feature.

    Oh dear, you're right! There must be some way to improve it?

  • (disco) in reply to kupfernigk
    Mario_Levesque:
    No it doesnt work, Coyne. It would work only if the telegramtype is 198. Otherwise, it'll always be false.

    No, it only changes isPaymenType if it finds a match. So it will work for any of the 99 values of i...it's just that the values of i that are tested only go from 100 to 198.

    PWolff:
    But you're right in that putting that into the loop would be even more enterprisey. Best like

    if (telegramType == i) { isPaymentType = (telegramType == i); } else { isPaymentType = (telegramType == i); };

    I think that makes it worse...if that were possible....

    CarrieVS:
    I came across an if statement a while ago which tested

    if ( $condition || ! $condition )

    Well, of course they tested it that way. Must account for FILE_NOT_FOUND.

    kupfernigk:
    create table telegramtype ... etc.

    This is properly enterprisy because it is necessary to test for null as well as false. I am sure a decent system architect could get the telegramtype table up to a lot more fields. How about a modification date and the creator username?

    All added value....

    You're right...that's the way it really should be done. That's the true enterprisey.

  • (disco)

    //document.write('<sc'+'ript language="javascript" type="text/javascript" src="' + url + '"></sc'+'ript>');

    This isn't really a WTF. If you look at the horrors of SGML, CDATA, Text Nodes, XHTML, HTML and browsers especially historically, then there are good reasons to do something like the above.

    That workaround used to be extremely common but I believe now people create and insert proper DOM elements more often.

    That might even be my code. I did the same before myself as a quick fix when something broke on a dodgy as hell website I inherited.

    If I vaguely remember, the copy pasta from GOOGLE for analytics and other various providers would work this way.

    Even today on Google's guide you'll see...

    https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingOverview

    They use something a little different but basically the same.

    Most today will now use a little minified piece of a pure DOM implementation and with support for nice things like //urls for inheriting protocols, etc. Between five to ten years ago, we didn't have such nice things.

Leave a comment on “If You Want To”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article