Re^7: On being 'critical'

[sauoq]

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.

[polettix]

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.

[sauoq]

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.

I think the core issue we are addressing can be summed up with the question "what makes coding standards good?"

My pragmatic, I think, outlook is that if the rules are too rigid, you can count ont them being cleverly circumvented when a reason to do so presents itself. (As in the OP.) If, on the other hand, they are flexible then they won't have to be circumvented at all.

It seems your outlook is that, regardless of how rigid they are, the coding standards should be followed. And not just their letter, but their intent. Petition for change is fine but, short of that, if the coding standard in place requires you to jump hoops then that's exactly what you should do.

Interesting. I think it might just boil down to personality. Some, like yourself, will follow both the coding standard itself and the intent of its author regardless of how doing so adds complexity to your task. Some, like me, will happily follow the coding standard itself but, when presented with a situation that is poorly addressed by the coding standard, I'll happily circumvent it if doing so enables me to more efficiently solve the real issue at hand.

The reason I think my outlook is pragmatic is that people like me exist. If a coding standard isn't written with the understanding that we exist, it will be less than optimal. And I suggest that any coding standard that is so rigid that it can actually be checked by software fails to take my existence into account. :-)

I guess you could argue that I should change. Maybe I should. But even if I do, there are a lot of people like me. And it just isn't pragmatic to expect them all to change. So, instead of changing, I think I'll just advocate better coding standards.

[polettix]

I think the core issue we are addressing can be summed up with the question "what makes coding standards good?"

Uhm, not really IMHO. I think that it was more of a "meta-discussion", but it's fine for me to mix the two topics :) Forgive me if I mix up your citations, but I urge this one:

I guess you could argue that I should change.

I couldn't be more distant from this. I'm pretty happy there are so different people in the world, even if I don't like them all (not your case, of course). And the reason why I continue this thread (beyond the pleasure to do so) is that I'm curious about other points of view.

It seems your outlook is that, regardless of how rigid they are, the coding standards should be followed.

Yes, but maybe I missed to stress another point: nobody obliges you. If you find that the standards are too rigid, that the management is too stiff, and that you hate them all, you'd better consider getting a better job. Which is not always feasable, or adviceable, I understand; but the decision to continue (given by family, loans, etc.) should be in the good and in the bad. I mean, if you accept the compromise to continue a bad work in order to "survive", you'd accept the rules that come with this decision.

Interesting. I think it might just boil down to personality.

Definitively. I always prefeared to try the discussion instead of explicit rule breaking and *then* discussion. But I also understand that many results, in many fields, were reached more because of "break" than because of "diplomacy" - just think of '68. I probably lack the courage/nerves/heart/mind/whatever to be on the "break" side. If you happen to be such a person, you should probably try to discuss anyway: the final goal should probably be that all benefit from better coding standards.

To conclude, one advice: if you happen to drive in Italy, don't pass when the traffic light is red :) Merry Christmas,