What was the strangest coding standard rule that y

Question

When I asked this question I got almost always a definite yes you should have coding standards.

What was the strangest coding standard rule that you were ever forced to follow?

And by strangest I mean funniest, or worst, or just plain odd.

In each answer, please mention which language, what your team size was, and which ill effects it caused you and your team.

Answer 1

A buddy of mine encountered this rule while working at a government job. The use of ++ (pre or post) was completely banned. The reason: Different compilers might interpret it differently.

Answer 2

We had to sort all the functions in classes alphabetically, to make them "easier to find". Never mind the ide had a drop down. That was too many clicks.

(same tech lead wrote an app to remove all comments from our source code).

Answer 3

To NEVER remove any code when making changes. We were told to comment all changes. Bear in mind we use source control. This policy didn't last long because developers were in an uproar about it and how it would make the code unreadable.

Answer 4

I worked at a place that had a merger between 2 companies. The 'dominant' one had a major server written in K&R C (i.e. pre-ANSI). They forced the Java teams (from both offices -- probably 20 devs total) to use this format, which gleefully ignored the 2 pillars of the "brace debate" and goes straight to crazy:

if ( x == y ) 
    {
    System.out.println("this is painful");
    x = 0;
    y++;
    }

Answer 5

a friend of mine - we'll call him CodeMonkey - got his first job out of college [many years ago] doing in-house development in COBOL. His first program was rejected as 'not complying with our standards' because it used... [shudder!] nested IF statements

the coding standards banned the use of nested IF statements

now, CodeMonkey was not shy and was certain of his abilities, so he persisted in asking everyone up the chain and down the aisle why this rule existed. Most claimed they did not know, some made up stuff about 'readability', and finally one person remembered the original reason: the first version of the COBOL compiler they used had a bug and didn't handle nested IF statements correctly.

This compiler bug, of course, had been fixed for at least a decade, but no one had challenged the standards. [baaa!]

CodeMonkey was successful in getting the standards changed - eventually!

Answer 6

An externally-written C coding standard that had the rule 'don't rely on built in operator precedence, always use brackets'

Fair enough, the obvious intent was to ban:

a = 3 + 6 * 2;

in favour of:

a = 3 + (6 * 2);

Thing was, this was enforced by a tool that followed the C syntax rules that '=', '==', '.' and array access are operators. So code like:

a[i].x += b[i].y + d - 7;

had to be written as:

((a[i]).x) += (((b[i]).y + d) - 7);