- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
Performance measured based on number of lines of code?
Admin
I caught a similar thing in code review recently. Someone had added an override to a validation method that went something like
Admin
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.
Admin
It's amazing how many people simply cannot fathom conditional breakpoints.
Admin
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.
Admin
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.
Admin
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.
Admin
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 ...
Admin
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
Admin
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 )
Admin
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)
Admin
Not quite. That is the correct way a getter should behave. But there is nothing stopping someone from doing some nasty side-effects.
Admin
I agree with most, this is dead code. For RJ, let us know how it works out.
Admin
@Auction God ref
The derived method unconditionally calls
base.IsValid
. Therefore whateverbase.isValid
does will be done. Be that return true, return false, throw, perform amazing feats of side effect, or fire nasal demons all over the server room.Addendum 2024-10-31 08:41: Oops. Hit send too soon. ...
Which is to say the derived function does nothing useful in the execution path.
It does represent a way to set a conditional breakpoint without using the conditional feature of your IDE. Which might be valuable.