The Daily WTF: Curious Perversions in Information Technology

2011-05-18 Reply Admin

jnewton:
The WTF is that write only accessors are effectively just functions. This should be written as follows:
public void MakeReadOnly(){ organizationName.Visible = false; organizationNameRead.Visible = true; }

Why is that a WTF? Setters do the same thing... It's a convenient behvior that makes working with properties much easier and intuitive.

2011-05-18 Reply Admin

frits:
C-Octothorpe:
Also, the setting of properties only exists to cause side effects.
FTFY

You're conflating local side effects (changing state, the reason Cocktothorpe mentioned) with global side effects (I/O and such).

2011-05-18 Reply Admin

C-Octothorpe:
Sorry, I didn't mean it that it shouldn't have ANY side effects. I should have been more explicit, and I realized after I submitted my post.
I'm talking more about something like this:
public bool IsSetup
{
  set 
  { 
    // Do a whole bunch of stuff like send an email, delete
    //  some records, activate the flux-capacitor, etc.
    // Oh, and this...

    _isSetup = value;
  }
}
Sorry, I've seen stuff like this and it makes me cringe. Also a property is just that, a property and a method is a verb, a unit of work. IAmCool = false vs. MakeMeCool(bool makeCool).
I hope that makes more sense then the aspergers induced crap that I wrote before.

Unless the business logic dictates that those actions should occur when the property is set. That's the point of properties; doing things that are related to the property at the time the value is set without the calling code having to worry about the implementation.

2011-05-18 Reply Admin

migala:
C-Octothorpe:
Also, setting a property should not cause side effects

So setting the ".visible" property on a control should not cause the control to be shown or hidden?

The perfect example of how this could fail was good old IE 5. You could move an object by updating its .x and .y properties. The obvious problem there is that if you update .x and then .y, it should perform two motions. IE being IE, there was some internal kludge to get around this, but the model is fundamentally flawed. Generally, with any kind of GUI library, I want the GUI to appear all at once, properly, not slowly updating itself each time I change a setting.

It doesn't make sense with transactions. If setting a property involves updating a DBMS, it will start a transaction, update the DBMS, and commit the transaction. Then I set the next property and it starts its own transaction. Now if there's an error, only one is rolled back. And, sure, you could manually wrap them in a transaction, but at that point why bother with the side effects?

2011-05-18 Reply Admin

Vaca Loca:
Unless the business logic dictates that those actions should occur when the property is set. That's the point of properties; doing things that are related to the property at the time the value is set without the calling code having to worry about the implementation.

Agreed, however I'm speaking to the misuse (and likely misunderstanding) of what properties are and what they are used for. Generally you won't see too many places where a getter or setter cause side effects outside of the containing class. For example, in the SqlCommand object, you wouldn't expect setting the Text property to call ExecuteNonQuery, right?

You set the property state, then call a method to act on the object's state. Take for example ASP.NET Control. If you disassemble it you'll notice the it doesn't set itself to visible right then and there, obviously. And do you know why? Because on Render, the inheriting control will know what to do with Visible = false/true. So you set it's state to Visible=false, then on render that state is acted upon.

dogbrags · 2011-05-18 Reply Admin

A property holds a portion of the state of an object. Pure and simple. If setting a property causes an email to be sent, data written to the database, etc., that is not object state and so should not be part of the code of the property setter.

I might be convinced (on a case-by-case basis) that the property setter can call a method which does these things. I'd rather see a method that does these things and updates the property as well.

jnewton · 2011-05-18 Reply Admin

C-Octothorpe:
jnewton:
The WTF is that write only accessors are effectively just functions. This should be written as follows:
public void MakeReadOnly(){ organizationName.Visible = false; organizationNameRead.Visible = true; }

Why is that a WTF? Setters do the same thing... It's a convenient behvior that makes working with properties much easier and intuitive.

Since there was no getter and no way to reverse setting the values to read only, having this be a property instead of a function is confusing.

Addendum (2011-05-18 13:09):

C-Octothorpe:
jnewton:
The WTF is that write only accessors are effectively just functions. This should be written as follows:
public void MakeReadOnly(){ organizationName.Visible = false; organizationNameRead.Visible = true; }

Why is that a WTF? Setters do the same thing... It's a convenient behvior that makes working with properties much easier and intuitive.

Since there was no getter and no way to reverse setting the values to read only, having this be a property instead of a function is confusing. Additionally, it does the same thing regardless of what value you set the "Property" to.

2011-05-18 Reply Admin

jnewton:
Since there was no getter and no way to reverse setting the values to read only, having this be a property instead of a function is confusing. Additionally, it does the same thing regardless of what value you set the "Property" to.

I agree, but you stated that TRWTF is "write only accessors are effectively just functions". I was asking why that was a WTF...

jnewton · 2011-05-18 Reply Admin

C-Octothorpe:
jnewton:
Since there was no getter and no way to reverse setting the values to read only, having this be a property instead of a function is confusing. Additionally, it does the same thing regardless of what value you set the "Property" to.

I agree, but you stated that TRWTF is "write only accessors are effectively just functions". I was asking why that was a WTF...

Indeed, so restating... TRWTF is write-only accessors.

2011-05-18 Reply Admin

jnewton:
The WTF is that write only accessors are effectively just functionsprocedures. This should be written as follows:
public void MakeReadOnly(){
        organizationName.Visible = false;
        organizationNameRead.Visible = true;
}

FTFY

2011-05-18 Reply Admin

Dorus:
I don't even see the WTF.

Duh, it's invisible.

2011-05-18 Reply Admin

Functional ProGrammar Nazi:
jnewton:
The WTF is that write only accessors are effectively just functionsprocedures methods. This should be written as follows:
public void MakeReadOnly(){
        organizationName.Visible = false;
        organizationNameRead.Visible = true;
}
FTFY

FTFY

2011-05-18 Reply Admin

yawn

damn you akismet

daily · 2011-05-18 Reply Admin

He should just RTFM (RTF Manuel)

2011-05-18 Reply Admin

Not arguing for the "rightness" of this solution in any way, but in a Windows Forms app the driving force behind this could likely be that the desire for the read-only version to use the default appearance of a label and for the read/write version to use the default appearance of a textbox. I have seen code similar to this when .NET newbies didn't know the various appearance properties well enough to make this transition through code.

Captcha: wisi Coding in anything but binary is wisi

2011-05-18 Reply Admin

Anonymous:
Visible/Enabled confusion: Using two controls (one editable, one non-editable) and managing them via their "Visible" property, instead of using a single control and managing its read-only state with the "Enabled" property.
Sensible solution? No comment.

If you want the read-only text to look different than the editable text, this is a reasonable way to do it. As someone else said, you have the label placed on top of the text box and just make visible whichever one you need at the time.

The rest of the code is silly, but not really bad enough to be a WTF, just a "shake your head and move on" level.

2011-05-18 Reply Admin

frits:
Reading this literally me say WTF?

Don't let's start that again.

I literally had too much of it yesterday

2011-05-18 Reply Admin

Joe:
Ah, now I "see" it.
The GUI has 2 controls laid exactly on top of each other. An editable box (organizationName) and an un-editable box (organizationNameRead)

So to make it read-only, you hide the one that's editable.

Just hope that they never both get visible at the same time, and that nobody ever moves one of them.

--Joe

Not justifying the code, but...

Couldn't help but wonder whether one was a label (organizationNameRead), and one was a textbox (organizationName).
A textbox looks greyed out if you set Enabled to false (I assume you can change this, but I've never tried), so putting a label over the top may not be the stupidest idea in the world to make the Company name still look active without being active....

Of course, without context a lot of things are difficult (I don't really know why we'd need an editable company name anyways, but there may be a good reason)

2011-05-18 Reply Admin

frits:
Dotan Cohen:
TPG:
After a couple of digging through the sloppy editing, I have come to the conclusion that you accidentally some of the article.

You me to it!

Was this too subtle?

Duh....the title gives it away.... Some of the article is INVISIBLE!!!

2011-05-18 Reply Admin

daily:
He should just RTFM (RTF Manuel)

I better get another coffee....and a new monitor!

2011-05-18 Reply Admin

TRWTF is setters and getters. Who needs them when you get access to the class members?

Llort.setID("WTF");

Versus

Llort.ID = "WTF";

It's obvious which is better.

2011-05-18 Reply Admin

Pr0gramm3r:
TRWTF is setters and getters. Who needs them when you get access to the class members?
Llort.setID("WTF");
Versus
Llort.ID = "WTF";
It's obvious which is better.

Nearly had me....

2011-05-18 Reply Admin

I love it when bunches of "developers" decide whether or not an ambigous hunk of code is a WTF without seeing its use case. It's almost like they imagine they understand all possible situations, and they've never chosen a strange construct on purpose.

Bonus: if you complain about a setter being used too much like a method, I'm not even going to stoop to insult you. You'd probably miss it, anyway. But just in case you feel like taking it personal, please feel free to do so.

hatterson · 2011-05-18 Reply Admin

I wonder if the original dev team literally evaporated...

2011-05-18 Reply Admin

I'm sure you're trolling but anyway.
There is no use case that would ever justify this ever.

Elsewhere in the code you see this: NameReadonly = false;

or NameReadOnly = readonlyCondition;

or If(readonlyCondition) NameReadOnly = true; else NameReadOnly = false;

They all look reasonable, but they don't work. There are other solutions that are functionally identical and have no potential to be confusing, therefore this 'solution' is strictly worse in every possible way.

I'm a little surprised that nobody mention the TextBox.Readonly property.

2011-05-19 Reply Admin

Consultants are the excuse the internal development management use so that they don't get fired.

Before a project fails, hire consultants to take the blame, get promoted before the failure is visible, rinse and repeat.

I can't complain: being used as an excuse for a failed project is part of the service I offer as an external consultant. It's one of the things I get paid for.

2011-05-19 Reply Admin

JD:
I'm a little surprised that nobody mention the TextBox.Readonly property.

That was my first thought but we don't actually know that it's a TextBox control - it's a fair assumption but there's no guarantee, so it may not even have a ReadOnly property. However, it will have an "Enabled" property as long as it's derived from Control, so that should be a safe fallback for making the control non-editable even if it doesn't derive from TextBoxBase (which is the base class that exposes the "ReadOnly" property).

2011-05-19 Reply Admin

Silfax:
Joe:
remi bourgarel:
ok I see ! There is a bug ! If by default the field is not readonly, then there is a only "maybe" a bug.

Cheater! You changed the outcome by observing it!

--Joe

How did he observe it if it wasn't visible?

Um... code smell?

2011-05-19 Reply Admin

TechNeilogy:
The problem with rats leaving a sinking ship is that they usually do it by gnawing holes in the bottom.

If you have a hole in the bottom of your ship letting in water, you need a another hole to let it drain out again.

2011-05-19 Reply Admin

Another one I just don't get. I prefer the ones with the pictures.

2011-05-19 Reply Admin

sibyl:
Article is very interesting,thanks for your sharing. I will necessarily add it in the selected works and I will visit this site. http://www.iweddingdressshop.co.uk/

Oh dear ... I can feel another meme coming on.

Watson · 2011-05-20 Reply Admin

sibyl:
Article is very interesting,thanks for your sharing. I will necessarily add it in the selected works and I will visit this site. http://www.iweddingdressshop.co.uk/

Sorry; I already have a place I get my bridalwear from: http://yvettesbridalformal.com/index.htm

2011-05-20 Reply Admin

I really don't get why the code here is worthy of a WTF. They are simply hiding the edit box and showing the read only control. I think the major thing wrong here is poor naming.

2011-05-22 Reply Admin

You've all made the incorrect assumption that the fields are both on the same page...

Invisible Developers?

Leave a comment on “Invisible Developers?”