Sabotage the coding standards [closed]

Question

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.

Two notable examples are the MISRA C, and the C++ standard developed for the JSF project.

These are usually in the following form, after carefully specifying what the words "must", "shall", "should", "might", etc. mean:

Example:

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!

Scoring

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.

Answer 1

C / C++

Rule 1: octal constants shall not be used

Rationale: octal constants can be a cause of confusion. For example, a casual glance over the line const int coefficients[] = {132, 521, 013, 102};
might miss the fact, that one of the numbers in the array is defined in octal.

If you want to be even more evil, add the following:

Rule 2: hexadecimal constants shall only be used in the context of bit manipulation.

Rationale: If a constant represents a numerical value, it's more readable if it's in decimal. A hexadecimal constant should indicate that it represents a bit mask, not a numerical value.

How it can be abused:

Take the following simple program which will add the first 10 elements of an array. This code would not be standard-conforming.

sum = 0;
for (i = 0; i < 10; i++) 
{
    sum += array[i];
}

Note, that 0 is, per definition, an octal constant. Per rule 1, requiring it to be written as 0x00 all through the code is frustrating. Per rule 2, even more frustrating.

Answer 2

Python

Rule 1: All code must be byte-compiled using the -OO flag, which optimizes the bytecode. We want optimized bytecode for size and efficiency!

Rule 2: Tests must be run against the same "artifact" of code that will be put into production. Our auditors require this.

Using -OO removes assert statements. Combined with rule 2, this effectively bans the use of assert statements in tests. Have fun!

Answer 3

This is for a Node.JS project.

Section 3 - Speed and efficiency are of essence

Rule 3.1: Files should be kept to a maximum of 1kb. Files bigger than this take too long to parse.

Rule 3.2: Don't nest functions more than 3 levels deep. The V8 engine must keep track of many variables, and deep closures like this make it work harder, slowing down general interpretation.

Rule 3.3: Avoid require() runarounds.

Rule 3.3.1: Any modules require()d should not require() to a depth of more than 3. Deep require() chains are expensive both in terms of memory usage and speed.

Rule 3.3.2: Core modules count as a single require(), no matter how many times they require() internally.

Rule 3.3.3: External modules count as a maximum of 2 require()s. We cannot afford the same leniency as with core modules, but can assume that module authors are writing efficient code.

Rule 3.4: Avoid synchronous calls at all cost. These often take a long time, and block the entire event loop from continuing.

How it can be abused:

Rules 3.1 and 3.3 do not work well together. By keeping a maximum of 1kb and 3 require()s down the chain, they will be hard-pressed to succeed.
Rules 3.2 and 3.4 are almost incompatible. 3.4 bans synchronous calls; 3.2 makes advanced asynchronous work difficult by limiting the number of callbacks.
Rule 3.4 is, in all honesty, a rule that is good to follow for real. 3.1, 3.2, and 3.3 are complete bogus.

Answer 4

JavaScript (ECMAScript)

7.3.2: Regular expression literals

Regular expression literals must not be used. Specifically, the source code must not contain any substring matching the RegularExpression nonterminal defined below.

RegularExpression     :: '/' RegularExpressionBody '/'
RegularExpressionBody :: [empty]
                         RegularExpressionBody [any-but-'/']

[empty] matches the empty string and [any-but-'/'] matches any single-character string except the one containing '/' (slash, U+002F).

Rationale

Regular expressions are often discouraged for readability reasons. It is often easier to understand code with traditional string operations rather than by resorting to regular expressions. More importantly however, many regular expression engines offer subpar performance. Regular expressions have also been associated with security issues in the context of JavaScript.

However, the Organization™ recognizes that regular expressions occasionally is the best tool for the job. Therefore, the RegExp object itself is not forbidden.

(The syntax of the grammar excerpt itself [not the one it defines] corresponds to that of the ECMAScript specification. This would of course be defined more rigourously at another point of the hypothetical specification.)

The trick

The following program is non-conforming:

// sgn(x) is -1 if x < 0, +1 if x > 0, and 0 if x = 0.
function sgn(x) {
  return x > 0?  +1
       : x < 0?  -1
       :          0
}

The productions for the RegularExpressionBody nonterminal given above shows a common way of expressing lists in BNF by relying on explicit recursion. The trick here is that I "accidentally" allow the empty string as a RegularExpressionBody, such that the string // is forbidden in the source code. But who needs single-line comments anyway? C89 and CSS seem to do all right while allowing only /* */ block comments.

Answer 5

C#

12.1 Static methods that affect the state of the program are forbidden

This is because it is hard to reliably test the results of a static method, especially one that changes some state.

12.2 Static methods must be deterministic

If the static method takes an input and gives an output the result must be the same each time the static method is called with the same input.

Why

The entry point for a C# program is the private static method 'main'. By the first rule this is now forbidden because the rule forgets to state that only public, protected or internal methods should follow this rule. If testing really is the concern only public methods should follow rule 1. Main may also break rule 2 as the program will give an error code if the program fails, this may occur independent of the input parameters. For example the program might not find a file or may have dependencies on other systems that are not setup correctly.

Answer 6

JAVA/SPRING

4.2 Use of Reflection in Production Code

Because Reflection can be used to access otherwise restricted parts of our source code use of reflection in Production Code is strictly prohibited.

The Trick

Spring technically uses reflection to instantiate and manage the objects that it supports. By enforcing this rule, all Spring utility would have to be removed.

Answer 7

Website encoding

666.13 UTF-8 must not be used and shall be replaced by UTF-7
Rationale: UTF-7 is more efficient than UTF-8, especially when targeting users from Arabic countries which we do.

How it can be abused:

HTML5 specifically disallows UTF-7. That means, modern browsers won't support it. If all the testing is done on a browser such as IE 11, nobody will notice this until it is too late.

Answer 8

JavaScript Bitwise Operators

1.9 You shall not use multiplication or division or flooring unless they are considerably faster than their bitwise counterparts. They shall be replaced by the bitwise operators <<, >> and ~~ respectively.
Rationale: The bitwise operators are more efficient.

How it can be abused:

Using << or >> instead of multiplication or division will cause troubles when handling large numbers. Also, they ignore operation precedence and decimal points. The double tilde will return different values when you give it a negative number.

Answer 9

JavaScript (ECMAScript)

7.3.1: Identifier conventions

Restrictions are placed on identifiers depending on what type of identifier it is. Identifiers are split into the types Variable, Constant, Function and Constructor; see 5.3. The restrictions are given below.

• Variable: The first character must be a lowercase letter character. Camel-case (see 1.3) should be used to separate words within an identifier.

• Constant: The identifier must consist of only uppercase letter characters and underscores ('_', U+005F). Underscores should be used to separate words within an identifier.

• Function: Functions must follow the same rules as the Identifier type.

• Constructor: The first character must be an uppercase letter character. Camel-case (see 1.3) should be used to separate words within an identifier.

Rationale

Readable identifier names is very important for maintainability. Restricting the identifiers to well-known conventions also eases transition between different code bases. These particular conventions are modelled after the standard conventions for the Java™ programming language [1].

The trick

I regret to inform the jQuery team that the most common name for their "global jQuery object" clashes with this name convention. Luckily, they've already thought of that and provide both $ and jQuery as global names referring to the same object. I imagine that the userbase might not be as keen to switch from $ to jQuery everywhere, though.