Submitted (almost) without comment



  • [code language="C#"]
    if (Session["EditWorkorderSubmissionToken"] != null)
    {
        Session["EditWorkorderSubmissionToken"] = null;
    
        workorderForm.Save();
    
        this.UserProfile.RestoreProfileDataFromCache();
    
        if (ViewState["ReturnUrl"] != null)
            Response.Redirect((string)ViewState["ReturnUrl"]);
    }
    else
    {
        this.UserProfile.RestoreProfileDataFromCache();
    
        if (ViewState["ReturnUrl"] != null)
            Response.Redirect((string)ViewState["ReturnUrl"]);
    }
    [/code]
    


  • Other than MAYBE using SessionState, I'm not really seeing the WTF.



  •  Duplicated code in the unnecessary "else", I'm guessing...  Not the worst coding foul ever.



  • @Nook Schreier said:

     Duplicated code in the unnecessary "else", I'm guessing...  Not the worst coding foul ever.

    Not the worst, no, but still irritating. It's more an indication of the overall level of skill and attention applied to this code.



  • @corgimonster said:

    @Nook Schreier said:

     Duplicated code in the unnecessary "else", I'm guessing...  Not the worst coding foul ever.

    Not the worst, no, but still irritating. It's more an indication of the overall level of skill and attention applied to this code.

    That's nothing. I run into stuff like this all the time where I work: [code]$foo = $foo? $foo: false[/code]



  •  @this_code_sucks said:

    I'm not really seeing the WTF.

    The entire if construction is a NOOP.



  • @dhromed said:

     @this_code_sucks said:

    I'm not really seeing the WTF.

    The entire if construction is a NOOP.

    Not entirely: the [code]workorderForm.Save();[/code] thing doesn't always happen.



  • @dhromed said:

     @this_code_sucks said:

    I'm not really seeing the WTF.

    The entire if construction is a NOOP.

    Not entirely. You still need:

    <font face="Lucida Console" size="2">if (Session["EditWorkorderSubmissionToken"] != null)
    {
        Session["EditWorkorderSubmissionToken"] = null;
        workorderForm.Save();
    }
    </font>

     

    Edit: Ah, ninja'd by toon. That ought to teach me not to switch tabs before replying. Or to refresh them when I come back.



  • @toon said:

    Not entirely: the <font face="Lucida Console" size="2">workorderForm.Save();</font> thing doesn't always happen.
     

    You are right and I am wrong.



  • @toon said:

    That's nothing. I run into stuff like this all the time where I work: <font face="Lucida Console" size="2">$foo = $foo? $foo: false</font>

    I'm not sure I see the problem. If you want $foo to be explicitly false when it has a false-like value, this is the way to go.


  • Discourse touched me in a no-no place

    @morbiuswilters said:

    @toon said:
    That's nothing. I run into stuff like this all the time where I work: <FONT size=2 face="Lucida Console">$foo = $foo? $foo: false</FONT>
    I'm not sure I see the problem. If you want $foo to be explicitly false when it has a false-like value, this is the way to go.
    Is there any (reasonable!) context where '$foo needs to be explicitly false' is different from '$foo having a false-like value?'



  • @PJH said:

    @morbiuswilters said:
    @toon said:
    That's nothing. I run into stuff like this all the time where I work: <font size="2" face="Lucida Console">$foo = $foo? $foo: false</font>
    I'm not sure I see the problem. If you want $foo to be explicitly false when it has a false-like value, this is the way to go.
    Is there any (reasonable!) context where '$foo needs to be explicitly false' is different from '$foo having a false-like value?'

    Something like marshaling data into JSON--you don't want your Javascript to have to check your JSON objects to see if the value is false or empty string or [ ]. Or an API you want to return an explicit false instead of a null or empty string or empty array--usually I try to return well-formed data from any functions I write. I don't like to return multiple values that mean the same thing; it seems sloppy.

    Without more context, I don't know if toon's example is really a WTF or not, although he seems like a stand-up guy so I'll give him the benefit of the doubt and assume his coworkers aren't trying to use an explicit false. I'm just pointing out that that can be a valid pattern.



  • @morbiuswilters said:

    @PJH said:
    @morbiuswilters said:
    @toon said:
    That's nothing. I run into stuff like this all the time where I work: <font size="2" face="Lucida Console">$foo = $foo? $foo: false</font>
    I'm not sure I see the problem. If you want $foo to be explicitly false when it has a false-like value, this is the way to go.
    Is there any (reasonable!) context where '$foo needs to be explicitly false' is different from '$foo having a false-like value?'

    Something like marshaling data into JSON--you don't want your Javascript to have to check your JSON objects to see if the value is false or empty string or [ ]. Or an API you want to return an explicit false instead of a null or empty string or empty array--usually I try to return well-formed data from any functions I write. I don't like to return multiple values that mean the same thing; it seems sloppy.

    Without more context, I don't know if toon's example is really a WTF or not, although he seems like a stand-up guy so I'll give him the benefit of the doubt and assume his coworkers aren't trying to use an explicit false. I'm just pointing out that that can be a valid pattern.

    I ran into that one last week. It definitely wasn't intentional. In PHP, as many of you may know, several things can be "falsy" like the empty string, NULL, etc., but in some instances much less exotic than mentioned above, the difference matters (the strpos() function is a good example). So I suppose morbs has a good point. The [code]$foo[/code] was some associative jagged array, so [code]$foo[$bar]['baz'] = $foo[$bar]['baz']? $foo[$bar]['baz']: false[/code] would have been nearer the mark. So I guess it's the sort of line that got written, then after a few weeks it turns out that [code]$foo[$bar][$baz][/code] should really be [code]$foo[$bar]['baz'][/code], instead. Suddenly there are three instances of the same variable in one line, it's Friday afternoon and the guy simply didn't notice. So a huge WTF, I guess it's not.

    I do tend to run into stuff like this, though, and it always seems to be the same dude. He's better at doing business than he is at programming. I can guess it's him pretty well, because at the moment we're a three programmer shop so I have a good idea of who wrote what. I sort of feel bad posting WTF's, so I only do it when I really can't resist any longer. To be fair: it's a nice place to work. I don't think I'll be there another ten years, but it's my first professional programming gig, and being someone with no diploma or degree to speak of, I could do much worse. They're not rich so I'm not exactly brushing my teeth with Dom Perignon every morning, but I'm having a lot of fun and still learning a lot.



  • @toon said:

    He's better at doing business than he is at programming.

    That observation fills me with hope: if you can demonstrate that his efforts - well-intentioned that they are - aren't as profitable for the organisation as they could be and that perhaps him moving into areas where he excels and away from areas where he's lacking can only benefit everyone in the longer term.

    I've had discussions with people who have up-front admitted they're shite at coding and don't like it too much (mainly because they're new to it) but have become fair testers and pretty good at requirements-gathering. These people are much more valuable than those who are shite at coding but can't see it, won't admit it, won't change to something different nor are willing to change their ways.



  •  ^


Log in to reply