http://qs321.pair.com?node_id=11127803


in reply to Re: Pod::Coverage for helper classes
in thread Pod::Coverage for helper classes

"why your other classes are not in their own files?"

From my OP: "I could move the helpers out into other module files, but that gets pretty silly for some of the helper classes.". Some of the helper classes are very small and it is something of a pain to spin up a new module just to provide three methods in a helper class where each method is only a few lines long. It is also a pain during development to flip back and forth between different files as I evolve the design. None of these are show stopper reasons, but they add up to "I'd rather have the helpers in the main module file.".

"PS if your modules works fine why to care about Pod::Coverage"

My module doesn't yet "work fine" - I'm still writing it and I like to check code and documentation coverage as I write the code and even write tests for code I haven't written yet in some cases. Even if this were a complete working module, I'd still be concerned that tests, code coverage and documentation coverage were all up to snuff so that I can maintain the module with confidence.

"you forgot to return true ;"

From OP: "In outline the file looks something like"

You may be interested to note that '...' is the yada yada statement. It is useful as a place holder for code yet to be written. It compiles correctly, but generates an error if executed. Kinda useful in code that isn't fleshed out yet. You can write a place holder sub and write tests against it which will fail until the ... is replaced by real code.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond