• (cs) in reply to UncleMidriff
    UncleMidriff:
    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:

    Yes, I am.  This site, while served up as humor, is really a group code-review, no?


    For all we know, those email addresses weren't all the same. 


    As you say "all we know".  The case at hand appears to be a set of adresses on the same mail server.

    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.



    In this hypothetical case, I would still argue in favor of maintaining a set of constants with the names of the hypothetically small set of mail server names.  Clearly, such a scheme falls apart for a hypothetical^hypothetical number of servers.
    Now, if you're going to dynamically generate this code, rather than maintain it by hand, fine: I'm arguing art for art's sake.
    However, had you that kinda smarts, would you have done this in the first place?

  • (cs) in reply to Hank Miller

    I actually remembered tha there is a good reason to hardcode one email address in the code.  More than once I've seen an error go unreported or displayed with no informative detail because error handling was dependent on the database.  This doesn't work when the DB is unavailable, for whatever reason (usually the DB being unavailable is the problem.)  So you need a drop final, all-else has failed handler that sends an email to a hardcoded address.  The address should not be a personal one, though.  It should be a distribution list.

  • soops (unregistered) in reply to Jon Limjap

    It's a WTF that you dozy buggers don't snip a little before you reply.

  • (cs) in reply to UncleMidriff
    UncleMidriff:

    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.



    Right, UCase may have been a careless mistake, but NOT REALIZING ALL EMAIL WAS BENG SENT TO ONE PERSON because the programmer OBVIOUSLY DIDNT DO ANY TESTING, or even BOTHER TO CHECK IF THE PROGRAM WORKED, was a purposeful, conscious WTF decision by the programmer.  He should be shot, hanged, drawn, quartered and fed to the sharks with laser beams on their heads.

    PS: I apologize for the yelling,
  • me (unregistered)

    The WTF looks like the UCase and comparing against lower case strings and always sending emails to Gwen.

    "Gwen was an employee at the client who was responsible for forwarding emails from the system to others in her group. "

    "note why the method always bothered poor Gwen ..."  

    These seem to say that Gwen always received the emails and no one else was receiving emails from the application.

  • (cs) in reply to UncleMidriff
    UncleMidriff:
    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.


    While I'm sure that you don't have a similar process for data files, does it really make any practical difference if the email address is in a source code file or a data file?  If editing it in one place can break the program then editing it in the other can.  Since reading in the file is slightly more complex than hardcoding the address the odds of breaking the system are that much greater with the external file.


    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.



    Leaving possible broken processes aside, if a programer is going to be making the change in any case, I don't see the practical difference between hard coded and externally stored email addresses.
  • (cs) in reply to jstrayer
    jstrayer:

    While I'm sure that you don't have a similar process for data files, does it really make any practical difference if the email address is in a source code file or a data file?  If editing it in one place can break the program then editing it in the other can.  Since reading in the file is slightly more complex than hardcoding the address the odds of breaking the system are that much greater with the external file.

    ...


    Leaving possible broken processes aside, if a programer is going to be making the change in any case, I don't see the practical difference between hard coded and externally stored email addresses.

    The difference is that of data verus application logic.  Once you have created an application that can read the data from a file or somewhere else, changing the data in the file is simple and relatively safe.

    Putting it in code means you have to change your application logic every time the addresses change.  It also means you cannot configure the application to use different addresses in different installations without creating different versions of your application.

  • (cs)

    I was taken in by the UCase. As a C guy I originally thought it was passing through because of the missing break statements - a quick search of VB Case set me straight.

    I imagine it was tested. Mails were sent and Gwen got them. I bet they never decided to test any other case.

    I have worked with a programmer like that - until the company canceled his contract. However, the damage he did to the systems he developed would make a coder's eyes bleed. Imagine 4-5 layers of OOD where specific commands are eventually translated into a string that tells the parent how to execute a task.

    Better yet, imagine a VB program with only a single form, but with images created according to a layout sent by a webpage - the entire thing sent by 1 webpage of meta-layout tags. Now it rebuilds that same form with every page call. There there are image objects that he has extended so that they can function like buttons - but without full button functionality. They can only fire off an action.

    but all of that is coming to an end as I start my new job.

  • (cs) in reply to GalacticCmdr

    There there are image objects that he has extended so that they can function like buttons - but without full button functionality. They can only fire off an action.

    Truly I wish I had the source code, for it bears posting here.
    I once saw a report criteria (cry-teria) page where someone had perverted radio buttons to work as checkboxes.
    It was a monument to anti-RTFM, that page.
    When I asked the project manager who had produced this [colorful language], he responded quickly that a former contractor was the perpetrator.
    Later, I heard that the project manager himself had worked on that functionality at one point, and I learned something: be positive, no matter the scope of the train wreck at hand, as you never know who engineered it.

  • Matt (unregistered) in reply to Anonynous

    ewbi's point was pointless; if the coder was thinkning that comparisons were case-insensitive, why would he have uppercased the input in the first place?

  • (cs) in reply to smitty_one_each
    smitty_one_each:

    Yes, I am.  This site, while served up as humor, is really a group code-review, no?

    As you say "all we know".  The case at hand appears to be a set of adresses on the same mail server.

    In this hypothetical case, I would still argue in favor of maintaining a set of constants with the names of the hypothetically small set of mail server names.  Clearly, such a scheme falls apart for a hypothetical^hypothetical number of servers.
    Now, if you're going to dynamically generate this code, rather than maintain it by hand, fine: I'm arguing art for art's sake.
    However, had you that kinda smarts, would you have done this in the first place?

    You're right, I agree with you, and I'm sorry.  I didn't mean to sound snippy in my reply to you.  That wasn't my intent and I apologize.

    @Charles Nadolski:

    Agreed.  The utter lack of testing is a major WTF.

    jstrayer:

    While I'm sure that you don't have a similar process for data files, does it really make any practical difference if the email address is in a source code file or a data file?  If editing it in one place can break the program then editing it in the other can.  Since reading in the file is slightly more complex than hardcoding the address the odds of breaking the system are that much greater with the external file.

    I'm assuming that one doesn't just go straight to the external data file and edit values directly, but rather that one can only do so through the application.  On top of that assumption, it should be assumed that the application will be written in such away that it validates the data going into and coming out of the external data file.  When I say that the e-mail addresses shouldn't be hard coded, I do not mean that they should rather be sucked in from a text file all willy nilly like.  I mean that the application should be written in such a way that the storing, retrieval, and use of the e-mail addresses is relatively painless, with errors in any part of the process being handled appropriately.

    jstrayer:

    ...if a programer is going to be making the change in any case, I don't see the practical difference between hard coded and externally stored email addresses.

    My point of view on this whole problem is that the user should be able to change which people are e-mailed various reports via a configuration screen in the application.  Thus, I would argue that if the programmer has to be the one making changes to something that should be handled by the user through the application, then something is wrong.

  • (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...


    Actually, you don't get the problem of the case statement. He converts agCode to UPPERCASE while all comparison values are lowercases. This way, it will NEVER match any of the values in the case statement and thus poor Gwen has to forward all of it to everyone else...
  • drake (unregistered) 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.

  • (cs) in reply to Matt
    Anonymous:
    ewbi's point was pointless; if the coder was thinkning that comparisons were case-insensitive, why would he have uppercased the input in the first place?

    The coder was merely trying to make the cases execute faster by making that input YELL at the compiler...



  • Nex (unregistered)

    This site is getting gold seller spam now? Seriously?

    wow gold:
    Out of ... is substantial.
  • Smithd288 (unregistered)

    Very neat article post.Much thanks again. Much obliged. aceakfaddfgdbbfg

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

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article