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

    God I HATE the m_ convention!  All my code uses the m convention (as in mLastName).  This is MUCH more efficient as I don't have to type the damned _ key with the {SHIFT} key every time! 

    I am JUST LIKE the genious at GM in the 80's that convinced the powers that be that it would save $X millions per year if they would just spell employee with ONE trailing "E".  (Employe)  Which... hard to believe, but still true, they did CORPORATE WIDE until the mid 90's.

    Strange, but true...

     

  • (cs) in reply to Grant
    Anonymous:
     

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

    class lastName {
    public:
       boolean operator=(lastName x) 
       {
          declareGlobalThermoNuclearWar();
          return true;
        }
    }


    A closely related, yet simpler C++ weirdness example:

    class LastName{} lastName(lastName);  // Completely undefined behavior
  • (cs) in reply to christoofar
    christoofar:
    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.




    One underscore followed by any alphanumeric character is also reserved for library writers (which brings up an interesting point that all variables starting with an underscore are illegal except the variable single-underscore '_')

    But it's irrelevant here since you are talking about member variables which are in their own class namespace and so are exempted from the restriction as clashes aren't going to happen.  Still, just to be safe, I've always seen this practiced as a trailing underscore, not a leading.
  • Anonymous coward (unregistered)
    Alex Papadimoulis:

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


    Not knowing C# makes this a real WTF- as in, WhyTF is this a WTF?

    [the captcha is 'unreal']
  • (cs) in reply to jvancil
    jvancil:
    Anonymous:
    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.

    God I HATE the m_ convention!  All my code uses the m convention (as in mLastName).  This is MUCH more efficient as I don't have to type the damned _ key with the {SHIFT} key every time! 

    I am JUST LIKE the genious at GM in the 80's that convinced the powers that be that it would save $X millions per year if they would just spell employee with ONE trailing "E".  (Employe)  Which... hard to believe, but still true, they did CORPORATE WIDE until the mid 90's.

    Strange, but true...

     



    K... I've done Delphi and VB and I tend to see a lot of f_ and m_.  Delphi programmers used it to denote a class's field I'm sure VB's m_ meant "module variable."  But, class fields should be easy to spot with just a simple _.

    The _ should make you think "aha this variable is really a field in my class with class-level scope."  So if you are writing something that is thread-safe, you would take care to protect those _ fields.
  • (cs) in reply to Anonymous coward
    Anonymous:
    Alex Papadimoulis:

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


    Look at the line that says LastName = value;

    Then, look harder.

    Not knowing C# makes this a real WTF- as in, WhyTF is this a WTF?

    [the captcha is 'unreal']
  • (cs) in reply to Anonymous coward
    Anonymous:
    Alex Papadimoulis:

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


    Not knowing C# makes this a real WTF- as in, WhyTF is this a WTF?

    [the captcha is 'unreal']


    Sorry, put my comments inside the quote tags.

    Look at LastName = value.  Do you see it?
  • (cs) in reply to christoofar
    christoofar:
    Anonymous:
    Alex Papadimoulis:

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



    Not knowing C# makes this a real WTF- as in, WhyTF is this a WTF?

    [the captcha is 'unreal']


    Sorry, put my comments inside the quote tags.

    Look at LastName = value.  Do you see it?

    I can't see it. Wait, I can't see anything! Oh god no I'm blind! Mom always said that doing that would make me go blind! Oh mom I'm so sorry! Er wait, I just had my eyes closed.

    Hasn't the exact nature of this WTF been explained in excruciating detail? Something tells me we just found the author of this code.

  • anonymous coward (unregistered) in reply to Jack

    you are incorrect.  MSDN doesn't specify anything for private variables.  protected variables should use camel casing, but you're free to name private variables however you like.

  • ByteJuggler (unregistered) 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>

    Actually no it isn't.  OK, let me try this as a question:   Why in the pleiades do people say that?  There is a huge difference between the pound symbol:  £    and the hash or sharp symbol:  #     They are not on the same key (different hands in fact, on my UK keyboard) and they don't remotely look alike.  So *why* do I keep seeing this "it is a C with the pound symbol etc. crap?   Is there character set mapping/mangling going on that's messing with peoples minds????

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

    Actually no it isn't.  OK, let me try this as a question:   Why in the pleiades do people say that?  There is a huge difference between the pound symbol:  £    and the hash or sharp symbol:  #     They are not on the same key (different hands in fact, on my UK keyboard) and they don't remotely look alike.  So *why* do I keep seeing this "it is a C with the pound symbol etc. crap?   Is there character set mapping/mangling going on that's messing with peoples minds????

    In America (where Microsoft resides and their products are primarily developed), we call the # symbol the pound symbol when referring to it on a phone keypad. And since all we ever care about is our own country, no one immediately associates pounds with UK currency. Besides, aren't you guys converted over to Euros yet?

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

    Actually no it isn't.  OK, let me try this as a question:   Why in the pleiades do people say that?  There is a huge difference between the pound symbol:  £    and the hash or sharp symbol:  #     They are not on the same key (different hands in fact, on my UK keyboard) and they don't remotely look alike.  So *why* do I keep seeing this "it is a C with the pound symbol etc. crap?   Is there character set mapping/mangling going on that's messing with peoples minds????



    Because Americans and Canadians in the early days reserved the £ to mean the "pound sign" or "number sign".  Perfectly fine to have two meanings for something between countries.  Happens in Spanish and Portuguese all the time (even sex tenses on verbs!)
  • (cs) in reply to christoofar

    Correction I mean the # sign.

  • ByteJuggler (unregistered) in reply to christoofar
    christoofar:
    Correction I mean the # sign.


    Yes I know # means number - but that's a mile from "pound" which is money???  <mutter mutter>  I still find it highly strange...
  • ByteJuggler (unregistered) in reply to ByteJuggler

    but OK, having looked at the wikipedia page, I see what you mean.  8-)

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


    WOW!  I only wanted that sig until someone noticed.  I thought for sure that it would take longer than 17 minutes!

    Sincerely,
      <er, no.  that's been done too.>

  • (cs)

    Haha, I've done this before. The best part is that in ASP.NET, when the stack overflows as it does in this situation, the stack trace is lost and you get no error location info with the error message.

  • (cs)

    I bet more than half the readers didn't catch the problem with the code

  • OverloadedOperator (unregistered) in reply to anonymous coward

    Fellas!

    The real WTF is not the camel casing or the protected vs public keywords. The real WTF is that the brilliant developer wrote bad code -- as in doesn't work and has unreachable variables.  To the clueless, get a clue. To everybody, focus on the fundamentals first.








  • (cs) in reply to BlackTigerX
    BlackTigerX:
    I bet more than half the readers didn't catch the problem with the code

    Yes, I have been programming in C# for 3 years and I still make that mistake once in a while. The problem isn't doing that mistake. The problem is thinking you are the best coder in the world and thinking that the problem is the language and not you, considering that this is a bug easy to find.


  • (cs) in reply to WTFer

    With the resharper plugin, it would hi-lite unused variables. If the variable were also private, then it would then tool-tip with a nice message saying that the variable never gets assigned.

  • qasr (unregistered) in reply to christoofar
    christoofar:
    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?

    I'm sure he gets it, but you didn't look closely enough. The OP only implemented a set property, not get. Your principle of least surprise is still a good point though.
  • Rody (unregistered) in reply to Wavey
    Anonymous:
    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.
     


    I don't consider it trite.  I consider it useful.  In fact, this is the _useful_ form of hungarian notation, as opposed to the (IMHO) much less useful lpszName type hungarian notation.
  • joe_bruin (unregistered) in reply to BlackTigerX
    BlackTigerX:
    I bet more than half the readers didn't catch the problem with the code


    I didn't catch it until it was explained in the first few posts.  Why?  Because I was not expecting a function call when the assignment operator is used.  How silly of me to expect an operator to perform the operation that it is supposed to do.  Seriously, what kind of fucktard designs a language where a primitive operator can implicitly be a function call that may do anything it feels like (including recursing infinitely or NOT SETTING THE VARIABLE)?  Yes, I'm looking at you, Bjarne Stroustrup.

    <font color="Red"> Something didn't quite work out ...
    - CAPTCHA Validation Incorrect </font>
  • Random832 (unregistered) 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.


    Incorrect. Only identifiers beginning with an underscore and either an uppercase letter or another underscore are reserved everywhere. Identifiers beginning with an underscore and a lowercase letter or a number are only reserved as symbols with external linkage. This does not include class members.

    (I'm talking about C, but this comes from C originally. replace "class members" with "struct members" - i don't think they're reserved as struct tags either, but it'd be reasonable for them to be reserved as class names in c++)
  • ByteJuggler (unregistered) in reply to joe_bruin
    Anonymous:
    BlackTigerX:
    I bet more than half the readers didn't catch the problem with the code


    I didn't catch it until it was explained in the first few posts.  Why?  Because I was not expecting a function call when the assignment operator is used.  How silly of me to expect an operator to perform the operation that it is supposed to do.  Seriously, what kind of fucktard designs a language where a primitive operator can implicitly be a function call that may do anything it feels like (including recursing infinitely or NOT SETTING THE VARIABLE)?  Yes, I'm looking at you, Bjarne Stroustrup.<font color="Red"></font>


    C# was not designed by Bjarne Stroustrup, but by Anders Hejlsberg.  As for complaining about property setters potentially recursing:  Get used to it, it's a trivial mistake thats trivially easy to spot, fix and avoid.  IMO property based syntax adds an effective extra layer of syntactic encapsulation, allowing you to (for example) swap a public data member with an encapsulated getter/setter in a way which other languages doesn't.  In this regard it is very very useful IMO and is a Good and Usefule Thing (tm) IMNSHO.    YMMV.

    (ffs, why does the CAPTCHA fail first time round??? does it time out or something???)
  • The other &quot;world's best coder&quot; - not. (unregistered)

    I cant believe no one has bitched about the fact that this doesn't do encapsulation well.  Why would you make your member variable protected? 

    It should really be

    private string lastName;

    not

    protected string lastName;

  • (cs) in reply to ByteJuggler

    Anonymous:
    Anonymous:
    BlackTigerX:
    I bet more than half the readers didn't catch the problem with the code


    I didn't catch it until it was explained in the first few posts.  Why?  Because I was not expecting a function call when the assignment operator is used.  How silly of me to expect an operator to perform the operation that it is supposed to do.  Seriously, what kind of fucktard designs a language where a primitive operator can implicitly be a function call that may do anything it feels like (including recursing infinitely or NOT SETTING THE VARIABLE)?  Yes, I'm looking at you, Bjarne Stroustrup.<FONT color=red></FONT>


    C# was not designed by Bjarne Stroustrup, but by Anders Hejlsberg.  As for complaining about property setters potentially recursing:  Get used to it, it's a trivial mistake thats trivially easy to spot, fix and avoid.  IMO property based syntax adds an effective extra layer of syntactic encapsulation, allowing you to (for example) swap a public data member with an encapsulated getter/setter in a way which other languages doesn't.  In this regard it is very very useful IMO and is a Good and Usefule Thing (tm) IMNSHO.    YMMV.

    (ffs, why does the CAPTCHA fail first time round??? does it time out or something???)

    The syntatic arsenic otherwise known as operator overloading has been around much longer than Hejlsberg's D-flat. The purple dinosaur also known as Bjarne seems to be responsible for at least the wide spread use if not actual invention of this perversion.

  • (cs)

    What a dumbass...

  • (cs) in reply to The other &quot;world's best coder&quot; - not.
    Anonymous:

    I cant believe no one has bitched about the fact that this doesn't do encapsulation well.  Why would you make your member variable protected? 

    It should really be

    private string lastName;

    not

    protected string lastName;



    Depends.  If you want subclasses to be able to access/override the member directly, then it should be protected.  If not, then private.
  • (cs)

    Yeah, you could have a naming convention to avoid this sort of problem. Or you could just make the data public (since it effectively is anyway), and have a policy like "no nulls across method boundaries" so that the conversion from null to "" isn't needed. (If you're in the habit of using the Null Object pattern, well, "" is the natural Null Object for strings, so you'd probably never have a problem or notice.) Or you could, you know, actually try to practice some form of encapsulation. Instead of testing out a spiffy new language feature intended to replace a pair of methods (without really reducing typing much anyway) which were lying by pretending to encapsulate stuff in the first place. Seriously. How often does anyone ever actually go back and add checks and balances to these kinds of methods?


    But. Supposing one wants to keep the insulation from change. Dare I propose a language where it worked like this:

    // current version
    read_write String lastName;
    private String foo; // by default, not readable or writeable outside; readable and writeable inside.
    
    // Obviously "protected" will need to be rethought, depending on how many 
    // levels/combinations of access control really ought to be provided.
    
    readonly String firstName; // clients can check the first name but not change it post construction.
    
    // later, when we decide that there is a need to add checks and balances
    read_write String lastName
    get { return lastName + ", which is a perfectly valid last name"; };
    // Now the get block overrides the default of just yielding the value;
    // but setting still does what it normally would.
    
    // Even later.
    read_write String lastName
    get { return lastName + ", which is a perfectly valid last name"; }
    set { if (value.contains('e')) {
        Log("we don't allow last names to contain e's around here");
        throw someException();
    } else { assign value.stripLeadingWhitespace(); } 
    // here assign is a keyword, not a function
    
    readonly String firstName set { Log("hi mom!"); } 
    // compile error; can't define set method for non-settable thing.
    

    But that's all just off the top of my head.

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


    No I mean one underscore. Read the C++ standard [17.4.3.1.12]: "Each name, that begins with an underscore is reserved to the implementation for use in the global namespace".
  • joni.Da::coder}| (unregistered) in reply to Axel

    lol, this is such a newb.

    I've been codin in C# for like 10 yrs and never done such dumbass thing lol. [H] net really sux cause it has so many bugs. Sun should have fixed them all already, I found them. rofl. This would never happen in ruby cause it's not that dumb. Googd languages dont' allow you to do dumb thingies. I don't like c# anymoore because of this crap.

  • Suomynona (unregistered) in reply to marvin_rabbit
    marvin_rabbit:
    Manni:
    marvin_rabbit:

    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!


    WOW!  I only wanted that sig until someone noticed.  I thought for sure that it would take longer than 17 minutes!

    Sincerely,
    <er ,="" no="" that's="" been="" done="" too="">


    Darn! For literally DAYS I've been wanting to use the following sig, but now the fun is already over!
    ___________________
    </er>This is a semi-automated signature. I copy and paste it from Manni's sig every time, then change most of the words.
  • Kukester (unregistered)

    Gah, I hate to agree with the guy, but thats what you are asking for when you can't tell a function from a property.

    Sure it is a nice shortcut, but I think a language should show you the difference between a simple variable set, which will run in constant (and short too!) time and a function call which could be... say a RMI method to another state!

    In any programmer's mind A = B; should not have any side effects beyond the value of A. It allows you, when debugging, to simplify things in your mind. Looking for a stack problem? X should not be suspect, F() is.

  • moo (unregistered) in reply to Gene Wirchenko

    What's wrong with the code: in the setter, LastName should have been lastName.

    Moreover, why would he put the null check in the getter?  Why not put it in the setter instead?  Don't getters tend to get called a lot more than setters?

  • (cs) in reply to Kukester
    Anonymous:
    In any programmer's mind A = B; should not have any side effects beyond the value of A. It allows you, when debugging, to simplify things in your mind. Looking for a stack problem? X should not be suspect, F() is.


    That is simply your preference.

    I like the potential for the internal representation to be different from the external representation.  I can see the need for calculations if the value of B is not kept handy but is computed as needed.

    Like any other programming language flexibility, this is subject to abuse, but that does not mean that using this is always abuse.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Gene Wirchenko

    here is a valid use of recursion in a property:

    
    class Graph
    {
    	private Graph parent;
    
    	public Graph Parent
    	{
    		get
    		{
    			return parent;
    		}
    	}
    
    	pulbic Graph GraphTop
    	{
    		get
    		{
    			if (Parent == null)
    				return this;
    			return parent.GraphTop;
    		}
    	}
    }
    
    
  • (cs) in reply to Kukester

    Anonymous:
    Gah, I hate to agree with the guy, but thats what you are asking for when you can't tell a function from a property.

    Sure it is a nice shortcut, but I think a language should show you the difference between a simple variable set, which will run in constant (and short too!) time and a function call which could be... say a RMI method to another state!

    In any programmer's mind A = B; should not have any side effects beyond the value of A. It allows you, when debugging, to simplify things in your mind. Looking for a stack problem? X should not be suspect, F() is.

    For those who hate properties, indexers, and overloading...
    http://www.geocities.com/csharpfaq/test2.html

    To be honest, I've grown kind of fond of properties and indexers - maybe i'm going soft in the head. I still loathe operator overloading.

  • (cs) in reply to joni.Da::coder}|
    Anonymous:

    lol, this is such a newb.

    I've been codin in C# for like 10 yrs and never done such dumbass thing lol. [H] net really sux cause it has so many bugs. Sun should have fixed them all already, I found them. rofl. This would never happen in ruby cause it's not that dumb. Googd languages dont' allow you to do dumb thingies. I don't like c# anymoore because of this crap.

    *cough* Troll. *cough*

    I like the idea of assignments automatically filtering through your property get/sets... to some extent.

    I use Python, where property's are strictly optional. Are they optional in C#?

     

  • (cs)

    public sealed class User
    {
        private string _lastName;
       
        public string LastName
        {
            get { return this._lastName == null ? string.Empty : this._lastName; }
            set { this.lastName = value; }
        }
    }

    unless a class is inheritable, i always as a rule seal the class. The compiler provides some optimisation for classes that are sealed and every ounce of optimisation will surely lead one day to a pound-ful of robust performance.

    I understand from a colleague of mine that the underscore is used within VB.NET and as such, the m
    however trite it may well be, is the better option

  • (cs) in reply to OneFactor
    OneFactor:

    Anonymous:
    Gah, I hate to agree with the guy, but thats what you are asking for when you can't tell a function from a property.

    Sure it is a nice shortcut, but I think a language should show you the difference between a simple variable set, which will run in constant (and short too!) time and a function call which could be... say a RMI method to another state!

    In any programmer's mind A = B; should not have any side effects beyond the value of A. It allows you, when debugging, to simplify things in your mind. Looking for a stack problem? X should not be suspect, F() is.

    For those who hate properties, indexers, and overloading...
    http://www.geocities.com/csharpfaq/test2.html

    To be honest, I've grown kind of fond of properties and indexers - maybe i'm going soft in the head. I still loathe operator overloading.


    Me too. Properties aren't too bad because with the use of casing you can diferentiate them, and I almost always use indexers for classes that implement ICollection so that doesn't bother me neither since I know what to expect from them. Plus the function tend to be simple and most complex thing I do is generating an on change event or validation in properties and indexers. However operator overloading and implicit conversion are just evil.(I haven't notice many of those used in the .net libraries by the way).
  • (cs) in reply to whojoedaddy
    whojoedaddy:
    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

     

    And who do you think you are, we ALL know its C-HASH. # == HASH. i like hash.

    chill man.

  • (cs) in reply to Cyresse
    Cyresse:
    I like the idea of assignments automatically filtering through your property get/sets... to some extent.

    I use Python, where property's are strictly optional. Are they optional in C#?

     

    Sadly, no, as I said C# properties don't create virtual members, they're completely independant from regular members and can't always be transparently switched with "real" members.

    Even less so because the C# coding guidelines ask you to CamelCase properties and methods and camelCase members (which clearly identify properties as properties)...

    In the end, C#'s properties are more or less equivalent to Java's getters/setters plague, just slightly less ugly.

    Another "issue" with C#'s properties is that you can define properties in an interface, but not regular members, and you can't switch between them (defining a member's signature in the interface and being able to implement either a real member or a virtual member via a property hasn't been deemed acceptable by the creators of C#)

  • Ed (unregistered)

    That's a textbook example of why Best Practices call for prefixing member variables with an underscore.  Still, it's a pretty common mistake.  It wouldn't surprise me to see the compiler generate warnings for these types of errors at some point in the future.

  • Darryl Bleau (unregistered) in reply to Ed

    <font style="font-family: Arial;" size="2">Yeah so the guy messed up a capital.. geeze leave him alone.

    But the real WTF for me is here:</font>

            return (lastName == null) ? "" : lastName; // <- ick, yuck, eww


    I admit I've not ever coded in any sort of M$-devired excuse for a language, but if this were C I'd choke.

  • Willie (unregistered) in reply to Darryl Bleau

    Nothing wrong with the ternary operator.

     

    Mdollarsign u r cl3v3r.

  • vhawk (unregistered)

    Stupid D-flat programming language - it actually does what the program was written to do ! Recurse till the stack falls over.  Tisk - tisk : the stupid compiler should have guessed what the clever C++ programmer wanted to do :D

  • (cs)

    The setter is clearly tail-recursive, so it should never overflow the Stack. Ok, so it will never halt either, but hey...

    The real WTF is that IL has a TailCall opcode, but it doesn't seem to get emitted by any of the compilers!

  • (cs) in reply to quamaretto

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

     

    props! [pi]

Leave a comment on “Buggy.NET”

Log In or post as a guest

Replying to comment #:

« Return to Article