ソフトウェア企業では、さまざまな開発者が共同で記述したコードのコードの信頼性、移植性、そして最も重要な可読性を高めることを目標とするさまざまなコーディング標準が施行されています。

2つの注目すべき例は、MISRA Cと、JSFプロジェクト用に開発されたC ++標準です。

これらは通常、「must」、「shall」、「should」、「might」などの単語の意味を慎重に指定した後、次の形式になります。

例：

規則50：浮動小数点変数は、正確な等価性または不等価性についてテストされません。

理論的根拠：浮動小数点数は丸め誤差と切り捨て誤差の影響を受けるため、予想された場合でも正確な等価性が得られない場合があります。

これらのコーディング標準は、通常コンパイラの観点から合法であるコードに制限を課しますが、危険または読めないため、「有害と見なされます」。

これを悪用しましょう！

あなたはあなたの会社の小さな標準化委員会のメンバーとして受け入れられます。それは会社のすべての開発者が使用する必要がある新しいコーディング標準を設計することを目的としています。他の人には知られていませんが、あなたはひそかに不吉な組織を雇用しており、会社を妨害する使命を持っています。コーディング標準に1つ以上のエントリを提案する必要があります。これは、後で開発者の妨げになります。ただし、これをすぐに明らかにしないように注意する必要があります。そうしないと、標準に受け入れられない危険があります。

言い換えれば、正当であるように見え、委員会の他のメンバーに受け入れられる可能性が高いルールをコーディング標準に導入する必要があります。プロジェクトが開始され、コードに無数の工数が費やされた後、これらのルールを悪用できるようになります（たとえば、技術的または非常に文字通りの解釈）、そうでなければ通常の品質の良いコードに標準に違反しているというフラグを立てる したがって、彼らはそれを再設計するために多大な努力を払わなければならず、ルールはこの時点からそれらを妨げますが、ルールは現在かなり長い間アクティブであるため、純粋な勢いはこれらの役割を生き続け、重大な競合があるので異なるレベルの管理者間で関心がある場合、他のマネージャーはおそらくルールを守り続けるでしょう（彼らは間違いを認めるのは愚かなことでしょう！）、したがって会社を妨害します！ムワハハハハア！

得点

最初の有効なエントリーが勝ってから約2週間後の最高の回答。良い答えのアイデアはありますが、他の誰かが同じアイデアに出くわす可能性があるため、数日後に投稿します。もちろん、スコアに関係なく、私自身の答えは他のものよりも受け入れられません。

有権者は、抜け穴がどれだけ隠れているか、開発者がどれだけイライラするかに基づいて回答を採点することをお勧めします。

ルールと規則

• ルールは、上記の例のように専門的に書かれたように見える必要があります
• ルールは本物に見えるはずです（したがって、「すべての変数には少なくとも1つのアンダースコア、1つの大文字、1つの小文字、2つの数字が含まれている必要があります。」などは受け入れられません。委員会）そして彼らのメリットがすぐに明らかでない場合、あなたは良い根拠を与えるべきです。
• ルールを使用/悪用して、後で開発者を妨害する方法を見つけることができるはずです。他のルールのあいまいさを悪用したり、それ自体では無害であるが結合すると悪魔的な複数のルールを使用する可能性があります。
• ルールの悪用方法については、投稿の最後にスポイラータグで説明を投稿する必要があります
• 使用される言語は難解な言語であってはなりません。実際のプロジェクトで広く使用されている言語を選択する必要があるため、Golfscriptのようなものではなく、Cに似た構文の言語が優先されます。

C / C ++

規則1： 8進定数は使用しない

理論的根拠：8進定数は混乱の原因となります。たとえば、行を少し見ただけ const int coefficients[] = {132, 521, 013, 102};
では、配列内の数値の1つが8進数で定義されているという事実を見逃す可能性があります。

さらに邪悪になりたい場合は、以下を追加します。

規則 2：16進定数は、ビット操作のコンテキストでのみ使用されます。

根拠：定数が数値を表す場合、10進数であると読みやすくなります。16進定数は、数値ではなくビットマスクを表すことを示す必要があります。

悪用される方法：

配列の最初の10要素を追加する次の簡単なプログラムを使用します。このコードは標準に準拠していません。

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

つまり0、定義ごとに8進定数であることに注意してください。ルール1では、コード全体で0x00として記述する必要があるため、イライラします。ルール2により、さらにイライラさせられます。

Python

ルール1：-OOフラグを使用してすべてのコードをバイトコンパイルする必要があります。これにより、バイトコードが最適化されます。サイズと効率のために最適化されたバイトコードが必要です！

ルール2：テストは、実稼働環境に配置されるコードの同じ「アーティファクト」に対して実行する必要があります。監査人はこれを必要とします。

-OOremoves assertステートメントを使用します。ルール2と組み合わせるとassert、テストでのステートメントの使用が事実上禁止されます。楽しむ！

これはNode.JSプロジェクト用です。

セクション3-速度と効率が重要

ルール3.1：ファイルは最大1kbに保持する必要があります。これより大きいファイルは解析に時間がかかりすぎます。

ルール3.2： 3レベルを超える深さの関数をネストしないでください。V8エンジンは多くの変数を追跡する必要があり、このような深いクロージャーは動作を難しくし、一般的な解釈を遅くします。

ルール3.3：require()回り込みを避けます。

ルール3.3.1：すべてのモジュールrequire()dはrequire()3を超えてはなりません。深いrequire()チェーンは、メモリ使用量と速度の両方の点で高価です。

ルール3.3.2：コアモジュールはrequire()、require()内部で何度使用されても、単一としてカウントされます。

ルール3.3.3：外部モジュールは最大2 require()秒としてカウントされます。コアモジュールと同じ寛容さは許せませんが、モジュールの作成者が効率的なコードを書いていると想定できます。

ルール3.4：同期呼び出しは一切避けてください。これらは多くの場合、時間がかかり、イベントループ全体の継続をブロックします。

悪用される方法：

ルール3.1と3.3は一緒に機能しません。require()チェーンの最大1kbと3 秒を維持することで、成功するのが難しくなります。
ルール3.2と3.4はほとんど互換性がありません。3.4同期呼び出しを禁止します。3.2は、コールバックの数を制限することにより、高度な非同期作業を困難にします。
ルール3.4は、正直なところ、実際に従うのに適したルールです。3.1、3.2、および3.3は完全な偽物です。

JavaScript（ECMAScript）

7.3.2：正規表現リテラル

正規表現リテラルは使用しないでください。具体的には、ソースコードには、以下で定義されているRegularExpression非終端記号に一致する部分文字列を含めることはできません。

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

[empty]は空の文字列に一致し、[any-but-'/']は '/'（スラッシュ、U+002F）を含むものを除く任意の1文字の文字列に一致します。

根拠

読みやすさの理由から、正規表現はしばしば推奨されません。多くの場合、正規表現に頼るよりも、従来の文字列操作を使用してコードを理解する方が簡単です。ただし、さらに重要なことは、多くの正規表現エンジンが同等以下のパフォーマンスを提供することです。JavaScriptのコンテキストでは、正規表現もセキュリティの問題に関連付けられています。

ただし、Organization™は、正規表現がジョブに最適なツールである場合があることを認識してい ます。したがって、RegExpオブジェクト自体は禁止されていません。

（文法の抜粋自体の構文（定義されていないもの）は、ECMAScript仕様の構文に対応しています。もちろん、これは、仮説仕様の別のポイントでより厳密に定義されます。）

トリック

次のプログラムは不適合です。

// 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
}

上記の非終端記号RegularExpressionBodyの生成は、明示的な再帰に依存することにより、BNFでリストを表現する一般的な方法を示しています。ここでのコツは、空の文字列をRegularExpressionBodyとして「誤って」許可すること//です。そのため、文字列はソースコードで禁止されています。とにかく、単一行のコメントが必要なのは誰ですか？C89とCSSは/* */ブロックコメントのみを許可している間は大丈夫なようです。

C＃

12.1プログラムの状態に影響する静的メソッドは禁止されています

これは、静的メソッド、特に何らかの状態を変更するメソッドの結果を確実にテストすることが難しいためです。

12.2静的メソッドは確定的でなければなりません

静的メソッドが入力を受け取り、出力を与える場合、結果は静的メソッドが同じ入力で呼び出されるたびに同じでなければなりません。

なぜ

C＃プログラムのエントリポイントは、プライベート静的メソッド 'main'です。最初のルールでは、パブリック、保護、または内部メソッドのみがこのルールに従う必要があることを示すことを忘れているため、これは現在禁止されています。テストが本当に懸念事項である場合、パブリックメソッドのみがルール1に従う必要があります。プログラムが失敗した場合、プログラムはエラーコードを表示するため、メインはルール2にも違反します。たとえば、プログラムがファイルを見つけられなかったり、正しくセットアップされていない他のシステムに依存している場合があります。

JAVA / SPRING

4.2量産コードでのリフレクションの使用

Reflectionは、ソースコードの制限された部分へのアクセスに使用できるため、Production Codeでのリフレクションの使用は固く禁じられています。

トリック

Springは技術的にリフレクションを使用して、サポートするオブジェクトをインスタンス化および管理します。このルールを適用すると、すべてのSpringユーティリティを削除する必要があります。

ウェブサイトのエンコード

666.13 UTF-8は使用してはならず、UTF-7に置き換える必要があります。理由
：UTF-7はUTF-8よりも効率的です。特にアラビアの国のユーザーを対象とする場合は効率的です。

悪用される方法：

HTML5は特にUTF-7を許可しません。つまり、最新のブラウザではサポートされません。すべてのテストがIE 11などのブラウザーで実行される場合、手遅れになるまで誰もこれに気付かないでしょう。

JavaScriptのビット演算子

1.9乗算、除算、またはフローリングは、ビット単位のビットレートよりもかなり高速でない限り使用しないでください。これらは、ビット単位の演算子<<、>>、および~~にそれぞれ置き換えられます。
理由：ビット演算子はより効率的です。

悪用される方法：

乗算または除算の代わりに<<または>>を使用すると、大きな数を処理するときに問題が発生します。また、操作の優先順位と小数点を無視します。ダブルチルダは、負の数を指定すると異なる値を返します。

JavaScript（ECMAScript）

7.3.1：識別子の規則

識別子の種類に応じて、識別子に制限が課されます。識別子は、Variable、Constant、 Function、およびConstructorタイプに分割されます。5.3を参照してください。制限は次のとおりです。

• 変数： 最初の文字は小文字でなければなりません。 識別子内の単語を区切るには、キャメルケース（1.3を参照）を使用する必要があります。

• 定数： 識別子は、大文字とアンダースコア（ '_'、U+005F）のみで構成する必要があります。アンダースコアは、識別子内の単語を区切るために使用する必要があります。

• 機能： 機能は、識別子 タイプと同じ規則に従う必要があります。

• コンストラクター： 最初の文字は大文字でなければなりません。 識別子内の単語を区切るには、キャメルケース（1.3を参照）を使用する必要があります。

根拠

可読性の高い識別子名は、保守性にとって非常に重要です。識別子を既知の規則に制限すると、異なるコードベース間の移行も容易になります。これらの特定の規則は、Java™プログラミング言語の標準規則[1]をモデルにしています。

トリック

「グローバルjQueryオブジェクト」の最も一般的な名前がこの命名規則と衝突することをjQueryチームに知らせることを後悔しています。幸いなことに、彼らはそれをすでに考えており、同じオブジェクトを指すグローバル名として両方$を提供jQueryしています。ただし、ユーザーベースはどこ$からjQueryでも切り替えたいとは思わないでしょう。