• (cs)

    FristComment.Read = false;

    {I had to do it!}

  • Alex (unregistered)

    Frist = false

  • (cs)

    Reading this literally me say WTF?

  • Joe (unregistered)

    Is this some sort of introspective class? Where access to the getter/setter functions is controlled by bools in the structure itself?

    Not a bad idea to have an object enforce its readonly status by if(!field_readonly) in its setter, and if (field_visible) in its getter.

    It might even be a design pattern. Not necessarily a good one, but a pattern none the less.

    --Joe

  • Very bright, striking, distinctive (unregistered)

    Did Paula work for this team?

  • Corey (unregistered) in reply to Joe
    Joe:
    Is this some sort of introspective class? Where access to the getter/setter functions is controlled by bools in the structure itself?

    Not a bad idea to have an object enforce its readonly status by if(!field_readonly) in its setter, and if (field_visible) in its getter.

    It might even be a design pattern. Not necessarily a good one, but a pattern none the less.

    --Joe

    So I think the problem is that NameReadOnly = false still makes the name read only. I can only imagine that their is a NameNotReadOnly setter somewhere...

  • Joe (unregistered) in reply to 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

  • doctor_of_common_sense (unregistered) in reply to Very bright, striking, distinctive
    Very bright:
    Did Paula work for this team?
    No. she was just an intern there.
  • (cs) in reply to Joe
    Joe:
    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.

    Well, yeah, so much was clear, but why return a bool then?

  • Anonymous (unregistered)

    Classic property abuse with a bonus side-order of Visible/Enabled confusion. Not exactly a world-ending WTF but it always makes me cringe to see developers making such elementary errors.

  • Anon (unregistered)

    Could have been worse. It could have been LabVIEW.

  • NotVeryAnon (unregistered) in reply to Anonymous

    Please enlighten me. Why is this "abuse"? What do you mean by Visible/Enabled confusion? I can imagine this being an ASP.NET page for example, and the developers are hiding (say) a textbox and making visible a div/span with plain text. To me that seems like a pretty sensible solution.

  • Qvazar (unregistered)

    Translating this to Java for those not familiar with C# property syntax:

    public void setNameReadOnly(bool nameReadOnly) { organizationName.setVisible(false); organizationNameRead.setVisible(true); }

    So it's a property setter that is not a property setter.. and there's no getNameReadOnly() method.

  • (cs) in reply to ParkinT
    ParkinT:
    {I had to do it!}
    No, you had *not* to.
  • pelrun (unregistered)

    I worked on a product that had a web-based front-end; we did exactly this for enabling/disabling fields. That said, it was the easiest way to get the page working consistently across all the browsers we had to support.

  • remi bourgarel (unregistered)

    Every time I see someone saying "there is no WTF" I'm thinking "this guy either has no humor or is a bad developer" , but here come on ! At worst it's a bad practice, but I would do it myself without any remorse !

  • TPG (unregistered)

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

  • Dorus (unregistered) in reply to Qvazar

    I don't even see the WTF. Ok, granted, they should have used

    public bool NameReadOnly { set { organizationName.Visible = !value; organizationNameRead.Visible = value; } }

    Assuming the difference between organizationName and organizationNameRead is bigger then just organizationName.ReadOnly, this might actually be a half sane solution.

  • remi bourgarel (unregistered)

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

  • Joe (unregistered) in reply to remi bourgarel
    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

  • Dotan Cohen (unregistered) in reply to TPG
    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!

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

  • C-Octothorpe (unregistered) in reply to Severity One
    Severity One:
    Joe:
    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.

    Well, yeah, so much was clear, but why return a bool then?

    It doesn't return anything. It only has a set method.

  • C-Octothorpe (unregistered)

    Christ on a bike, do we ever have a metric ass ton of WTF apologists. No, it's not a good idea, not even maybe. Given no context I can still guarantee that this is a bad idea. No, this was a junior dev who had a poor grasp of which constructs/patterns to use where and when.

    Also, setting a property should not cause side effects (I'm assuming though, that the developer intentionally didn't use "value" and is using a property setter as a method instead).

  • TechNeilogy (unregistered)

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

  • Anonymous (unregistered) in reply to NotVeryAnon
    NotVeryAnon:
    Please enlighten me. Why is this "abuse"? What do you mean by Visible/Enabled confusion? I can imagine this being an ASP.NET page for example, and the developers are hiding (say) a textbox and making visible a div/span with plain text. To me that seems like a pretty sensible solution.
    Property abuse: using a property as if it were a method and completely ignoring the passed in setter value.

    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.

  • Andrew (unregistered)

    So... the WTF is that thingy.NameReadOnly = true; and thingy.NameReadOnly = false; both either make name read-only or both make name read-write, but who knows which?

  • (cs) in reply to TechNeilogy
    TechNeilogy:
    The problem with rats leaving a sinking ship is that they usually do it by gnawing holes in the bottom.
    Blue please.
  • C-Octothorpe (unregistered) in reply to Andrew
    Andrew:
    So... the WTF is that thingy.NameReadOnly = true; and thingy.NameReadOnly = false; both either make name read-only or both make name read-write, but who knows which?

    No, it's the fact that they used a property setter as a method. It gets the job done but is confusing as hell for anybody else who has to trudge through that "code".

  • Machtyn (unregistered)

    I'm assuming that organizationNameRead is exactly the same control as organizationName with the exception of the ReadOnly property being set differently. Both controls sit on top of each other in the application's form.

    At least, that's how I read it, this being The (somewhat) Daily WTF.

    The code could likely be (and remove the other control):

    public bool NameReadOnly { set { organizationName.ReadOnly = value; } }

  • (cs)

    Our company pride on completion of all project undertaken.

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

    Yeah, what to the verbs?

  • Mania (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    Also, setting a property should not cause side effects (I'm assuming though, that the developer intentionally didn't use "value" and is using a property setter as a method instead).

    Say what? Whilst I agree the codes a particularly horrendous wtf, both in not using value at all and in being a set only property... The fact that the property setter has side effects is not one of them. That's pretty much the whole point of property setters, just look at the standard uses - enabled, visible, text, font etc - without side effects, what purpose would these have?

  • Anonymous (unregistered) in reply to Nagesh
    Nagesh:
    Our company pride on completion of all project undertaken.
    Is that your way of saying that you wrote this code?
  • (cs) in reply to Anonymous
    Anonymous:
    Nagesh:
    Our company pride on completion of all project undertaken.
    Is that your way of saying that you wrote this code?
    I think Nagesh is saying that his company wouldn't have quit there. They would have written a lot more code just like this until the project was really finished.
  • (cs) in reply to Nagesh
    Nagesh:
    Our company pride on completion of all project undertaken.
    Who cares?
  • (cs) in reply to Joe
    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?

  • airdrik (unregistered) in reply to Mania
    Mania:
    C-Octothorpe:
    Also, setting a property should not cause side effects (I'm assuming though, that the developer intentionally didn't use "value" and is using a property setter as a method instead).

    Say what? Whilst I agree the codes a particularly horrendous wtf, both in not using value at all and in being a set only property... The fact that the property setter has side effects is not one of them. That's pretty much the whole point of property setters, just look at the standard uses - enabled, visible, text, font etc - without side effects, what purpose would these have?

    That's kind of what I was thinking, why have a property with (getters and) setters if it never has side effects? What is the real advantage of a property which gets/sets a "hidden" field over just making the field public (similarly the getter/setter method (anti)pattern in java)? If you want the field read-only make it so (final in java). I'm not sure why one would want to make a property write-only and not expect there to be side effects from setting it (if at the very least it changes the behavior of the containing object).

    I will concede, however, that they should either have used "value" so that obj.NameReadOnly = false undoes whatever obj.NameReadOnly = true does, or used a real method instead.

  • (cs)
    ...the entire dev team that started the project over a year before had suddenly evaporated...
    That's what happens when you hire liquids to write your code for you.
  • (cs)

    Yeah, people do all kinds of crazy stuff when you have mutable fields.

  • (cs) in reply to Anonymous
    Anonymous:
    Nagesh:
    Our company pride on completion of all project undertaken.
    Is that your way of saying that you wrote this code?

    Not so. I am saying that with our company we would never go dessert ship like sinking rats.

  • (cs) in reply to Anonymous
    Anonymous:
    Classic property abuse with a bonus side-order of Visible/Enabled confusion. Not exactly a world-ending WTF but it always makes me cringe to see developers making such elementary errors.

    Well yeah... It's a big WTF. If it's written for C#, this isn't a "read only" property. You have a setter that ignores the value... so somewhere in the code we must have this:

    NameReadOnly = false;

    But that doesn't really do anything... but you have to call it, or the states of the controls will be default, which may be unknown... I'm confused...

  • (cs)

    This is the codebehind for a .net webform. The idea is that 1) the user does something to cause a postback (click a button, for example) 2) the code looks at things like form values, etc; and determines that a value (organizationName) should no lcnger be editable; but that the organizationName's value should be displayed as text.

    One way to do this is to set the Visible propery of the two webform controls involved at that point in the code. Another way to do it would be to call a method to set the Visible propery.

    Another way to think of this, though, is that the form itself is an object; and that object has state. The state would be represented by properties; one of the properties is that the organizationName is editable, or is not editable.

    In that sense, a property has a legitimate reason for setting the Visible property of these form controls.

    [Of course, you'd actually want to code the property's code correctly, to turn the visibility on or off.]

  • Jim Barrows (unregistered) in reply to Silfax

    To not observe is still to observe, thereby changing the outcome.

  • migala (unregistered) in reply to C-Octothorpe
    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?

  • (cs) in reply to Nagesh
    Nagesh:
    Anonymous:
    Nagesh:
    Our company pride on completion of all project undertaken.
    Is that your way of saying that you wrote this code?

    Not so. I am saying that with our company we would never go dessert ship like sinking rats.

    Mmmm... dessert ship. Much tastier than biscuit ship.

  • (cs) in reply to C-Octothorpe
    C-Octothorpe:
    Also, the setting of properties only exists to cause side effects.
    FTFY
  • C-Octothorpe (unregistered) in reply to airdrik
    airdrik:
    Mania:
    C-Octothorpe:
    Also, setting a property should not cause side effects (I'm assuming though, that the developer intentionally didn't use "value" and is using a property setter as a method instead).

    Say what? Whilst I agree the codes a particularly horrendous wtf, both in not using value at all and in being a set only property... The fact that the property setter has side effects is not one of them. That's pretty much the whole point of property setters, just look at the standard uses - enabled, visible, text, font etc - without side effects, what purpose would these have?

    That's kind of what I was thinking, why have a property with (getters and) setters if it never has side effects? What is the real advantage of a property which gets/sets a "hidden" field over just making the field public (similarly the getter/setter method (anti)pattern in java)? If you want the field read-only make it so (final in java). I'm not sure why one would want to make a property write-only and not expect there to be side effects from setting it (if at the very least it changes the behavior of the containing object).

    I will concede, however, that they should either have used "value" so that obj.NameReadOnly = false undoes whatever obj.NameReadOnly = true does, or used a real method instead.

    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.

  • C-Octothorpe (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    ...blah blah blah...
    Wow, I'm tired today. Going into read-only mode for the rest of the day...
  • (cs)

    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; }

Leave a comment on “Invisible Developers?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article