On Tuesday 24 June 2008 00:50:27 Paul Fenwick wrote: I forgot to respond to another portion of this post; I apologize for double responses.
> > I'm very much not happy to get bug reports and test failures and big red > > bars against my distributions because an automated heuristic which > > applies only to some cases decided that it knows better about how to > > write code than I do. > > One could argue this is the case for all the CPANTS tests. Why should your > code use strict, Because it helps me as an author. > or warnings, Because it helps me as an author, and some of my code uses lexical warnings, which help my users. > or Test::Pod::Coverage, It doesn't (and soon won't), because it's almost always useless for the code I write. When I spend more time tweaking the exception list to skip internal subroutines which are not and never will be part of the public API but help me write cleaner, more maintainable, more understandable code than I spend actually writing the code, Test::Pod::Coverage is actually *harmful*, and it must go away (from the code I write). If a heuristic says I should use it, the heuristic is wrong. (I'm aware of the argument which says "You can work around a wrong heuristic by piling hack upon hack and writing unnatural, ugly code" but I hope the problem with that fallacy is superlatively obvious. I could waste my time and clutter my source code with workarounds trying to make flawed heuristics at least not do the wrong thing, or I could use my brain and experience to look at and reason about shorter, clearer code and spend my time doing something more valuable. It seems a matter of bad policy to encourage other authors to waste their time and energy on minutiae.) > or have its tests in t/ ? Because it helps me as an author and it helps my users. > These are all just automated heuristics telling me how to write my > code. Some of them are even *useful*. I like those. The useless distracty ones and the actively harmful ones -- not so much. -- c
