プログラミングに携わっている間、ファッショナブルなさまざまなルールと慣行を熱狂的に順守していたため、曲がったプロジェクトがかなり見られました。 OOPやTDDなど、チーム全体を魅了するもの、または別の開発者が主張したもの（例：スペースに対するタブ、または特定のスタイルの中括弧）。 一人で作業するプログラマでさえ、生産性を損なうフェチを選択することでプロジェクトを妨害することができます。
プログラミングには数時間から数日かかる場合があります。
- スペースに対するタブ。 いくら賭けますか？
- 中括弧スタイル
- CamelCase、mixedCase、アンダースコア
- 可変命名規則、特にハンガリー語表記
- 機能は50行または100行を超えることはできません。または、機能は複数の画面にすることはできません。
- GOTO、eval、演算子のオーバーロード、シングルトーン、および悪と見なされる他の言語機能を使用しないでください。
- 関数には出口点が1つしかありません。
- グローバル変数なし
- OOPのみ、関数型プログラミングのみ
- 設計パターン
- TDD（テストによる開発）
- ガントチャート、アジャイル、スクラム、エクストリームプログラミング、ユーザーストーリー
- SQLストアドプロシージャを使用したり、SQLストアドプロシージャにすべてのロジックを実装したりしないでください
- SQL vs NoSQL
- PHPタグの記述に短い形式を使用しないでください
- すべてのWebインターフェイスはRESTfulである必要があります
- HTMLコードはW3C検証に合格する必要があります
- 厳格なXHTML
上記のすべてが悪いわけではありません。 そして一般に、チームのプログラマーにとっては、コードがチームの他の部分に理解され、システム全体と結合されるように、いくつかの一般的な規則に従うことが重要です。 問題は、プログラマーまたはチームが、開発そのものよりもルールの順守が重要であると判断したときに始まります。 誰かがアプリケーションの代金を支払うとき、コードでどのようなインデントを使用するかは実際には関係ありません。 プログラマーは、シングルトーンを使用するのが悪いかどうか、すべての変数名が誰かの好みの慣習に対応しているかどうかについての論争に多くの時間を費やさないことが顧客にとって重要です。
問題はプログラミングにおけるカーゴカルトと同様です。 経験の浅いプログラマーが、なぜそうするのか理解せずに何かをするのは非常に悪いことです。 さらに悪いことに、経験豊富なプログラマーが個人的な好みをフェチに変え、彼と一緒に働くすべての人がプロジェクトに何らかのリスクを意味する場合でも、従うことを強制します。
過去数年にわたって、私は、プログラマーと顧客がコスト超過、期限、または不当な期待のために分裂した後に放棄されたコードで多くの仕事をしてきました。 動作しないコードもありますが、コメントにはGang of Fourパターンへのリンクがたくさんあります。 ライブラリの記述が不十分で、これはプログラマが標準名が悪いと判断したために存在します。 さまざまな技術的ソリューションの正当性にあふれた仕様が見られますが、ビジネスロジックについては何も言えません。
また、特別なインデント、特定のスタイルの中括弧、変数の命名規則などを使用しないコードをよく見ます。 このようなコードを私の美的趣味に合った形にするのに私が費やした時間は、クライアントのお金の無駄に過ぎません 。 「自分の好みではない」と書かれたコードは、自分のコードよりも読みやすく、サポートするのが難しいことはありませんでした。
方法論、技術、および「ベストプラクティス」は、問題を解決するために理解および使用される必要がありますが、崇拝の主題になりません。 有用なコードを書くよりも変数の命名について同僚（または自分）と議論するのに多くの時間を費やすなら、フェティッシュ指向のプログラミングに時間を費やします。