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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.