All to often the reason for some things at companies is due to historical and/or old fashioned ways of doing things. I have seen cases where programming was done a certain way "just because that is the way we do it here". There are certainly also examples of programming a certain way or with certain methods because it is the way a senior programmer or manager (who was probably 'the' programmer at one time) want to have it done; irrespective of whether it is the best way or not.

as to the above,

Yes, Michael, in many cases you are absolutely right. Adhering to rules for the sake of rules can be destructive.

May I as one of the "programming a certain way " people respond.

My opinion:
Any "standard", "rule" or whatever must be adhered to if the advantage of deviating from it is not significant. I am perfectly open to doing things another way if there is a significant advantage, but making a total confusion of methodology, just because it can be done in a different way, leaves a mess.

If you work without standards and rules, you can end up with e.g. main() written one way and a first level function written a second way and a driver written a third way.

THAT breaks my one ironclad rule: Maintainabilty. If the person that has to modify some code down the road has to familiarize him/herself with 5 different programming styles, the maintainability is lost.

Erik