|
in reply to Re^4: On being 'critical'
in thread On being 'critical'
Now, each company can have its peculiar coding standards, and TheDamian also warns that those in PBP are to be taken as things to think about, rather than absolute rules by themselves.
And that's kind of the point. Perl::Critic can't think. There was nothing all that egregious about the OP's code.
This actually moves the discussion towards the good and bad of having company coding standards.
What's bad about having coding standards? Nothing. Unless you have bad coding standards. Completely inflexible coding standards might be bad. And if you use software to check that your code is compliant with your standards... well... that's pretty inflexible.
... adopting those workarounds leads to a shallow compliance, breaking the underlying requirement.
This would be another very good reason to avoid using Perl::Critic or something similar to enforce your coding standards. Using software to check compliance to coding standards encourages workarounds. (Especially when forcing compliance on your existing code base.) Keeping things just a little fuzzy and open to interpretation encourages that interpretation to actually take place. If the standard is too rigorous and well-defined it will be subverted in absurd ways when it might have been better to just ignore it.
-sauoq
"My two cents aren't worth a dime.";
|
Re^6: On being 'critical'
by polettix (Vicar) on Dec 20, 2006 at 00:29 UTC
|
I don't fully get the point. Coding standards are coding standards. If the coding standard says "don't use globals and Perl 4 filehandles", you're not supposed to use either $Package::LOGFILE or Package::LOGFILE. There's no interpretation at all.
As to using Perl::Critic to enforce something, it's up to you (or to the company). Perl::Critic is a tool: it tells you if you appear to violate rules in PBP, at different levels of bothering. If the company chooses PBP as coding standards (which you could consider "bad coding standards", but that's another topic), then Perl::Critic can be a helpful tool in developer's hands to understand the adherence to the coding standards. At this point, if you look for a workaround instead of fixing the warning in the proper way... you're simply breaking the rules.
IMHO, Perl::Critic is quite similar to using warnings. I think that working with warnings on is good, but it's software checking compliance to a certain set of basic coding standards (like avoiding implicit usage of package variables, dereferencing strings, avoiding to initialise variables before using them, etc.). And, again, it's a tool: you can benefit from warnings, and decide to keep some fuzzyness in certain places disabling them (or deciding to explicitly ignore them).
Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf
Don't fool yourself.
| [reply] |
|
|
I don't fully get the point. Coding standards are coding standards.
Well, that's just it. Coding standards in the real world tend to be coding guidelines. For good reason. Some formatting issues (ironically often called style guidelines) are hard and fast rules: do/don't cuddle elses, indents are X spaces, do/don't use tabs, etc.† But you have to have some flexibility when addressing things that aren't just cosmetic. Some coding standards, probably the better ones, are explicit about that. The goal is always to efficiently write efficient, robust, and maintainable code. It's pretty widely recognized that following arbitrary constraints just for the sake of following them doesn't get you there. Coding standards require intelligent application.
Forgive me for saying so, but you seem overly caught up in the "rules". Rigor is good when you are, say, implementing a protocol specification. But you can't so easily apply rigor to the art of programming itself. Coding standards sometimes must be bent so they should be flexible. If they aren't they'll be broken outright.
† Using tools to aid with these issues is a fine strategy, by the way. I'm a strong advocate of using perltidy, for instance.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
Forgive me for saying so, but you seem overly caught up in the "rules".
On the contrary, I'd say. I'm mostly a "personal" programmer, given the fact that programming is only a (pleasant) side effect of my real work (telecommunication consulting). So, I really stick to the rules that make sense to me, and it's indeed a somewhat natural process :). (Moreover, I find that you are very polite).
On the other side, I can understand software houses, or companies in general, deciding to adopt coding standards. What I was trying to point out (but I evidently failed miserably) is that if the company sets some rules the solution is not in adopting strategies that allow you to break them without being caught. You can probably object them, discuss them with the management, or whatever - but the fact remains that these are rules that you should follow.
To make an example, consider the traffic lights in Italy and in Poles. In Italy, when it's red you cannot pass; in Poles, in most cases you are allowed to pass if you have to turn right and you are careful to grant the due precedences. These are two different "driving standards", and you can say that the Polish one is probably more intelligent, but the fact remains: if you pass with red in Italy, even if nobody is passing and you're only turning on the right, you're breaking driving rules. If you're caught, you're likely to get a fine to pay and you actually have nothing in your hands to avoid this (apart some good friend in the local police, but that's another thread).
The bottom line is: if the company chooses some coding standards, you should adhere to them as much as possible. If you disagree with them, discuss them and try to have them changed, but don't advocate the right to bend them at your will: others may count on the fact that you're following them.
Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf
Don't fool yourself.
| [reply]
[d/l] |
|
|
|
|
|
|
