This makes me seriously doubt the mental capabilities of an ex-collegue...



  • if DbForm.ControleNames.Locate('NAAM_CONTR', UpperCase(monster_ID), [loCaseInsensitive]) then begin (...)



  • A little explanation might be in order:

    • ControleNames is both Dutch and English
    • Locate performs some select function in an ADO dataset, so naturally loCaseInsensitive makes it case insensitive
    • NAAM_CONTR is Dutch, abbreviated and in upper case (I HATE UPPER CASE!)
    • monster_ID is Dutch and ID is not an acronym but an abbreviation and should be cased Id, so it should have been SampleId
    • and, well... UpperCase(...) in a case insensitive search, well, that just makes me wonder...


  • If a bit of silly redundancy and crazy naming conventions are the worst you have to put up with, you're lucky.



  • @Gabelstaplerfahrer said:

    A little explanation might be in order:

    • ControleNames is both Dutch and English
    • Locate performs some select function in an ADO dataset, so naturally loCaseInsensitive makes it case insensitive
    • NAAM_CONTR is Dutch, abbreviated and in upper case (I HATE UPPER CASE!)
    • monster_ID is Dutch and ID is not an acronym but an abbreviation and should be cased Id, so it should have been SampleId
    • and, well... UpperCase(...) in a case insensitive search, well, that just makes me wonder...

     I hate to say this, but these seem a little nit picky to be honest.

    ControleNames still makes some sense (unless Controle.ToEnglish != "Control", then it's a bit messy I'll agree).

    Hatred of UPPER CASE isn't a WTF, though if it is an abbreviation and not an acronym, I'll agree it's annoying as hell.

    I actually prefer ID over Id because that's how I see it most often on signs and websites and such.

    As for the UpperCase in a case insensitive search, congratulations! We have found our (tiny) WTF. Just shake your head and move on.

     

    I'm going to guess you haven't been in the industry very long. Most of us here have seen things in code first hand that we wish we could unsee; many of us have, hopefully as junior developers, written much worse than what you describe. The key is to learn from the mistakes of others and avoid them yourself. If this is the worst you've seen, you've been lucky.
     



  • Personally I also do not like upper case too much, except in cases like the one shown in the original post: key strings.

    As for native language vs. English, I prefer to use German words for things from the problem domain (like "stock item" in a warehouse management system), and English words for purely technical things (like "lookup table"). "ControleNames" is IMO technical, so it would be written in English in my programs.

    Since most people pronounce ID as in I-D, it's only fair to write it like that.



  • oooooooh don't worry about that, it's certainly not the worst thing I had to put up with.

    It is just another silly line of code and I wanted to share it. The whole project is riddled with things like that and real WTFs like a 9 MB, 4 dimensional global array of which the meanings of the dimensions are unclear.

    A while ago I posted (or wanted to post) another little gem:

     

    procedure TMaintenance.OKBtnClick(Sender: TObject);
    begin
        Close;
    end;

    procedure TMaintenance.CancelBtnClick(Sender: TObject);
    begin
        Close;
    end;

    well, you get the point I guess.
     



  • @Gabelstaplerfahrer said:

    oooooooh don't worry about that, it's certainly not the worst thing I had to put up with.

    It is just another silly line of code and I wanted to share it. The whole project is riddled with things like that and real WTFs like a 9 MB, 4 dimensional global array of which the meanings of the dimensions are unclear.

    A while ago I posted (or wanted to post) another little gem:

     

    procedure TMaintenance.OKBtnClick(Sender: TObject);
    begin
        Close;
    end;

    procedure TMaintenance.CancelBtnClick(Sender: TObject);
    begin
        Close;
    end;

    well, you get the point I guess.
     

    Not so uncommon. In an application I've maintained, every form had (by convention) to have an "OK" and a "Cancel" button; "OK" would save and close, "Cancel" would close without saving; but in many forms, there is nothing to save (those forms just query data), so "OK" and "Cancel" both just closed the form.
     



  • But it's just wrong. If forms just query data the cancel button shouldn't be there and if the button is there it gives a sense of security, knowing that what you did can still be canceled.

    The form I'm talking about contains critical settings, change one innocent looking check box or radio button and the application grinds to a halt, bombarding the user with error messages he can't get out of, because of WTF timers performing tasks that crash.

    It's just, I am lacking the time and willpower to share everything that's wrong about this application with you guys, but really, it's bad. And I've been a reader of this site for quite a while now...


Log in to reply