Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid


by zby (Vicar)
on Mar 14, 2003 at 13:38 UTC ( [id://243021] : note . print w/replies, xml ) Need Help??

in reply to Fun with Hook::LexWrap and code instrumentation

I've read somwhere they are just coming. Wouldn't it be simpler with assertions?

Replies are listed 'Best First'.
The cure would be worse than the disease
by dragonchild (Archbishop) on Mar 14, 2003 at 14:33 UTC
    Doing this by hand would be a complete PITA

    No. Doing this would be

    1. a complete waste of time
    2. counter-productive
    3. a case of the cure worse than the disease
    Every time you add a line of code, you have a non-zero (and often deceptively large) chance of introducing a bug. Let's say that you're a really good programmer and your error rate for development is 1 bug for every 20 lines of code*. If you add 100 assertions to find one bug (assuming that Foo is used in 100 places), then you just (potentially) added another five bugs, just as hard to track. (Possibly harder, because everyone assumes that bugfix code isn't buggy.)

    In addition, you now have a maintenance nightmare. Let's say that I'm your maintenance programmer. I go in and realize I need to now modify Foo somewhere. I have 24 hours to get this bug fixed. I don't know about your assertions thing. All I know is that I can fix the bug by hacking at your pretty object. Boom! Your entire assertions framework fails.

    Using Hook::LexWrap (and similar techniques) is vastly preferable to adding assertions by hand, for just these reasons.

    * Error rates gleaned from Code Complete on p. 610. Steve McConnell says that delivered code generally has 15-50 defects per 1000 lines. He also says that the Apps Division at MS has 10-20/1000 during in-house testing and 0.5/1000 in released code. That's a 30-1 ratio between development and release for a stringent regime. A lax regime will probably have a 10-1 ratio. Thus, a standard programmer during development will probably have 350-500 defects per 1000 lines of code. A really good one will be at 50/1000, or 1/20 lines of code.

    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      All true.

      One of the many things that excites me about perl6 is that it looks like you'll be able to implement proper class invarients and contracts ala Eiffel with the subroutine wrapping stuff. Nice.

      That's not to say I'm not looking forward to a sensible assertion mechanism in the next perl5. Although my first thought when I saw it was to use it for logging ;-)

Re: Assertions?
by adrianh (Chancellor) on Mar 14, 2003 at 14:05 UTC

    I don't think it wouldn't in this instance. We're tracking bug that's due to a naughty subclass breaking encapsulation (direct hash access rather than via methods).

    Adding assertions to the base class won't help. That's not where the bug is.

    Adding assertions to the subclasses is basically what we're doing - but at runtime not compile time.

    The "problem" with perl is that because we don't have proper encapsulation we would have to add the assertions by hand to anything that might fiddle with a Foo object in a naughty manner. Doing this by hand would be a complete PITA. Doing it programmatically using Hook::LexWrap is a breeze.

      I've got it - you are right. I had a thread about code analyzis - TIMTOWDTDI, obfu and analyzis of code it seems this could be applicable here too. The difference is this would be a static method while your's is a dynamic one.