There are various coding standards enforced at software companies which have the goal of increasing code reliability, portability, and, most importantly, readability in code written jointly by different developers.
These are usually in the following form, after carefully specifying what the words "must", "shall", "should", "might", etc. mean:
Rule 50: Floating point variables shall not be tested for exact equality or inequality.
Rationale: Since floating point numbers are subject to rounding and truncation errors, exact equality may not be achieved, even when expected.
These coding standards pose restrictions, usually on code which would be legal from the compiler's point of view, but it is dangerous or unreadable, and is therefore "considered harmful".
Now let's abuse this!
You are accepted as a member of a small standardizing committee at your company, which is intended to design the new coding standards every developer at the company will be required to use. Unbeknown to the others, you are secretly in the employ of a sinister organization and have as your mission to sabotage the company. You have to propose one or more entries to the coding standard which will later hinder the developers. However, you must be careful to not make this immediately obvious, otherwise you risk it not being accepted into the standard.
In other words, you must introduce rules to the coding standard which look legitimate and have a good chance of being accepted by the other members of committee. After the projects are started and countless man-hours are invested in the code, you should be able to abuse these rules (for example, by a technicality, or by a very literal interpretation) to flag otherwise normal and good quality code as being against the standard. So they must put a lot of effort in to redesign it, and the rules will hinder them from this point on, but as the rules are active for quite some time now, pure momentum will keep these roles alive, and as there are significant conflicts of interests between different levels of management, the other managers will probably keep the rules alive (they would be foolish to admit their mistake!), therefore hindering the company! Mwahahahahaaa!
The highest voted answer after approximately 2 weeks from the first valid entry wins. I have an idea for a good answer, but I will only post it a few days later, as someone else might come to the same idea, and I don't want to rob them from the pleasure. Of course, my own answer will not be accepted above any other, no matter the score.
Voters are encouraged to score answers based on how well the loopholes are hidden, and how frustrating to the developers they would be.
Rules and regulations
- The rule or rules must look professionally written, like in the above example
- The rules should look genuine (so things like "all variables must contain at least one underscore, one upper case letter, one lower case letter and two numbers" are not accepted. They would indeed hinder developers, but would most likely not be accepted by the committee) and if their merit is not immediately obvious, you should give a good rationale.
- You should be able to find a way to use/abuse your rules to sabotage the developers later on. You might abuse any ambiguity in other rules, or you might use multiple rules which are harmless on their own, but diabolical once combined!
- You should post an explanation in spoiler tags at the end of your post about how you could abuse the rules
- The language used must not be an esoteric language. A language widely used in real projects must be chosen, so languages with C-like syntax (instead of things like Golfscript) are preferred.