• (cs)
    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

  • Damn Limeys (unregistered)

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

    USA! USA! USA!

  • (cs)

    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.

  • (cs) in reply to Damn Limeys

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

    </sarcasm>

  • (cs)

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

    .jc

  • Hans Hammer (unregistered)

    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)

  • toxik (unregistered) in reply to Manni
    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?...
  • (cs)

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

  • (cs) in reply to toxik

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

  • (cs) in reply to toxik
    Anonymous:


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



    No, its not.
  • (cs) in reply to haveworld
    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.
  • Oliver (unregistered) in reply to toxik

    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.

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

    HOW FUNNY!!!

    OMG I couldn't stop giggling.

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

  • Wavey (unregistered) in reply to haveworld 
    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.
     

  • Josh (unregistered) in reply to haveworld

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

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

  • (cs)
    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."

  • Willie (unregistered)

    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?

  • DavidBarrett (unregistered)

    <font size="3">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...
    </font>

  • (cs) in reply to Josh
    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.
  • creaothceann (unregistered) in reply to Willie
    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?
  • Oliver (unregistered) in reply to Willie

    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.

  • (cs) in reply to frosty

    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>

  • Jack (unregistered) in reply to christoofar

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

    <FONT face=Arial size=2><FONT title=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp face="Times New Roman" size=3>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp</FONT></FONT>

    <FONT face=Arial size=2><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT> 

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

  • Anonymous Coward (unregistered) in reply to Oliver
    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).
  • (cs)

    common sense is not for everyone

  • (cs) in reply to marvin_rabbit
    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!

  • (cs) in reply to Jack

    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?

  • (cs)

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

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

    <font face="Arial" size="2"><font title="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp" face="Times New Roman" size="3">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp</font></font>

    <font face="Arial" size="2"><o:p></o:p></font> 



    That's somewhat old.  I prefer the Philips guide plus some enhancements I have made. 
  • (cs) in reply to Willie
    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
         }
       }
    }
  • (cs) in reply to Josh
    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.
  • (cs) in reply to Oliver
    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.
  • (cs) in reply to ammoQ
    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.
  • Grant (unregistered) in reply to Josh

    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;
     }
 }
  • (cs) in reply to Sean
    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.

  • (cs) in reply to christoofar
    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?
  • (cs) in reply to christoofar
    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.
  • Axel (unregistered) in reply to christoofar
    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.
  • (cs) in reply to Josh
    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)

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

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

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


  • (cs) in reply to ehabkost
    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?
  • (cs) in reply to haveworld

    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>

Leave a comment on “Buggy.NET”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article