Comment On It's Always the Case

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!

Does this function return anything?



Shouldn't GetAgentEmail = agEmail be DecodeAgentEmail = agEmail

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

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).

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

Anonymous:

This is why we mustn't abbreviate.

You mean we must not abbreviate?

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

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.

"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"...

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.

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.

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!

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.

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.

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!

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."

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?

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.

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.

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]

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).

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.

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. [;)]

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.

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.

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[;)]

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.

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.

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.

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.

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.

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.

"@initech-global.com", sorry.

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.

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:

 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.

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.

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.

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.

You people are hurting my head.

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.

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.

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.

 

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
mike@initech.com but rather techsupport@initech.com).





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

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.

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!

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.

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.

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

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 [:)]

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.