The Daily WTF: Curious Perversions in Information Technology

Gene Wirchenko · 2005-11-22 Reply Admin

Alex Papadimoulis:
Jon Colomis works with the (self-proclaimed) world's best coder, who's qualifications include an honours degree from a first-class UK university AND a *solid* semester of real-world experience.

A bit of redundancy there: aren't all "best" coders self-proclaimed.

After a few hours of trying it, he demanded that his portion of the project be coded in C++. "Microsoft couldn't even spell QA," he quipped, "writing to a stupid property overflows the stack!" When Jon pointed out his mistake, the word's best coder scoffed, claiming that "this crap would never happen in C++" ...

I wish I were half as good as these self-proclaimed best coders.

Sincerely,

Gene Wirchenko

2005-11-22 Reply Admin

For once, we can't blame the "stupid Americans"! Bloody Limeys!

USA! USA! USA!

Sean · 2005-11-22 Reply Admin

What would never happen? Writing crappy code? I've inherited plenty of C++ code in the past that would cause me to beg to differ.

Manni · 2005-11-22 Reply Admin

This would never happen in a case-insensitive language like VB.

</sarcasm>

dabocla · 2005-11-22 Reply Admin

I think that it would be difficult to proclaim a status of "BEST" if one's experience is still being measured in semesters. :)

.jc

2005-11-22 Reply Admin

Maybe this guy should have tried debugging his work before opening his mouth. (It is better to keep your mouth closed and let people think you are a fool than to open it and remove all doubt. -- Mark Twain)

2005-11-22 Reply Admin

Manni:
This would never happen in a case-insensitive language like VB.

AFAIK at least VB.NET /is/ case-sensitive ;-)

Oh and did this man ever hear of the cool & _really_ handy debugging tools that are built into any later IDE?...

xenoputtss · 2005-11-22 Reply Admin

Bahhh Damn you L!! how dare you grow in size!

haveworld · 2005-11-22 Reply Admin

Waiting for someone to comment on what's wrong with the code.

rlewallen · 2005-11-22 Reply Admin

Anonymous:

AFAIK at least VB.NET /is/ case-sensitive ;-)

No, its not.

rlewallen · 2005-11-22 Reply Admin

haveworld:
Waiting for someone to comment on what's wrong with the code.

LOL. Copy it, set the value of LastName property, and wait for it to finish. Come back and let us know when its done.

2005-11-22 Reply Admin

VB.Net is most definitely NOT case sensitive, which is why you can't have CLRCompliant attributes on c# assemblies that have differently-cased methods or classes w/ the same name.

haveworld · 2005-11-22 Reply Admin

rlewallen:
haveworld:
Waiting for someone to comment on what's wrong with the code.

LOL. Copy it, set the value of LastName property, and wait for it to finish. Come back and let us know when its done.

Oh I get it. Recursion. Case-sensitive.

frosty · 2005-11-22 Reply Admin

haveworld:
Waiting for someone to comment on what's wrong with the code.

So am I. I don't know .Net or C-Pound.

... ugh, I'm falling into the depths of those who scream "Brillant" and the related.

christoofar · 2005-11-22 Reply Admin

HOW FUNNY!!!

OMG I couldn't stop giggling.

kleinux · 2005-11-22 Reply Admin

haveworld:
Waiting for someone to comment on what's wrong with the code.

it should have been written:
...
set
{
lastName = value;
}

with the uppercase L as written it is a recursive call to the setter.

/praying the formatting of this post is okay.

christoofar · 2005-11-22 Reply Admin

A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.

2005-11-22 Reply Admin

This would have worked:

public class User
{
/* ED: Snip */
protected string m_LastName;
public string LastName
{
get
{
return (m_LastName == null) ? "" : m_LastName;
}
set
{
m_LastName = value;
}
}
}

I know the m_ convention is considered trite, but at least it would have prevented this particular stupid mistake.

2005-11-22 Reply Admin

Waiting for someone to comment on what's wrong with the code.

For starters, it's written in C#.

What happens is, the line "Lastname = value" recurses infinitely. Why? Because the "preprocessor" in C# translates:

Lastname = value

into

void setLastName( const char *value )
{
setLastName( value );
}

rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign). And the original coder is right. This wouldn't happen in an even remotely thought-out programming language.

whojoedaddy · 2005-11-22 Reply Admin

I get it, because User doesn't inherit from Person right?

marvin_rabbit · 2005-11-22 Reply Admin

Alex Papadimoulis:

... "this crap would never happen in C++" ...

"Yeah! When I make a case error in C++, it just blissfully returns unexpected values and I never have to worry about run-time errors."

2005-11-22 Reply Admin

Just out of curiousity would it ever be considered a "good thing" for a property to be recursive in the first place? Is it possible that the compiler not catching a recursive call is actually the big bug?

2005-11-22 Reply Admin

HA,

Thats almost as stupid as the time that I did exactly the same thing, I say almost because... well I figured it out almost straight away - and kept quiet about it so no one would know...

christoofar · 2005-11-22 Reply Admin

Anonymous:
> Waiting for someone to comment on what's wrong with the code.

For starters, it's written in C#.

What happens is, the line "Lastname = value" recurses infinitely. Why? Because the "preprocessor" in C# translates:

Lastname = value

into

void setLastName( const char *value )
{
setLastName( value );
}

rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign). And the original coder is right. This wouldn't happen in an even remotely thought-out programming language.

I beg to differ. This *is* well thought out. It's clearly obvious just from the source he recursing ad infinitum, it's actually painfully obvious (unlike following compound pointer derefs and typecasting is C++).

The programmer should have followed some typical coding style that makes field identifiers clearer, the most-popular of which is to preface the identifier with an underscore, so that you know two things off the bat:

this variable has class level scope
this variable has my encapsulated state and should not be directly exposed

Maybe a compiler warning enhancement should be added to help make something like this more obvious to the schmucks who don't follow the _myVar style? That's another debate entirely.

2005-11-22 Reply Admin

Anonymous:
Just out of curiousity would it ever be considered a "good thing" for a property to be recursive in the first place? Is it possible that the compiler not catching a recursive call is actually the big bug?

I don't see why it should be prohibited. Would you want to add a similar feature for functions as well?

2005-11-22 Reply Admin

You don't want the compiler catching recursion, anyway; it would have to inject code around the method body, making it slower and harder to inline, among other things.

mrsticks1982 · 2005-11-22 Reply Admin

frosty:
haveworld:
Waiting for someone to comment on what's wrong with the code.

So am I. I don't know .Net or C-Pound.

... ugh, I'm falling into the depths of those who scream "Brillant" and the related.

yes, it is a c with the pound symbol but it is C-SHARP .... <cue>charlie brown scream as he tries to kick the american football</cue>

2005-11-22 Reply Admin

christoofar:
A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.

The funny thing is the code conforms to Microsoft's design guidelines for naming classes/members/properties (which I personally find to be quite lame):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

mrsticks1982 · 2005-11-22 Reply Admin

christoofar:
Anonymous:
> Waiting for someone to comment on what's wrong with the code.

For starters, it's written in C#.

What happens is, the line "Lastname = value" recurses infinitely. Why? Because the "preprocessor" in C# translates:

Lastname = value

into

void setLastName( const char *value )
{
setLastName( value );
}

rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign). And the original coder is right. This wouldn't happen in an even remotely thought-out programming language.

I beg to differ. This *is* well thought out. It's clearly obvious just from the source he recursing ad infinitum, it's actually painfully obvious (unlike following compound pointer derefs and typecasting is C++).

The programmer should have followed some typical coding style that makes field identifiers clearer, the most-popular of which is to preface the identifier with an underscore, so that you know two things off the bat:

this variable has class level scope

this variable has my encapsulated state and should not be directly exposed

Maybe a compiler warning enhancement should be added to help make something like this more obvious to the schmucks who don't follow the _myVar style? That's another debate entirely.

I have to agree ... surely the world's best coder should also be the world's best variable declarer. Also, why does someone need to boast about how good they are, when in the industry you have to show/do what you are good at.

OH YEAH, when they talk more than they do, they just don't have the goods....compensating for what they lack.

2005-11-22 Reply Admin

Anonymous:
You don't want the compiler catching recursion, anyway; it would have to inject code around the method body, making it slower and harder to inline, among other things.

There are some checks the compiler can do for recursion without injecting code simply by checking for unconditional recursion before an exit point (I think VS might do this already).

mrsticks1982 · 2005-11-22 Reply Admin

common sense is not for everyone

Manni · 2005-11-22 Reply Admin

marvin_rabbit:
Alex Papadimoulis:

... "this crap would never happen in C++" ...

"Yeah! When I make a case error in C++, it just blissfully returns unexpected values and I never have to worry about run-time errors."

This is an automated signature. I can't be bothered to type it in each time.

Thief! I'm calling the signature police! I'm pressing charges! The death penalty for you!

Satanicpuppy · 2005-11-22 Reply Admin

If it does conform to their guidelines, their guidelines suck. If you name your method and the variable for your method the same thing with a very slight change in capitalization, you're going to make this mistake.

Besides, as someone else pointed out above, wouldn't it have been _lastName for the variable, if the programmer had been following MS's policy?

quamaretto · 2005-11-22 Reply Admin

I'm going to be honest. I've done this several times. Of course, the mistake itself is not in this case the big WTF. :)

.NET does have an interesting set of WTFs, but hell, I would take it over C++ for almost any purpose..

christoofar · 2005-11-22 Reply Admin

Anonymous:
christoofar:
A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.

The funny thing is the code conforms to Microsoft's design guidelines for naming classes/members/properties (which I personally find to be quite lame):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

<o:p></o:p>

That's somewhat old. I prefer the Philips guide plus some enhancements I have made.

ammoQ · 2005-11-22 Reply Admin

Anonymous:
Just out of curiousity would it ever be considered a "good thing" for a property to be recursive in the first place? Is it possible that the compiler not catching a recursive call is actually the big bug?

Yes. It's probably not common, but I can think of certain cases where you would do that.


public Foo Bar

{

   set

   {

      try {

        process(value);

        moreProcess(value);

        evenMoreProcess(value);

     }

     catch

     {

         Bar = value.playSafe;  // Recursion

     }

   }

}

Matt B · 2005-11-22 Reply Admin

Anonymous:

For starters, it's written in C#.
...
rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign). And the original coder is right. This wouldn't happen in an even remotely thought-out programming language.

Clearly the better alternative is to have two methods (getFoo() and setFoo()) for every property your class wants to expose.

Oh wait, this does the same exact thing, just in the IL.

Sean · 2005-11-22 Reply Admin

Anonymous:
You don't want the compiler catching recursion, anyway; it would have to inject code around the method body, making it slower and harder to inline, among other things.

You're right. You can technically place logic in property declarations (although if it's at all complex it should be frowned upon). While for the life of me I can't think of why anyone would want to, I guess one could feasibly have recursive logic in a setter or getter. And make it work without crashing the software at that.

christoofar · 2005-11-22 Reply Admin

ammoQ:
Anonymous:
Just out of curiousity would it ever be considered a "good thing" for a property to be recursive in the first place? Is it possible that the compiler not catching a recursive call is actually the big bug?

Yes. It's probably not common, but I can think of certain cases where you would do that.

public Foo Bar { set { try { process(value); moreProcess(value); evenMoreProcess(value); } catch { Bar = value.playSafe; // Recursion } } }

That gets close to violating the principle of least surprise. What do I mean by that? You usually don't expect an exception to be raised when you read a property... maybe when you set one, but not when just reading it.

If something bad happens in the property read you would want to return a null value (say you implement a Parent property and when you look for the parent object it isn't there) or whatever you establish as baseless for a value type (0/-1) to avoid surprising the client.

If you must return an exception, then consider using a method instead and return an explicit exception (ParentNotFound), etc.

2005-11-22 Reply Admin

Anonymous:
> Waiting for someone to comment on what's wrong with the code.

For starters, it's written in C#.

What happens is, the line "Lastname = value" recurses infinitely. Why? Because the "preprocessor" in C# translates:

Lastname = value

into

void setLastName( const char *value )
{
setLastName( value );
}

rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign). And the original coder is right. This wouldn't happen in an even remotely thought-out programming language.

Yes, C++ is so much more thought out. Witness the following example:

class lastName {

public:

   boolean operator=(lastName x) 
   {

      declareGlobalThermoNuclearWar();

      return true;
     }
 }

christoofar · 2005-11-22 Reply Admin

Sean:
Anonymous:
You don't want the compiler catching recursion, anyway; it would have to inject code around the method body, making it slower and harder to inline, among other things.

You're right. You can technically place logic in property declarations (although if it's at all complex it should be frowned upon). While for the life of me I can't think of why anyone would want to, I guess one could feasibly have recursive logic in a setter or getter. And make it work without crashing the software at that.

Agreed. It's bad.

Property reads are good places to place calculated values or complex object lookup returns. For example if you have a data object with properties to retrieve objects higher up in the food chain, a property read is a good place to do that. Say this (C# pseudo):

//Notify all dept heads if they have any birthday boys & girls!
foreach (Employee employee in Employees.GetEmployeesByBirthdate(DateTime.Today))
{	
	//We don't expect Employees to ever throw an exception here; only return an empty result.
	if (employee.Department == null || 
	    employee.Department.Employees == null ||
	    employee.Department.Employees.Count == 0)
	{
		continue;
	}

	//Employee 0 is always the dept-head.
	SendMail mail = new SendMail();
	mail.To = employee.Department.Employees[0].Email;
	mail.Subject = "It's " + employee.FullName + "'s Birthday!";
	mail.From = "HR";
	mail.Send();

	//Maybe we should put a counter to see how many emails we were able
	//to get out vs. how many we couldn't here.
}

Of course, the natural counter-argument is "What if the database lookup fails for for Department.Employees? Returning 0 employees would be bad because that is wrong!".

Well, that depends on what you are doing. 0 and NULL are different. If you return a null value, you could react to that. If it's serious, then by all means generate an exception. But... are you going to be reacting appropriately to the exception if/when it occurs for EVERY property read? Probably not... so a method call would be better.

ehabkost · 2005-11-22 Reply Admin

christoofar:
ammoQ:

public Foo Bar { set { try { process(value); moreProcess(value); evenMoreProcess(value); } catch { Bar = value.playSafe; // Recursion } } }

That gets close to violating the principle of least surprise. What do I mean by that? You usually don't expect an exception to be raised when you read a property... maybe when you set one, but not when just reading it.

Uh... did you read the code above? Where would the code above raise an exception on get?

ammoQ · 2005-11-22 Reply Admin

christoofar:
ammoQ:
Anonymous:
Just out of curiousity would it ever be considered a "good thing" for a property to be recursive in the first place? Is it possible that the compiler not catching a recursive call is actually the big bug?

Yes. It's probably not common, but I can think of certain cases where you would do that.

public Foo Bar { set { try { process(value); moreProcess(value); evenMoreProcess(value); } catch { Bar = value.playSafe; // Recursion } } }

That gets close to violating the principle of least surprise. What do I mean by that? You usually don't expect an exception to be raised when you read a property... maybe when you set one, but not when just reading it.

If something bad happens in the property read you would want to return a null value (say you implement a Parent property and when you look for the parent object it isn't there) or whatever you establish as baseless for a value type (0/-1) to avoid surprising the client.

If you must return an exception, then consider using a method instead and return an explicit exception (ParentNotFound), etc.

This property cannot be read. It's an artificial example anyway.

2005-11-22 Reply Admin

christoofar:
A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.

Identifiers with a leading underscore are resevered for the compiler in C++. You don't do that.

masklinn · 2005-11-22 Reply Admin

Anonymous:
> Waiting for someone to comment on what's wrong with the code.

For starters, it's written in C#.

What happens is, the line "Lastname = value" recurses infinitely. Why? Because the "preprocessor" in C# translates:

Lastname = value

into

void setLastName( const char *value )
{
setLastName( value );
}

rather than doing what any reasonable person would expect (that is, set a variable when one appears on the left-hand side of an = sign). And the original coder is right. This wouldn't happen in an even remotely thought-out programming language.

Such as Ruby you mean?

And in C#'s case, what was extremely badly thought of was considering properties as nothing more than syntactic sugar for Java-style accessor functions instead of virtual members generators (which is their role in Python or Ruby)

whojoedaddy · 2005-11-22 Reply Admin

mrsticks1982:

frosty:
haveworld:
Waiting for someone to comment on what's wrong with the code.

So am I. I don't know .Net or C-Pound.

... ugh, I'm falling into the depths of those who scream "Brillant" and the related.

yes, it is a c with the pound symbol but it is C-SHARP .... <CUE>charlie brown scream as he tries to kick the american football</CUE>

Guess that was before your time C-Pound

Just in case the freakin' formatting doesn't work ... http://www.thedailywtf.com/forums/34804/ShowPost.aspx

JohnO · 2005-11-22 Reply Admin

masklinn:

And in C#'s case, what was extremely badly thought of was considering properties as nothing more than syntactic sugar for Java-style accessor functions instead of virtual members generators (which is their role in Python or Ruby)

Actually, they are a continuation of the VB4 style property let/set/get syntax. Not sure why you think Java was involved.

christoofar · 2005-11-22 Reply Admin

Anonymous:
christoofar:
A typical coding style rule for C# and C++ is to give the identifiers which are fields to your class the prefix of an underscore ("_") so that when you are writing property code you are astute to what you are returning and setting to avoid stupid mistakes like this one.
Identifiers with a leading underscore are resevered for the compiler in C++. You don't do that.

You mean with TWO leading underscores. I agree, you don't do THAT. But one is OK.

christoofar · 2005-11-22 Reply Admin

ehabkost:
christoofar:
ammoQ:

public Foo Bar { set { try { process(value); moreProcess(value); evenMoreProcess(value); } catch { Bar = value.playSafe; // Recursion } } }

That gets close to violating the principle of least surprise. What do I mean by that? You usually don't expect an exception to be raised when you read a property... maybe when you set one, but not when just reading it.

Uh... did you read the code above? Where would the code above raise an exception on get?

Yes, I did. I didn't say it generated an exception, it's going to be a SURPRISE when you theoretically run it and it locks up your process. Get it, principle of least surprise?

webstranger · 2005-11-22 Reply Admin

haveworld:
Waiting for someone to comment on what's wrong with the code.

For non .NET folks (like myself :)<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

  set <o:p></o:p>

    {<o:p></o:p>

        LastName = value;<o:p></o:p>

    }<o:p></o:p>

on Java will look like:

<FONT size=2>  setLastName(value) <o:p></o:p></FONT>

<FONT size=2>    {<o:p></o:p></FONT>

<FONT size=2>        setLastName(value);<o:p></o:p></FONT>

<FONT size=2>    }<o:p></o:p></FONT>

Buggy.NET

Leave a comment on “Buggy.NET”