Front page | perl.qa |
Postings from April 2007
Re: New CPANTS metrics
Thread Previous
|
Thread Next
From:
ReneeB
Date:
April 1, 2007 07:11
Subject:
Re: New CPANTS metrics
Message ID:
460FBD78.1090703@renee-baecker.de
Eric Wilhelm schrieb:
> I'm looking forward to the source (must just be delayed by PAUSE.) I'm
> curious whether the mentions_kwalitee metric has any gaming-prevention.
> If I say "reduced kwalitee" in the changelog, does that count for or
> against me?
>
>
>> Some of the new metrics can't be satisfied. I doubt that all dists can
>> "use" 5 or more other CPAN dists. I think some of the metrics should
>> be optional (uses_recursion, nice_code_layout, reuses_code). You
>> shouldn't punish the people (like me) who don't like the code layout
>> you like.
>>
>
> If your code doesn't have *any* recursion, the module is probably
> lacking several features anyway. I think we would all be better off if
> whenever we start to write a "for" loop, we stop to think "how could I
> do this recursively?" If done correctly, it also tends to rid code of
> those silly temporary arrays that lead to so much needless
> head-scratching.
>
> As for code reuse, I think the metric needs work. It should detect
> whether I've paste-reused code. Any good module contains at least 15
> verbatim lines from each of 10 existing modules. Saves the end-user
> the hassle of installing prerequisites or dealing with bugfixes. For
> those that prefer a more SPOT style, the metric should detect whether
> we're using eval(`curl http://search.cpan.org/src/$wantcode`) to
> implement reuse.
>
We should upload five basic dists (one for for-loops, one for
if-else,...). Then (nearly) every module can use these five modules to
raise the kwalitee.
> The point of having the nice_code_layout metric is to force conformity.
>
But everybody has different opinions about "nice_code". And sometimes
companies force their employees to write the code in a specific layout.
I don't like the idea of forcing people to program in a specific way.
I would test for a test_perl_critic.pl file that tests for
severity-level 5 issues. That has nothing to do with code-layout but
with good code.
> That's the important thing here. We should also probably require vim
> modelines somewhere:
>
> # vim:ts=1:sw=1:noet:syn=lua
>
I dont't use vi(m) or emacs!
> Is my personal favorite. Though I think the lines should start with
> "peterbuilt" just to be perfectly clear. After all, ";" is awfully
> abbreviated. How can you expect an intern to understand something so
> terse?!
>
>
>> You also should mention what "docs_make_sense" is! What are the rules
>> for "docs_make_sense".
>>
>
> That one is still under development. We're working on a massively
> parallel distributed human comprehension evaluator. At present, it
> seems that the HaMCaQE (harmonic mean captcha quiz engine) may prove
> more viable than the SDMC (shakespearian digital monkey cluster) due to
> the wide availability of porn site subcontractors. I'm still working
> on the SIGSEC (statistical ignorance game show entropy collector)
> though, and think it shows real promise. For the time-being, we're
> using a stopgap hack of a simple part-of-speech ordering analysis,
> though that tends to get easily confused by recently trendified
> nounverbifications.
>
> --Eric
>
Renee
--
my Perl-Blog: http://reneeb-perlblog.blogspot.com
Thread Previous
|
Thread Next