Useless code...



  • I saw this in this project I'm working on and it kind of made me laugh

    if (someObject != null ) {
      return someObject; 
    } 
    return null; 
    

    Sadly this is a recurring theme in the code.



  •  You say useless, I say bulletproof.



  • @rozner said:

    I saw this in this project I'm working on and it kind of made me laugh

    if (someObject != null ) {
      return someObject; 
    } 
    return null; 
    

    Sadly this is a recurring theme in the code.

    Well, similar patterns are useful for being able to establish breakpoints (although most debuggers now support powerful data driven breakpoints i find less than 2% of developers atually know how to use them) .



  • @TheCPUWizard said:

    Well, similar patterns are useful for being able to establish breakpoints (although most debuggers now support powerful data driven breakpoints i find less than 2% of developers atually know how to use them) .

    That's because the documentation for IDEs and debuggers lags far behind the feature set (glares at XCode4).



  • @TheCPUWizard said:

    Well, similar patterns are useful for being able to establish breakpoints (although most debuggers now support powerful data driven breakpoints i find less than 2% of developers atually know how to use them) .


    And sometimes even when you know how to use them, they slow things down soooooooooo much that you'd rather use a poor man's breakpoint than the proper conditional one.



  • @lrucker said:

    @TheCPUWizard said:

    Well, similar patterns are useful for being able to establish breakpoints (although most debuggers now support powerful data driven breakpoints i find less than 2% of developers atually know how to use them) .

    That's because the documentation for IDEs and debuggers lags far behind the feature set (glares at XCode4).

     True, but how many RTFM anywhy???

    @pjt33 said:

    @TheCPUWizard said:

    Well, similar patterns are useful for being able to establish breakpoints (although most debuggers now support powerful data driven breakpoints i find less than 2% of developers atually know how to use them) .


    And sometimes even when you know how to use them, they slow things down soooooooooo much that you'd rather use a poor man's breakpoint than the proper conditional one.

     I have not had that problem with any of the IDE's I use in about 3-5 years. Yes, if you set a "watch this memory location on every instruction" type breakpoint it will slow things to a crawl, but that is what you asked it to do. In this case, the breakpoint merely needs to be evaluated only when a specific instruction executes (i.e. the place where the person put in the code)., and should not have any impact.



  • @lrucker said:

    @TheCPUWizard said:

    Well, similar patterns are useful for being able to establish breakpoints (although most debuggers now support powerful data driven breakpoints i find less than 2% of developers atually know how to use them) .

    That's because the documentation for IDEs and debuggers lags far behind the feature set (glares at XCode4).

     True, but how many RTFM anywhy???

    @pjt33 said:

    @TheCPUWizard said:

    Well, similar patterns are useful for being able to establish breakpoints (although most debuggers now support powerful data driven breakpoints i find less than 2% of developers atually know how to use them) .


    And sometimes even when you know how to use them, they slow things down soooooooooo much that you'd rather use a poor man's breakpoint than the proper conditional one.

     I have not had that problem with any of the IDE's I use in about 3-5 years. Yes, if you set a "watch this memory location on every instruction" type breakpoint it will slow things to a crawl, but that is what you asked it to do. In this case, the breakpoint merely needs to be evaluated only when a specific instruction executes (i.e. the place where the person put in the code)., and should not have any impact.



  • @TheCPUWizard said:

    @pjt33 said:
    @TheCPUWizard said:

    Well, similar patterns are useful for being able to establish breakpoints (although most debuggers now support powerful data driven breakpoints i find less than 2% of developers atually know how to use them) .


    And sometimes even when you know how to use them, they slow things down soooooooooo much that you'd rather use a poor man's breakpoint than the proper conditional one.

     I have not had that problem with any of the IDE's I use in about 3-5 years. Yes, if you set a "watch this memory location on every instruction" type breakpoint it will slow things to a crawl, but that is what you asked it to do. In this case, the breakpoint merely needs to be evaluated only when a specific instruction executes (i.e. the place where the person put in the code)., and should not have any impact.


    True, but plenty of people will take the experience of 5 years ago and keep on applying it even though it's no longer relevant.



  • Maybe the developer didn't like that null, so he returns another brand new shiny null... brilliant!



  • @ubersoldat said:

    Maybe the developer didn't like that null, so he returns another brand new shiny null... brilliant!

    There was a specialized language for automation about 15 years ago, where "null" was actually a reall object. All nulls were equal, but they inherently carried with them information about where in the code they had been created. It was very strange, but also quite useful in many circumstances. Sort of like "this information is unknow, and it was xxx who made the determination that it was unknown"



  • So if null was a real object... could you modify it? That would be a totally awesome way to screw with your coworkers' minds... sort of like the old #define TRUE 0 trick in C :)



  • @ekolis said:

    So if null was a real object... could you modify it? That would be a totally awesome way to screw with your coworkers' minds... sort of like the old #define TRUE 0 trick in C :)

     There are very few things that you *cannot* modify in the land of computers [think EMP for an extreme example].  However, in this case, the only information exposed was "const" from any reasonsible viewpoint (on the same order that a _vtable is const in c++)



  • @ekolis said:

    So if null was a real object... could you modify it? That would be a totally awesome way to screw with your coworkers' minds... sort of like the old #define TRUE 0 trick in C :)

    You can do this with certain "constants" in .NET with reflection:
    [code]typeof(string).GetField("Empty").SetValue(null, "muahahaha");[/code]



  • In projects I've worked on, this sort of thing is usually seen when there used to be some other code there, which was removed at one point. Just imagine the piece of code which is no longer there, and it makes more sense.

    The reason the code isn't restructured is usually "I'm nervous that I might be asked to put it back, and I don't want to confuse myself if that happens," which is admittedly a weak excuse but not a WTF.

     



  •  In a still-more-civilized world, it means "we're not doing anything special here now, but knowing management we'll probably have to put in some special stuff later on, so I'm going to make the place where it plugs in so easy to find even a contractor can do it."



  •  Maybe the return of someObject contains an implicit cast to a different type, which cannot be done for a null value.



  • @TheCPUWizard said:

    @pjt33 said:
    @TheCPUWizard said:
    Well, similar patterns are useful for being able to establish breakpoints (although most debuggers now support powerful data driven breakpoints i find less than 2% of developers atually know how to use them) .
    And sometimes even when you know how to use them, they slow things down soooooooooo much that you'd rather use a poor man's breakpoint than the proper conditional one.
    I have not had that problem with any of the IDE's I use in about 3-5 years. Yes, if you set a "watch this memory location on every instruction" type breakpoint it will slow things to a crawl, but that is what you asked it to do. In this case, the breakpoint merely needs to be evaluated only when a specific instruction executes (i.e. the place where the person put in the code)., and should not have any impact.

    I think pjt is referring to "conditional breakpoints". Those can be useful, but they really can turn your application into a slug race when you (have to) put them in a busy location in the code. I once tried placing a conditional breakpoint in the AWTEventQueue when I was trying to figure out where a rogue UI event in a Java application was coming from, and boy, the resulting slowdown (with the debugger having to evaluate the condition for every event added to the queue) meant a 5+ second wait from clicking anywhere in the UI and the desired effect happening.This was Eclipse, by the way.

     



  • @Anonymouse said:

    meant a 5+ second wait from clicking anywhere in the UI and the desired effect happening.This was Eclipse, by the way.

    Yeah, but what did the conditional breakpoints have to do with anything?



  • @blakeyrat said:

    @Anonymouse said:
    meant a 5+ second wait from clicking anywhere in the UI and the desired effect happening.This was Eclipse, by the way.

    Yeah, but what did the conditional breakpoints have to do with anything?

    You don't understand why having a conditional breakpoint in a hot spot might slow things down?


  • ♿ (Parody)

    @smxlong said:

    @blakeyrat said:
    @Anonymouse said:
    meant a 5+ second wait from clicking anywhere in the UI and the desired effect happening.This was Eclipse, by the way.

    Yeah, but what did the conditional breakpoints have to do with anything?

    You don't understand why having a conditional breakpoint in a hot spot might slow things down?

    It's just blakey's way of showing how much he loves eclipse and, for that matter, java.



  • @TheCPUWizard said:

     I have not had that problem with any of the IDE's I use in about 3-5 years. Yes, if you set a "watch this memory location on every instruction" type breakpoint it will slow things to a crawl, but that is what you asked it to do. In this case, the breakpoint merely needs to be evaluated only when a specific instruction executes (i.e. the place where the person put in the code)., and should not have any impact

    As a "CPU wizard" I though you'd know that data access breakpoints are implemented in hardware (DR0-DR7) and don't slow execution much if at all. They might serialize execution in the core, though.


  • @alegr said:

    @TheCPUWizard said:

     I have not had that problem with any of the IDE's I use in about 3-5 years. Yes, if you set a "watch this memory location on every instruction" type breakpoint it will slow things to a crawl, but that is what you asked it to do. In this case, the breakpoint merely needs to be evaluated only when a specific instruction executes (i.e. the place where the person put in the code)., and should not have any impact

    As a "CPU wizard" I though you'd know that data access breakpoints are implemented in hardware (DR0-DR7) and don't slow execution much if at all. They might serialize execution in the core, though.

     Exactly. The impact should be minimal, especially if the "qualification logic" [that which determines if the value which tirggered the hardware breakpoint should cause a software breakpoint] is well optimized.

     Unfortunately there are still a few debuggers out there that either dont use the hardware capabilities (as well as some "non-pc" CPU's that dont have them) which means all bets are off.

    There are also a few vendors who have really poor optimization on the qualification logic...but I simply avoid using their products.



  • If it's javascript then it's useful code for converting undefined variables into null objects. It could be done shorter (return someObject||null;) but it's still useful code.

    In javascript (undefined == null) but (typeof undefined != typeof null)



  • @blakeyrat said:

    @Anonymouse said:
    meant a 5+ second wait from clicking anywhere in the UI and the desired effect happening.This was Eclipse, by the way.

    Yeah, but what did the conditional breakpoints have to do with anything?

    Well, imagine a busy section of a road where normally several dozens, if not hundreds or thousands of cars pass through every second. And there's that big police road block, inspecting cars for suspicious content. Then, imagine the police officers calling back to HQ for every single car passing through, asking for them to decide what to do. I guess HQ is quickly going to be pissed off, telling them to stop bothering them unless there's, for example, at least 3 people in the car, with at least one of them being male, or some other condition like that. Now, there won't be nearly as much actual interruptions in the flow as before, but the on-site officers still have to slow down each car to give it a quick inspection for whether it matches the given condition to be able to tell whether they should stop that car or not. I am sure you can imagine the amount of congestion this would still cause on a busy road like that...



  • @Anonymouse said:

    police
     

    Man, what does this tldr tangent on traffic policy have to do with anything at all ever? Geez.



  • @dhromed said:

    @Anonymouse said:

    He just kept talking in one long incredibly unbroken sentence moving from topic to topic so that no one had a chance to interrupt, it was really quite hypnotic
    Man, what does this tldr tangent on traffic policy have to do with anything at all ever? Geez.

    Nothing makes me happier than someone writing extremely long-winded screeds in response to obvious jokes they didn't get.



  • @blakeyrat said:

    @dhromed said:
    @Anonymouse said:
    He just kept talking in one long incredibly unbroken sentence moving from topic to topic so that no one had a chance to interrupt, it was really quite hypnotic
    Man, what does this tldr tangent on traffic policy have to do with anything at all ever? Geez.
    Nothing makes me happier than someone writing extremely long-winded screeds in response to obvious jokes they didn't get.
    Around this place, there's no such thing as an obvious joke. Or certainty about whether someone really isn't serious about something, almost no matter how outrageous, for that matter.

    Besides, when I read your post that road block analogy just popped into my head, I thought it was cute and wanted to share it. It didn't really matter at that time whether you were actually being serious or just bashing something again.

     



  • @blakeyrat said:

    @dhromed said:

    @Anonymouse said:

    He just kept talking in one long incredibly unbroken sentence moving from topic to topic so that no one had a chance to interrupt, it was really quite hypnotic
    Man, what does this tldr tangent on traffic policy have to do with anything at all ever? Geez.
    Nothing makes me happier than someone writing extremely long-winded screeds in response to obvious jokes they didn't get.

    Me too, but what does this have to do with what you quoted?

Log in to reply