Another reason why using properties that actually do something is bad...

I was debugging some code in a product we are dependant on and came across a property called GetNextValue. Yes - a property - not a method. The code looked something like this:

string key = s.GetNextValue;
string value = s.GetNextValue;

As  was debugging, it suddenly dawned on me just how bad this can be. True, at the end of the day this is just code, however, both code maintainers and people who just happen to debug can be struck by this - you basically do not expect the code to do anything else other than get a value. In this case, the property actually advances the iterator in "s" to the next value. This means that while debugging, if I was to hover with my mouse over the property, it would change the value of the property, changing the result of the debugging session ("Code can be either watched, or debugged, but not both" sort of thing) When faced with such code, your debugging looks much like walking a mine-field. You move your mouse AROUND the text that may change the behavior. Similarly, the "Auto" watch window, if visible, can also change everything one each debugging step (and of course if you manually added the property to the Watch window)

All in all, this is a perfect example how something that is "bad form" happens to also drag after it much worse effects.

Comments

• Anonymous
  May 03, 2006
  Guilty as charged..
  
  I thought it would be cool to have "object tree" presentation of a server content exposed as a property. So when debugging, going over the + will sometimes work and get the list of stuff from remote server and sometimes it will not.. Who knows how that can mess up things randomly.