• TheCPUWizard (unregistered)

    Now (without that code) set a break point that is triggered ONLY on the specific derived class when valid is false! With that code, it is trivial.

  • Jonathan (unregistered)

    Performance measured based on number of lines of code?

  • Jaloopa (unregistered)

    I caught a similar thing in code review recently. Someone had added an override to a validation method that went something like

    public override bool IsValid()
{
    switch (someProperty)
    {
        case someValue:
            break;
    }
    return base.IsValid();
}
  • some guy (unregistered)

    It might be there as proof that the base method can, in fact, be overridden. However, that is reaching, and dysfunction is the far more likely explanation.

  • (nodebb)

    It's amazing how many people simply cannot fathom conditional breakpoints.

  • retsep (unregistered)

    Pimples can't be carelessly popped, as well as deleting of seemingly useless code lines. Use of a static boolean for debugging purposes and checking its value before function definition might help to clear the intention of developer.

  • Deeseearr (unregistered)

    And yet, somehow, if you remove that method the entire application breaks. But not right away. And it will only break if you build it with all eighteen different DEBUG settings turned off, using the special cross-compiler which produces the final application which can only run on the embedded device with 200k of memory and a processor that was built by hand in a monastery on the Comoro Islands.

    And it will all be your fault.

  • Brian (unregistered) in reply to WTFGuy

    Oh, we fathom them, we just don't use them when they slow the execution to roughly the speed of a turtle swimming in molasses. Much faster to simply compile that condition into the code somehow, such as with this kind of no-op. Of course, when I do that, I also put a big "Debug only! Don't commit this!!" note-to-self comment in there so either I remember to take it out later, or someone can catch it in a code review.

  • Foo AKA Fooo (unregistered) in reply to WTFGuy

    Either that, or "set a breakpoint" to justify all kinds of stupid code has become a running gag/meme by now. I'm really not sure at that point ...

  • (nodebb)

    What this code ACTUALLY (TM) does is to ensure that, should some other linked library contain an isValid function, that this one takes precedence and guarantees the builtin isValid will be invoked. /s

  • (nodebb)

    It is possible the base class implementation is more complex than you realize. For example, it may throw an exception only when evaluation would lead it down the TRUE path. In which case this derived function would "skip" the exception. (Very, very unlikely - but you can't just whack code without looking )

  • Tim (unregistered) in reply to Auction_God

    I was thinking about this but I don't think you're right. The base function can only do one of 3 things: return true, return false, or throw an exception. In all cases the derived function will do the same thing (albeiit in the latter case the stack trace will be slightly different)

Leave a comment on “A Base Nature”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article