あなたが従わなければならなかった最悪のコーディング標準？[閉まっている]

次のようなコーディング標準に取り組む必要がありましたか？

• 生産性が大幅に低下しましたか？
• 元々は正当な理由で含まれていましたが、元の懸念が無関係になってからずっと保持されていましたか？
• リストに載っていたので、それらをすべて覚えることは不可能でしたか？
• 著者は、優れたコーディングの実践を奨励するのではなく、単に彼らのマークを残そうとしていると思わせましたか？
• なぜ含まれているのか分かりませんか？

もしそうなら、あなたの最も好きではないルールとその理由は何ですか？

ここにいくつかの例

これはいくつかの羽を生む可能性がありますが、各メソッドの上部にあるテンプレートブロックコメントを義務付ける標準は、常に私からのくだらないことをバグにします。

1）更新中に気付くには実際の作業を行うコードから離れすぎているため、常に最新ではありません。悪いコメントはコメントなしよりも悪いです。

2）多くの場合、ソース管理ツールに既に含まれている情報を繰り返しますが、精度は低くなります。例：最終変更者、変更日/理由のリスト。

かつて教授に、コードの各行に少なくとも1つのコメントを要求したことがありました。

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

それはかなりばかげていた。

私たちの会社（C＃）コーディング標準では、＃REGIONの広範な使用が求められています（知らない人のために、Visual Studioで1行に折りたたまれるソースコードのブロックをマークします）。その結果、常にきれいに構造化されたクラスと思われるものを開き、＃REGION構文の深くネストされたラグの下にスイープされたゴミの山を見つけました。ロガーの1つの宣言を見つけるためにLOG領域を展開する必要があるなど、単一行の周りに領域がある場合もあります。もちろん、いくつかの領域が作成された後に追加された多くのメソッドは、「間違った」領域スコープにも配置されました。ホラー。ホラー。

リージョンは、Visual Studioに追加された最悪の機能の1つです。実際のオブジェクト指向構造ではなく、表面の構造化を促進します。

最近では、＃REGIONsを殺しています。

ある仕事では、データベースで奇妙な形式のハンガリー記法を使用せざるを得ませんでした。

詳細を思い出せませんが、メモリから、各フィールド名には以下を含める必要がありました。

• 母音なし
• すべて大文字
• テーブルへの参照
• データ型インジケータ
• データ長
• ヌル可能標識

たとえば、人の名を保持する列は次のように呼び出されます：（PRSNFRSTNMVC30X人テーブル、名列、Varchar 30文字、Not Null）

すべての中括弧の後に、中括弧の終わりについてのコメントが続くことを主張します。

例えば：

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For

#define AND  &&
#define OR   ||
#define EQ   ==

'言っ途切れる。

• ローカル変数名はすべてアンダースコアなしの小文字です

実際の例：paymentmethodtotalshtml、contracttypechangecontexts、customsegmentspectexts、potentialmsceventref

ニューヨークタイムズの重さ：

「単語スペースは当たり前だと考えるべきではありません。母音を特徴付ける最初のアルファベットである古代ギリシア語は、音を出せば単語スペースなしで解読でき、それらなしでした。[…]ラテン語も2世紀までに言葉を分けるのをやめました。目が分離されていないテキストを読むためにもっと一生懸命に働かなければならないので、損失は不可解です。しかし、古文書学者のポール・センガーが説明したように、古代世界は「読書をより簡単で迅速にする」ことを望みませんでした。」

私は「やるために会社のソフトウェアのリーダーで頼まれたシンプルな、再nは dundantコードを」。たとえば、既存の関数に新しいパラメーターを追加することは禁止されていました。代わりに、回帰を回避するために元の関数をそのままにして関数を複製する必要がありました。もちろん正式なテストはありません（時間の無駄）。

マージソフトウェアの使用も禁止されていました。各ファイルは一度に1人のプログラマのみが変更できます。もちろん、リビジョン管理ソフトウェアはサイエンスフィクションでした。

私の人生で一番幸せな日は、彼が解雇されたときでした（イタリアで誰かを解雇することは非常に難しいと考えてください）。

データベースとのすべての対話は、ストアドプロシージャを介して実行する必要があります。私たちが2010年ではなく1997年に住んでいるなら、それは理にかなっているかもしれません。

私は、これが実際に元の質問のすべての基準をカバーしていることに気付きました。

• 生産性が大幅に低下しましたか？小切手。ORMを使用してください。
• 元々は正当な理由で含まれていましたが、元の懸念が無関係になってからずっと保持されていましたか？小切手。マネージャーは1000年前にデータベースサーバーの開発者であり、このコーディング標準を取り入れました。
• リストに載っていたので、それらをすべて覚えることは不可能でしたか？小切手。これには、「できるだけ多くのロジックをデータベースに保存する必要があります」が含まれます。
• 著者は、優れたコーディングの実践を奨励するのではなく、単に彼らのマークを残そうとしていると思わせましたか？小切手。元データベースサーバー開発者であるマネージャーに戻り続けます。
• なぜ含まれているのか分かりませんか？小切手。

CTOは「私たち」がより良く、より速くできると信じていたため、STLまたは他の標準C ++ライブラリの使用を許可されていません。リストや文字列クラスなどの基本的な構成要素です。

ハンガリー記法

MSDN の「Charles Simonyiによるハンガリー語表記識別子の命名規則の説明」から抽出したサンプル。

1 #include“ sy.h”
2 extern int * rgwDic;
3 extern int bsyMac;
4 struct SY * PsySz（char sz []）
6 {
7文字* pch;
8 int cch;
9 struct SY * psy、* PsyCreate（）;
10 int * pbsy;
11 int cwSz;
12符号なしwHash = 0;
13 pch = sz;
14 while（* pch！= 0
15 wHash =（wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy =＆rgbsyHash [（wHash＆077777）％cwHash];
18 for（; * pbsy！= 0; pbsy =＆psy-> bsyNext）
19 {
20文字* szSy;
21 szSy =（psy =（struct SY *）＆rgwDic [* pbsy]）-> sz;
22 pch = sz;
23 while（* pch == * szSy ++）
24 {
25 if（* pch ++ == 0）
26リターン（psy）;
27}
28}
29 cwSz = 0;
30 if（cch> = 2）
31 cwSz =（cch-2 / sizeof（int）+1;
32 * pbsy =（int *）（psy = PsyCreate（cwSY + cwSz））-rgwDic;
33 Zero（（int *）psy、cwSY）;
34 bltbyte（sz、psy-> sz、cch + 1）;
35 return（psy）;
36}

私はかつて、プロジェクトリーダーがすべての変数（すべての変数）の前に「v」を付けることを義務付けているプロジェクトに取り組んでいました。したがって、vCount、vFirstName、vIsWarrantyなど。

どうして？「私たちはVBScriptで作業しており、とにかくすべてがバリアントであるため」

WTF。

ほとんどこれを忘れました：

マネージャーからの引用：

独自のコードで見つかった問題のバグを修正または文書化しないでください。顧客は、今後数年間にわたってそれらを特定して修正するために私たちに支払います。

これは消費者向けソフトウェアではなく、単一の大規模組織向けのカスタムです。言うまでもなく、顧客はその後何年も支払いました。些細なことのように見えるかもしれませんが、バグを見つけようとするよりも、バグを無視しようとする方が困難です。

すべての非プライベートメソッド、定数、列挙、およびプロパティにXMLコメントを適用しました。

特に最終結果は///を押すだけですべての空のコメントスタブを作成するか、GhostDocをインストールして自動生成されたコメントを追加することになるため、コードがかなり乱雑になりました。

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

[編集]これをばかげた標準として言及する理由は、メソッドのコメントが愚かだと思うからではなく、これらのコメントの品質が何らかの方法で強制されず、コードファイルに大量の混乱が生じるだけだからです。盲目的な「コメントが必要」ビルド要件よりも、意味のあるコードドキュメントを作成するより良い方法があります。

実際にはコーディング標準ではありませんが、ソース管理に「changelog.txt」というファイルがありました

チェックインを行うたびに、このファイルにエントリを手動で追加する必要がありました。このエントリは、サブバージョンのリビジョン番号とチェックインコメントでした。

新しいCTOが始まり、誰かが彼にこれを言ったとき、彼はすぐにエグゼクティブの決定を下し、「もうこれをやるつもりはない」と言ってファイルを削除しました。これは何年も続いていました。

私が協力してきた場所のいくつかは、未使用または非推奨のコードを削除するのではなくコメントアウトすることを主張していました。履歴などについてVCSを信頼する代わりに、コメントアウトされたコードによってファイル内で痛々しいほど維持されました。

これに関して私が見つけた大きな問題は、コードがコメントアウトされた理由がよくわからないということです。それは、一部の開発者が積極的に変更を加えていて、参照のためにそれを保持したいのか、それとももはや必要ではなかったのですか？

私がこれまで参加した中で最悪のコーディング標準は、まったくないコードベースです。私は、まったく存在しないコードベースで作業するよりも、完全に反対するコーディング標準に従います。コードベースの新しい部分を習得するのがずっと難しくなります。

バージョン管理のためのインラインコメントの強制は、私が無視した最も無意味なコーディング標準に関するものでした。

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

200を超えるフィールドと40のトリガーを持つ競合の激しいテーブルでデータベースを「維持」しながら、空白の正しい使用を主張したOracle DBAが間近に迫っています。

すべてのクラスメンバー関数の前にクラス名と可視性を付けることを決定したC ++の最初のタイマーが率いるプロジェクトでコードレビューを行いました。

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}

すべてのコードを4つのスペースでインデントする必要があります;）

私は何年も前に、すべてのコードを左揃えにする必要があり、インデントなしで仕事をしていました。そのポリシーを思いついた男は、長いコード行を表示するときに水平方向に前後にスクロールしなければならないことを嫌い、目でピンポンを演奏していると見なしました。

これは、コーディング標準がないことがいかに痛いのかという例です。

大手銀行で働いている請負業者は、この基準に従うことが史上最高だと主張しました。このアプリケーションはdBase / Clipperで書かれており、彼は彼が唯一の開発者であり、もちろん彼は標準を思いつきました。

• すべて大文字です。彼が行ったまれなコメントを含む、すべてを意味します。
• インデントなし。
• 変数の命名は、APRGNAMEに沿ったものでした。A =変数のスコープ、たとえばPはパブリック、PRG =変数を作成したソースファイルの最初の3文字、NAME = dBase / Clipperが許可した残りの6文字の変数名。
• ソースコードの最初の4行と最後の4行は80 *長でした。どうして？そのため、ドットマトリックスプリンターがファイルの印刷を開始および終了するのを聞くことができました。メモリは、プログラム全体が毎週メインフレームを介して20,000ページ印刷されたものです。
• 私は自分の脳から何とかして捨てたものがもっとたくさんあると確信しています。

私はその段階で非常に新しい独学のプログラマーでしたが、プロジェクトを引き継ぐように依頼する前に、気違いの科学者に耳を傾けて地獄から抜け出せないほど十分に知っていました。

そして、はい、私たちはこれらの慣行がどれほど悪いかを経営者に話しましたが、いつもいつも「この請負業者に彼が話していることを知らなければならない最高のドルを支払っていました」。

私の過去からのもう一つの爆発。

会社の所有者からの引用：

Javaで書かれた{expletive}プロジェクトで2500万を失ったため、解釈言語を使用して記述されたコードはありません。

Javaプロジェクトは、数十の株を処理するように設計された株取引システムであり、現在では数千を処理するために使用されています。設計上の欠陥や貧弱なハードウェアに対処する代わりに、会社全体がすべての非C / C ++アプリケーションをC / C ++に変換することを余儀なくされ、すべての新しい開発はC / C ++で行わなければなりませんでした。解釈言語はコンパイルされていないものを意味し、所有者はアセンブラー、C、C ++のコンパイルのみを検討しました。

コードの大部分がJavaとPerlである800人の会社にとって、これは会社全体が今後数年間でC / C ++で完全にすばらしいコードを書き直すことにほとんどの時間を費やすことを意味しました。

面白いことに、この大失敗の約20年前、私は別の会社にいました。この会社では、ソートロジック（バブルソート）をクイックソートに置き換えるのではなく、アセンブラーで再コーディングする必要があると技術リーダーが判断しました。パフォーマンスを改善しません。パフォーマンスを改善する唯一の方法は、アセンブラーで同じロジックを書き換えることです。

どちらの場合も、口述が下がってすぐに私は去りました。

多くのプログラマーと同じように（しかし十分ではありませんが）、コード装飾は嫌いです。ゲッター/セッターがなくても、変数名にドル記号（$）プレフィックスを使用したり、プライベート変数にアンダースコアを使用したりする必要がある場合、私を怒らせます。それを理解するためにコードを装飾する必要がある場合、あなたは地獄を抜け出す必要があります！

私はしばらくの間、渡されたすべてのパラメーターにP1、P2、P3などの名前を付ける必要があったWebシステムで作業していました。

また、厳密にはコーディング標準ではありませんが、同じシステムでは、すべてのファイルにxyz0001.ext、xyz0002.ext、xyz0003.extなどの名前が付けられていました。xyzはアプリケーション自体のコードでした。

これはずっと前-正確には1976年です。上司はEdsger Dijkstraのことを聞いたことも、CACMの問題を読んだこともありませんでしたが、どこかから「GOTOが悪い」という噂を聞いたため、COBOLプログラムでGOTOを使用することは許可されませんでした。これは、COBOLが「end if」を追加する前でした。そのため、当時は3つの古典的な制御構造（シーケンス、if / then / else、実行（つまり、do while））のたった半分しかありませんでした。彼は、基本プログラムでGOTOを許可し、アセンブラー言語プログラムで分岐命令を許可しました。

これは一種の「あなたがそこにいなければならなかった」物語であることにごめんなさい。私の知る限り、1976年以降に発明されたすべての言語には適切な制御構造があり、GOTOを使用する必要はありません。しかし、要点は、ボスはなぜGOTOが有害であると考えられたのか、どの言語が乳児障害であり、どの言語が致命的な病気であるのかを決して知らなかったということです。

プロジェクトで働いたのは、チーフアーキテクトが明示的なコードを（あまりにも）書くことを要求したときでした。コードで見つけた最悪の例の1つ（そして彼は喜んで承認しました）は次のとおりです。

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

ReSharperでさえ、これは間違っているとあなたに言った！

私の最後の仕事では、「標準」は、私を雇った男から与えられたものの非常に強い用語です。ColdFusionとSQLでWebサイトをプログラミングすると、次のようなコーディング要件が与えられました。

• includeを使用しないでください。1つの大きなページが好き
• 変数名と列名の単語は常にアンダースコアで区切ります（isactive、firstnameなどを除く）
• 略語を使用しないでください-常にファーストネームを書きます（頻繁にfnameなどを書きました）
• 紛らわしい名前（amount_chargedやcharge_amountなど、異なるが関連するものを測定したもの）を使用しないでください。
• DIVを使用せず、最小限のCSSを使用します。代わりにネストされたテーブルを使用します（一度に6層の深さが見つかりました）。
• クエリをキャッシュしないでください。今まで。
• 複数のページで変数を使用しますか？アプリケーションの範囲。
• 各ページは、独自のtry / catchブロックです。グローバルエラーハンドラは不要です。

彼が辞めたらすぐにこれらを変え始めました。

私のC ++コーダーとしての生活の中で、2つの非常に厄介な「ルール」が実施されました。

1. 「VC ++ 4.1ではサポートされていないため、STLは使用できません（現時点ではVC ++ 6.0に切り替えることはできません）。」
2. 「QuickSortを使用しないでください。不適切な場合はO（n ^ 2）になる可能性があります。HeapSortアルゴリズムのこの実装を使用してください。

すべてのクラスとクラスメンバーのXMLドキュメントを強制的に作成します。プライベートを含む。デフォルトのghostdocコメントを使用することをお勧めします。

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}