There's no substitute for understanding what you're doing, so understand what you're doing.

(But don't resolve never to use a lathe or a drill press because you heard someone once used one somewhere for eeeeeevil.)

I utterly agree with both those statements.

Unfortunately, understanding takes time and practice and a few different projects and types of project, before the patterns from which understanding forms become evident. As a substitute, society tries to teach experience; but that is a very hard thing to do. So, you end up with guidelines that omit the reasoning, and so become unassailable dogmas. Hence, I received a recruiter circular a few months back that asked for "Perl programmer experienced in coding to PBP/PerlCritic standards."

(Really. Honestly. I just checked to see if it was still hanging around in my email somewhere but it isn't :( )

With respect to coverage tools. If a module is big enough that I need a computer program to tell me if I've covered it sufficiently with tests, it is big enough that it will be impossible for a human being to get a clear enough overview to be able to successfully maintain it. It is therefore too damn big.

But then, for any given problem I tend to write about 1/10 of the code that the average programmer seems to write. Mostly because of the code I don't write.