in reply to Lessons learned from getting to 100% with Devel::Cover

highlighted several redundant areas - along the lines of 'if these preconditions are met, then it is impossible to reach this part of the code'
This bothers me a bit, or at least how you might have reacted bothers me.

While I love realizing that I've been overly cautious and have redundant checks, I also wouldn't want to be, umm, underly cautious either. There have been several times when I realized that it would be _useful_ for later code to check that earlier code hadn't mangled necessary preconditions. Read these as 'assertions'.

How _did_ you react - clean up redundancies or total removal?

--
I'm a pessimist about probabilities; I'm an optimist about possibilities.
Lewis Mumford

  • Comment on Re: Lessons learned from getting to 100% with Devel::Cover

Replies are listed 'Best First'.
Re^2: Lessons learned from getting to 100% with Devel::Cover
by leriksen (Curate) on Aug 01, 2004 at 12:49 UTC
    Maybe I made it sound a little more impressive than it really is

    Say you have a function/method.
    Say you have a number of preconditions that need to be met in that function/method before proceeding deeper into the sub's logic.
    Devel::Cover points out which unexercised paths among those preconditions need tests written for them. You write those test, so that the preconditions are 100% tested.
    Deeper inside the function.method, Devel::Cover shows you other untested paths.

    Looking at these, it quickly becomes apparent that, _if_ the preconditions have been met, and therefore you have progressed to one of these untested code branches, that it is not possible to specify a set of parameters to that function/method that pass the preconditions and progress down the untested path - therefore the untested branch is redundant - it can never be exercised.

    use brain;

[reply]
Re^2: Lessons learned from getting to 100% with Devel::Cover
by maetrics (Sexton) on Jul 31, 2004 at 01:06 UTC
    You raise a good point.

    Redundancy isn't bad in the least bit. Since computers, math and all things logical are "incomplete" (google "halting problem turing godel"). Its impossible to remove all bugs, and (this is my belief) that there is a direct correlation between complexity and the bugginess (gotta love those scientific terms). Since there will always be bugs, redundancy is used to "detect" and possibly "ignore" bugs. Critical systems, such as those used on the F-16, have numerous redundancy that are checked against each other to determine the "correct" results. Of coarse even with highly redundant systems, it is possibly that a bug will result in a uniform false result.

    However, what is considered "critical" when flying faster than sound is quickly becomes "overkill" when running a perl script. In the end you have to decide just how important it is that the script absolutely runs.

[reply]

      Actually, redundancy is bad. Redundancy is, in fact, a great evil. Redundancy hinders the propagation of changes.

      Redundancy and failover systems can be good in hardware, but that scenario is not comparable to redundancy in code on any level.

      Makeshifts last the longest.

[reply]

In Section Meditations