• Chris Brien (unregistered)

    Nice pun - not only is it an absolutely horrid case statement which could have been replaced by a String append, but it is broken because of case-sensitivity.

    This is why we mustn't abbreviate. It's much harder to mistake "Upper" for "Lower", than it is to cause a bug by mistyping a single letter!

  • (cs)

    Does this function return anything?

    Shouldn't GetAgentEmail = agEmail be DecodeAgentEmail = agEmail



  • Anonymouse (the anonymous mouse) (unregistered)

    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...

  • (cs) in reply to haveworld

    haveworld:
    Does this function return anything?
    Shouldn't GetAgentEmail = agEmail be DecodeAgentEmail = agEmail

    Whoops -- my bad. I will usually change function/variable/entity names around to protect our brave submitters :-).

    And yes, "initech-global" is tribute to a favorite movie (Office Space).

  • (cs) in reply to haveworld

    I am not seeing things ... Alex changed the code without saying a thing.

  • (cs) in reply to Chris Brien
    Anonymous:
    This is why we mustn't abbreviate.

    You mean we must not abbreviate?
  • duh master (unregistered) in reply to Anonymouse (the anonymous mouse)

    uhhhh, dude, check out the "else" and you'll see why gwen got all the email.....

  • ewbi (unregistered)

    Not defending this (it's obviously bad on many levels), but the Select on a UCase value and subsequent check against lowercase values would work if the VB module included an "Option Compare Text" declaration.

    And, contrary to Chris' claim above, a simple append approach wouldn't account for the default case.

  • (cs) in reply to Anonymouse (the anonymous mouse)

    "but it works..."

    Note the use of UCase in the select case statement as opposed to the lower case "orbst", "jen", and "gwen" in each of the individual case statements. That's a pretty liberal definition of "works"...

  • Anonynous (unregistered) in reply to Anonymouse (the anonymous mouse)

    Anonymous:
    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...

    You are missing the point. Case Else is the same as Case "gwen". So poor gwend will get all the unmatched emails.

  • (cs) in reply to Anonymouse (the anonymous mouse)
    Anonymous:
    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...


    Don't forget to check the 'Display "Troll" Post" checkbox at the end of the page if you don't want to miss stuff like the above.
  • (cs)

    Took me a second, and then that big ol' ugly UCASE sat up and bit me right in the ass! What a laugh! Worth the searching!

  • (cs) in reply to Anonynous
    Anonymous:

    Anonymous:
    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...

    You are missing the point. Case Else is the same as Case "gwen". So poor gwend will get all the unmatched emails.

    It appears you too are missing the point.  The swtich is on the UPPER-CASE version of the name.  All the cases are lower-case.  The else is the only possible match.

  • (cs)
    Alex Papadimoulis:

    Dan Duda got a call from a client that was getting more and more frustrated with their custom-built software. Gwen was an employee at the client who was responsible for forwarding emails from the system to others in her group. Unfortunately, she left, requiring someone else to contstantly check her email box. The client was pretty adamant that Dan's predecessor (who developed the system) constantly told them that the system was designed to send an email to the correct employee, but that they need to configure it to do that.

    I think it's also a WTF that they checked her email instead of having it automatically forwarded to the proper recipients.  And I guess this company hasn't heard of distribution lists.

  • (cs)

    This is an obvious case of no testing going on before deploying this application...jeez. [:@] I know that this is a very basic function, but it should have been at least tested to see if it worked at ALL!

  • (cs) in reply to haveworld
    haveworld:
    Anonymous:
    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...


    Don't forget to check the 'Display "Troll" Post" checkbox at the end of the page if you don't want to miss stuff like the above.

    I disagree that it was a troll.  Certainly, I agree that email addresses should not be hardcoded.  And if the "UCase" were fixed to read "LCase" then it would indeed "work and be easy to read."

  • (cs) in reply to skicow

    skicow:
    This is an obvious case of no testing going on before deploying this application...jeez. [:@] I know that this is a very basic function, but it should have been at least tested to see if it worked at ALL!

    Oh come on!  How could they predict that Gwen wouldn't work there until the end of time?

  • Anonynous (unregistered) in reply to dubwai
    dubwai:
    Anonymous:

    Anonymous:
    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...

    You are missing the point. Case Else is the same as Case "gwen". So poor gwend will get all the unmatched emails.

    It appears you too are missing the point.  The swtich is on the UPPER-CASE version of the name.  All the cases are lower-case.  The else is the only possible match.

    It apear you missed ewbi's point.

  • (cs) in reply to Anonynous

    Anonymous:
    It apear you missed ewbi's point.

    What?  That it would work if it the VB module had kludgy option selected?  Yes, I missed that.  It would also work if it were written sensibly.  So what?  It didn't work because none of these things were done.

  • (cs) in reply to Anonynous
    Anonymous:
    dubwai:
    Anonymous:

    Anonymous:
    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...

    You are missing the point. Case Else is the same as Case "gwen". So poor gwend will get all the unmatched emails.

    It appears you too are missing the point.  The swtich is on the UPPER-CASE version of the name.  All the cases are lower-case.  The else is the only possible match.

    It apear you missed ewbi's point.

    What was the point again?[6]

  • (cs) in reply to skicow
    skicow:
    Anonymous:
    dubwai:
    Anonymous:

    Anonymous:
    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...

    You are missing the point. Case Else is the same as Case "gwen". So poor gwend will get all the unmatched emails.

    It appears you too are missing the point.  The swtich is on the UPPER-CASE version of the name.  All the cases are lower-case.  The else is the only possible match.

    It apear you missed ewbi's point.

    What was the point again?[6]



    It is possible that "Option Compare Text" was ON in which case the case would not matter (no pun intended).
  • bit (unregistered) in reply to haveworld

    Why? It seems to me s/he is not trolling. I think that the hardcoding of email addresses in the source code is the real WTF here. If you look, Gwen's address is in the company domain, so "poor Gwen" will obviously not receive them, because she left and lost access to that account (that company has system security policies, right?) The fact that Gwen's address, as every other address, is put IN THE SOURCE CODE OF THE PROGRAM is why this is a very bad idea.

  • (cs) in reply to dubwai
    dubwai:

    Anonymous:
    It apear you missed ewbi's point.

    What?  That it would work if it the VB module had kludgy option selected?  Yes, I missed that.  It would also work if it were written sensibly.  So what?  It didn't work because none of these things were done.

    Of course! Just like my VB.NET project would build without errors if I had Option Strict set to Off. [;)]

  • (cs) in reply to bit

    Anonymous:
    Why? It seems to me s/he is not trolling. I think that the hardcoding of email addresses in the source code is the real WTF here. If you look, Gwen's address is in the company domain, so "poor Gwen" will obviously not receive them, because she left and lost access to that account (that company has system security policies, right?) The fact that Gwen's address, as every other address, is put IN THE SOURCE CODE OF THE PROGRAM is why this is a very bad idea.

    Again... How could they possibly pedict that Gwen would not always work at this company?  You people just don't get it.  This guy was a coder, not a psychic.

  • (cs) in reply to haveworld

    haveworld:
    It is possible that "Option Compare Text" was ON in which case the case would not matter (no pun intended).

    But we *know* that "Option Compare Text" was not on because Gwen was the only one getting the email - if "Option Compare Text" was on other people would have received their mail, not just Gwen.

  • (cs) in reply to dubwai
    dubwai:

    Anonymous:
    Why? It seems to me s/he is not trolling. I think that the hardcoding of email addresses in the source code is the real WTF here. If you look, Gwen's address is in the company domain, so "poor Gwen" will obviously not receive them, because she left and lost access to that account (that company has system security policies, right?) The fact that Gwen's address, as every other address, is put IN THE SOURCE CODE OF THE PROGRAM is why this is a very bad idea.

    Again... How could they possibly pedict that Gwen would not always work at this company?  You people just don't get it.  This guy was a coder, not a psychic.

    lol - dubwai, I think you should end your posts with </sarcasm>, some people could be mistaken and think that you were serious[;)]

  • (cs) in reply to skicow
    skicow:

    haveworld:
    It is possible that "Option Compare Text" was ON in which case the case would not matter (no pun intended).

    But we *know* that "Option Compare Text" was not on because Gwen was the only one getting the email - if "Option Compare Text" was on other people would have received their mail, not just Gwen.

    And if it was on, why use UCase?  That would be a WTF intself.  Make the code look like it doesn't work and then set some silly option so that it does.

  • (cs) in reply to skicow
    skicow:

    haveworld:
    It is possible that "Option Compare Text" was ON in which case the case would not matter (no pun intended).

    But we *know* that "Option Compare Text" was not on because Gwen was the only one getting the email - if "Option Compare Text" was on other people would have received their mail, not just Gwen.



    Actually, the intro doesn't specifically say this. She may have been forwarding emails for those who were not added to the case.
  • (cs) in reply to dubwai

    I'm of the belief that people program at a particular competence level. If this horror of a programmer never bothered with databases or text files for storing the name-to-email mapping, then I would believe they have no idea what the various "Option" possibilities are (Explicit, Compare Text, etc). Even if the Compare Text is in there, that makes the person even more retarded for bothering to UCase the name before comparing it against lowercase names.

  • (cs) in reply to dubwai
    dubwai:
    skicow:

    haveworld:
    It is possible that "Option Compare Text" was ON in which case the case would not matter (no pun intended).

    But we *know* that "Option Compare Text" was not on because Gwen was the only one getting the email - if "Option Compare Text" was on other people would have received their mail, not just Gwen.

    And if it was on, why use UCase?  That would be a WTF intself.  Make the code look like it doesn't work and then set some silly option so that it does.



    It was never my intention to say that the code was WTF-free. I was simply stating the point that was made to defend one of the replies.
  • (cs) in reply to dubwai

    I agree that the WTF here is the hard coding of the e-mail addresses.  The upper case vs. lower case problem has been explained.  Sure, the fact VB has such an option is silly, but it does, so this code could very well have "worked."  But forget all that.  Let's say that there was no discrepancy regarding the case of anything in this code.  Even then this code would be absolutely horrible and, given enough time for old employees to leave and new employees to start, Gwen's e-mail account would still be getting all the e-mails.  The case discrepancy is indeed stupid, but in context with the greater error of hard coding the e-mail addresses and the fact that a simple VB option could make it work, it is minor.

  • (cs) in reply to UncleMidriff
    UncleMidriff:

    I agree that the WTF here is the hard coding of the e-mail addresses.  The upper case vs. lower case problem has been explained.  Sure, the fact VB has such an option is silly, but it does, so this code could very well have "worked."  But forget all that.  Let's say that there was no discrepancy regarding the case of anything in this code.  Even then this code would be absolutely horrible and, given enough time for old employees to leave and new employees to start, Gwen's e-mail account would still be getting all the e-mails.  The case discrepancy is indeed stupid, but in context with the greater error of hard coding the e-mail addresses and the fact that a simple VB option could make it work, it is minor.


    I think that repeating the "@initech.com" for every Case is a minor WTF in its own right.  A literal in more than one place generally begs for a constant.
  • (cs) in reply to smitty_one_each

    "@initech-global.com", sorry.

  • (cs) in reply to UncleMidriff

    UncleMidriff:
    I agree that the WTF here is the hard coding of the e-mail addresses.

    Oh yeah right! [^o)] The developer should have used some sort of magical dynamic data repository type thing.  Let me know when that's invented.

  • (cs) in reply to haveworld
    haveworld:
    skicow:

    haveworld:
    It is possible that "Option Compare Text" was ON in which case the case would not matter (no pun intended).

    But we *know* that "Option Compare Text" was not on because Gwen was the only one getting the email - if "Option Compare Text" was on other people would have received their mail, not just Gwen.



    Actually, the intro doesn't specifically say this. She may have been forwarding emails for those who were not added to the case.

    You are correct, the intro doesn't specifically says this, but what it does specifically do is point us towards the use of the use of UCase and the fact that all case values are lower case.

    Alex:

    <!--StartFragment --> After a bit of research, Dan tracked down the problem. Now, ignoring for the moment that this was written in VB well before databases, flat files, and every other disk-storage method was invented, note why the method always bothered poor Gwen ...

    Having read that statement I assumed that Dan had assessed the problem, and come to the conclusion that the reason this code was a candidate for WTF was because of the UCase problem.

    Anyways, all I'm saying is that using UCase in the select case, and then having all case values in lower case is a much bigger WTF than having the email addresses hard coded in the source code - though that is still a WTF too.

  • (cs) in reply to smitty_one_each
    smitty_one_each:
    UncleMidriff:

    I agree that the WTF here is the hard coding of the e-mail addresses.  The upper case vs. lower case problem has been explained.  Sure, the fact VB has such an option is silly, but it does, so this code could very well have "worked."  But forget all that.  Let's say that there was no discrepancy regarding the case of anything in this code.  Even then this code would be absolutely horrible and, given enough time for old employees to leave and new employees to start, Gwen's e-mail account would still be getting all the e-mails.  The case discrepancy is indeed stupid, but in context with the greater error of hard coding the e-mail addresses and the fact that a simple VB option could make it work, it is minor.


    I think that repeating the "@initech.com" for every Case is a minor WTF in its own right.  A literal in more than one place generally begs for a constant.

    Assuming you are serious:

     

    For all we know, those email addresses weren't all the same.  It could be that they were all wildly different, but since Alex or the original poster changed all of them to protect the innocent, who knows.

  • (cs) in reply to haveworld
    haveworld:
    skicow:

    haveworld:
    It is possible that "Option Compare Text" was ON in which case the case would not matter (no pun intended).

    But we *know* that "Option Compare Text" was not on because Gwen was the only one getting the email - if "Option Compare Text" was on other people would have received their mail, not just Gwen.



    Actually, the intro doesn't specifically say this. She may have been forwarding emails for those who were not added to the case.

    The title is 'It's Always the Case' and Intro asks us to figure out why it 'always' bothered poor Gwen.   Seems pretty obvious to me that that was the point.

  • (cs) in reply to skicow
    skicow:

    Having read that statement I assumed that Dan had assessed the problem, and come to the conclusion that the reason this code was a candidate for WTF was because of the UCase problem.

    I agree with you there.  It does seem our attention was directed away from the hard codedness and toward the case problem.

    skicow:

    Anyways, all I'm saying is that using UCase in the select case, and then having all case values in lower case is a much bigger WTF than having the email addresses hard coded in the source code - though that is still a WTF too.

    I really have to disagree with you there.  I see the converting of the string to uppercase and then comparing it to lower case values as being nearly impossible to do unless by accident.  In other words, I can understand how someone could have gotten distracted between the use of UCase and the writting of the Case statements.  I can hardly imagine that being purposeful.  Sure, something like that should never make it to production, but I can understand how it might have been a careless mistake.

    The hard coding of the e-mail addresses, on the other hand, I have a harder time seeing as anything but purposeful.  The fact that it seems more intentional makes it seem more indicative of a true lack of understanding of the way things should be than the case problem, and thus, the bigger WTF.

  • (cs)

    You people are hurting my head.

  • (cs) in reply to Manni

    Actually it's worse. Some parts of the app do use the database to store the email addresses. It's a patch work and was done by a single programmer not a team that wasn't communicating.

  • (cs)

    the Ucase thing is pure stupidity, they obviously meant Lcase.
    Anybody could of made that mistake, but any decent developer would of picked that up during simple testing.

    However putting the email addresses in-code is definatley the real WTF
    they could of at least put them  in a text file.

    It's not like file i/o is very difficult in VB.

  • (cs) in reply to Sweets

    The WTF here is not that the developer used UCase instead of LCase. It's a simple typo; Everybody makes 'em all the time. No, the real WTF is the complete and utter lack of any sort of code reviews or testing or simple proofreading that would have caught this immediately.

    I don't know why everyone's getting so hung up on the hardcoded email addresses. Depending on the circumstance, hardcoded addresses have their uses. For instance, if your app sends out an email to technical support when the database server goes down, it wouldn't do much good to store email addresses in the database, now would it?

    And yes, you could store the email address in a text file. But if you happen to be coding in ASP, your deployed application IS a text file (or several text files). Editing an ASP file is not much more difficult than editing any other kind of text file.

    But if this is a client application installed on multiple workstations, then yeah, that's retarded.

     

  • (cs) in reply to A Wizard A True Star

    but at least, if you MUST put email address hardcoded in a program, then DON'T put the addresses of individual people in there, but group names, that are distributed to individual people by the mail server. (speaking of hard-coding tech support email: that should hardly be [email protected] but rather [email protected]).


    I totally agree that the real WTF is those hardcoded email addresses.

  • (cs) in reply to haveworld
    haveworld:
    skicow:
    Anonymous:
    dubwai:
    Anonymous:

    Anonymous:
    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...

    You are missing the point. Case Else is the same as Case "gwen". So poor gwend will get all the unmatched emails.

    It appears you too are missing the point.  The swtich is on the UPPER-CASE version of the name.  All the cases are lower-case.  The else is the only possible match.

    It apear you missed ewbi's point.

    What was the point again?[6]



    It is possible that "Option Compare Text" was ON in which case the case would not matter (no pun intended).


    In which case it would still be a WTF because he used UCase which will be totally unecessary when Option Compare Text was on.
  • Brain dead AOLer (unregistered) in reply to Jon Limjap
    Jon Limjap:
    haveworld:
    skicow:
    Anonymous:
    dubwai:
    Anonymous:

    Anonymous:
    The WTF here is that the email addresses are hard-coded into the app.  I don't have that much of a problem with the case statement.  It may not be the best way to code it, but it works and it's easy to read.  The developer should be shot for hard coding the email addresses, though.  Talk about planned obsolescence...

    You are missing the point. Case Else is the same as Case "gwen". So poor gwend will get all the unmatched emails.

    It appears you too are missing the point.  The swtich is on the UPPER-CASE version of the name.  All the cases are lower-case.  The else is the only possible match.

    It apear you missed ewbi's point.

    What was the point again?[6]



    It is possible that "Option Compare Text" was ON in which case the case would not matter (no pun intended).


    In which case it would still be a WTF because he used UCase which will be totally unecessary when Option Compare Text was on.

    Me too!
  • (cs) in reply to A Wizard A True Star
    A Wizard A True Star:

    I don't know why everyone's getting so hung up on the hardcoded email addresses. Depending on the circumstance, hardcoded addresses have their uses. For instance, if your app sends out an email to technical support when the database server goes down, it wouldn't do much good to store email addresses in the database, now would it?

    And yes, you could store the email address in a text file. But if you happen to be coding in ASP, your deployed application IS a text file (or several text files). Editing an ASP file is not much more difficult than editing any other kind of text file.

    But if this is a client application installed on multiple workstations, then yeah, that's retarded.

    I'd argue that it is retarded no matter what.  People and groups change e-mail addresses regularly enough that there's just no excuse for hard coding them.

    Also, in my work place, and I imagine most others, changing code involves more that opening up Notepad, changing a few lines, and saving.  Any time we change code here, we have to go through a test on the development database, a test on the production test database, and then finally the changes will be moved into production.  All the tests are followed by the parties invloved signing off that everything works ok.  So, with the sending of e-mails back and forth to coordinate at least three parties (developer, user, and the operations group that conducts the testing) and the setting up of tests and carrying them out, the time it takes to make a code change really adds up and costs money.  Doing all of that everytime an e-mail address changes just isn't smart.

    It makes so much more sense to store the addresses in a text file, database, anything that could then be changed through the application itself.

  • (cs)

    Hard coded addresses. So... progressive. The only thing missing here is self modifying code. "How to get non-redeemable in 21 days..."

    I had this once in a project, where I "inherited" a project. My predecessor was a sailor, who had a job training for software developer. There was an INI file, where you could define the IP address of the target server (to store the data), but no matter which IP address you put there, it always was stored on the same test server. Debugging was impossible (due to the structure of the project), and so I did P&P debugging (pen and paper). When the program was started, the data was read and stored correctly. Then I checked if something changed the data, but I couldn't find anything. Okay, heading for the upload. And then, about 2 hours after start of debugging I found the problem in a small procedure (Delphi). Just a few statements before the upload started, he changed the IP address in the upload object to a hard coded one. What a pity, that I am a pacifist. I could've killed him with a smile on my face.

  • TeXMex (unregistered) in reply to Brain dead AOLer

    What a lovely recursive set of Boxes! Lets make more of them! 8)

  • (cs) in reply to UncleMidriff
    UncleMidriff:

    skicow:

    Anyways, all I'm saying is that using UCase in the select case, and then having all case values in lower case is a much bigger WTF than having the email addresses hard coded in the source code - though that is still a WTF too.

    I really have to disagree with you there.  I see the converting of the string to uppercase and then comparing it to lower case values as being nearly impossible to do unless by accident.  In other words, I can understand how someone could have gotten distracted between the use of UCase and the writting of the Case statements.  I can hardly imagine that being purposeful.  Sure, something like that should never make it to production, but I can understand how it might have been a careless mistake.

    The hard coding of the e-mail addresses, on the other hand, I have a harder time seeing as anything but purposeful.  The fact that it seems more intentional makes it seem more indicative of a true lack of understanding of the way things should be than the case problem, and thus, the bigger WTF.

    When you put it that way I can agree with you as well - the UCase was a mistake, and the hardcoding was on purpose.

    Why I picked the UCase to being the worse of the two WTF's is that it caused this function to never have worked in the first place - and that says to me that this function was never tested to see if it worked properly. Hard coding the email is wrong but the function would still work.

    I guess we agree to disagree [:)]

  • Hank Miller (unregistered)

    You are all missing the WTF, because it is something that is missing in the code: a comment that says:

    "Note, this should use a database of some sort to get these names, but right now my mind is full learning VB and the email modules. Come back latter and flesh this code out."

    I could see myself writing something like this on my first or second day working with VB. Then the code works well enough so I get sent on to other projects, and before I know it I've forgotten about this little hack.

    However I cannot see me writing something like this without a comment like that.   I would lookup the format for comments in VB if I didn't know them.   Though I guess I could make the claim documentation read is difficult and thus I hadn't yet found the syntax for comments.  

Leave a comment on “It's Always the Case”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article