From my original post:
Module::Starter::Simple.pm has a subroutine _get_licenses_mapping that lets the module developer select from perl, mit, bsd, add other license text.
How can I plugin my own license and copyright text (tailored to my employers standard commercial wording)? /
From that, I think it's clear that I can already select "perl", for example, and standard text is plugged in.
But that standard text is not tailored to my employers standard commercial wording.
It looks like Module::Starter produces a template that falls far short of perlcritic standards, but a Build program that works despite pathnames embedding spaces. In contrast, Module::Starter::PBP produces a template that almost meets perlcritic standards, but a Build program that fails if pathnames embed spaces.
The clumsy compromise seems to be to use Module::Starter::PBP once only to generate a template, then fix that template's few bugs and keep it, then always use
Module::Starter to generate new frameworks and Build programs, but overwrite its template with the saved perlcritic compliant one (as a Vim plugin, say).
Wouldn't it be nice if the few critical rough corners on Module::Starter::PBP were smoothed off . . .
Or can any Monk recommend a better way towards a really classy, standardised, consistently-tailored module-production mechanism? | [reply] |
falls far short of perlcritic standards
Are you listening to yourself? I mean, really listening to yourself!
Perl::Critic is the embodiment of: the Perl-shy in a Perl world; the belt-&-braces man in a just-what's-needed-world; a functional-zealot in a side-effects-are-inevitable world; an OO-zealot in a procedural-can-be-efficient-and-correct world.
Perl::Critic is: Caution in Extremis, to point of paralysis; Careful to the point of paranoia; Deferential to the point of Indecisive; Follow my leader (even over the cliff).
Perl::Critic is the Sum of all Fears!
Imagine trying to live your life avoiding all the 51 million 200 thousand things that someone, somewhere believes are bad for you. Well that's what trying to follow Perl::Critic (with it's default settings) gives you.
Every single prejudice, dogma, and misunderstanding that any ex-COBOL, C++, VBasic or Haskell programmer ever had on their first excursion in Perl; applied rote--like a 5 year old reciting their times tables--without any application of knowledge, understanding or judgement.
Man up! Learn enough about the language you are programming in to make your own decisions. Make your own decisions and live with their consequences and learn from them; Don't let the machine tell you what to do!
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Are you listening to yourself? I mean, really listening to yourself!
If you ... remove all the hyperbole; excessive adjectives, adverbs and superlatives; marketing speak; cutesy and/or tortured analogies; similes and metaphors; unverifiable statistics, bar charts and graphs; and customer testimonials.... Does what's left a) still make sense; b) constitute anything more than just common practice and common sense?
— BrowserUk, Re: Nobody Expects the Agile Imposition (Part II): The Office
Sometimes I think you'd find a way to criticize reading documentation if a handful of other monks started answers with "Have you read the documentation? It says...."
| [reply] |
Whoa, Flame-boy! Steady, now.
perlcritic is not a straitjacket that compels you to stick, as you say, with it's default settings.
Its manpage is up-front about this:
perlcritic is not limited to enforcing PBP, and it will even support rules that contradict Conway. All rules can easily be configured or disabled to your liking.
.perlcriticrc is your friend. That is where you elect which policies to enforce. Throttle back on those policies just as far as you want -- it won't bite you.
On a serious note, my project at work has swung at the opposite end of the spectrum for years, with some would-be Perl 5.004 programmers who have never used warnings or enforced strict checking, and would never consider taint checking. For them, project and open standards are utterly alien. They have never heard of perlcritic or perltidy. In their laissez-faire freedom, no one has ever shackled them to the constraints of perldoc, Test::More, Kwalitee, make, build, bench-marking, profiling, ptkdb, or any of the other tasty development tools that Perl 5.10 serves up on a plate.
But that lazy freedom has spawned a morass of dud software that enslaves todays programmers who have to learn it and maintain it. There are better ways.
perlcritic is merely a tool that, used wisely, is one element in creating a practical, developer-friendly IDE. Which policies to enforce? Let the project's smartest Perl programmers and architects debate, haggle, horse-trade, and agree on what to choose. Try democracy, not hippy dogma.
| [reply] |
1) create your own subclass to your standards
2) try Module::New
| [reply] |