Perl::Critic vs. Subversion
[email protected] ("Jonas B. Nielsen")
| Newsgroups | perl.copenhagen |
|---|---|
| Message-ID | <[email protected]> |
Hep,
Jeg har lige skrevet nedenstående mail til Perl::Critic users listen, men tænke at debatten måske også kunne være interessant i regi af Copenhagen Perl Mongers.
Mailen er på Engelsk, men jeg håber at I kan bære over med det.
--
Hello,
I fell over the following tweet.
http://twitter.com/perlcritic/status/15575614333
I understand Elliot's points and I do agree to some extent, but I think it is a bit one-sided. We have just had a presentation at a local Perl monger meeting where a local business presented there use of Perl::Critic integrated with their git solution - and this seemed to workout fairly well.
So I think some more debacle on the topic of using Perl::Critic with VCS pre-commit hooks is necessary, before eliminating this use as bad practice. So let me try to play the devils advocate here...
I think it is a tough balance to find out how much constraint you should put on the ability and ease of committing code to a repository.
But if you read the docs on Alexanders contribution, it actually opens up for ease of you in the case that Elliot is describing:
# Emergency commits: {0|1}. There are situations when you *do* need
# to commit changes bypassing all checks (e.g. emergency bug fixes).
# This featue allows you bypass Perl::Critic using “magic” prefix in
# comment message, e.g.: svn ci -m “NO CRITIC: I am in hurry” FooBar.pm
allow_emergency_commits => 1,
# Magic prefix described above can be customized:
emergency_comment_prefix => ‘NO CRITIC’,
And if I am not totally mistaken:
## no critic (RegularExpressions::ProhibitEscapedMetacharacters)
Should also do the job.
Enough with the details.
I think it is important to understand why static analysis is a good tool and what role it plays.
I often regard my ## no critic as TODO points, points to be revisited. And to me it is all about technical debt.
Perl::Critic helps us:
- writing maintainable code
- pin-pointing possible bugs or issues
So a quick fix circumventing the policies is introducing technical debt, breaking windows as it goes a long, so to speak.
So I need stronger arguments or war stories before discouraging the use of Perl::Critic based pre-commit hooks.
Anyone?
jonasbn