あなたが従わなければならなかった最悪のコーディング標準？
次のようなコーディング標準に取り組む必要がありましたか？
- 生産性が大幅に低下しましたか？
- 元々は正当な理由で含まれていましたが、元の懸念事項が無関係になった後も長い間保管されていましたか？
- 長い間リストにあったので、すべてを覚えることは不可能でしたか？
- 作者が優れたコーディング実践を奨励するのではなく、単に印を残そうとしているだけだと思いましたか？
- なぜそれらが含まれているのか分かりませんでしたか？
もしそうなら、あなたの最も好きではないルールは何ですか、そしてなぜですか？
いくつかの例 ここ
これはいくつかの羽毛を混乱させるかもしれませんが、各メソッドの上部にあるテンプレート化されたブロックコメントを義務付ける標準は、常に私をがらくたにします。
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つです。実際のOO構造ではなく、表面の構造化を促進します。
今日、私は#REGIONsを目にして殺します。
ある仕事では、データベースで奇妙な形式の ハンガリー語表記 を使用せざるを得ませんでした。
詳細を思い出せませんが、メモリから、各フィールド名に以下を含める必要がありました：
- 母音なし
- すべて大文字
- テーブルへの参照
- データ型インジケーター
- データ長
- ヌル可能インジケーター
たとえば、人の名を保持する列は次のように呼び出されます：PRSNFRSTNMVC30X（Personテーブル、First Name列、Varchar 30文字、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世紀までに言葉を分けることをやめました。分離されていないテキストを読むために目がはるかに努力する必要があるため、損失は不可解です。しかし、古文書学者のポール・センガーが説明したように、古代の世界は「読書をより簡単かつ迅速にすること」を望んでいませんでした。」
企業のソフトウェアリーダーから、「シンプル、再んdundant code "。たとえば、既存の関数に新しいパラメーターを追加することは禁止されていました。代わりに、関数を複製し、元の状態のままにして回帰を回避する必要がありました。もちろん、正式なテストはありません（無駄な時間）。
マージソフトウェアの使用も禁止されていました。各ファイルは、一度に1人のプログラマのみが変更できます。もちろん、リビジョン管理ソフトウェアはSFでした。
私の人生で最も幸せな日は彼が解雇されたときでした（イタリアで誰かを解雇するのは非常に非常に難しいと考えてください）。
データベースとのすべての対話は ストアドプロシージャ を介して行う必要があります。私たちが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 char * pch;
8 int cch;
9 struct SY * psy、* PsyCreate（）;
10 int * pbsy;
11 int cwSz;
12 unsigned 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 char * szSy;
21 szSy =（psy =（struct SY *）＆rgwDic [* pbsy]）-> sz;
22 pch = sz;
23 while（* pch == * szSy ++）
24 {
25 if（* pch ++ == 0）
26 return （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」というファイルがソース管理にありました。
チェックインを行うたびに、このファイルにエントリを手動で追加する必要がありました。このエントリは、Subversionのリビジョン番号とチェックインコメントです。
新しい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つのスペースでインデントする必要がある;）
私の過去からのもう1つの爆発。
会社のオーナーからの引用：
Javaで記述された{expletive}プロジェクトで2,500万を失ったため、解釈言語を使用して記述されたコードはありません。
Javaプロジェクトは、数十の株を処理するように設計された株取引システムでしたが、現在は数千の処理に使用されています。設計の欠陥や貧弱なハードウェアに対処する代わりに、会社全体がC/C++以外のすべてのアプリケーションをC/C++に変換し、すべての新しい開発はC/C++で行う必要がありました。解釈言語はコンパイルされていないものを意味し、所有者はアセンブラー、CおよびC++のコンパイルのみを考慮しました。
ほとんどのコードがJavaおよびPerlに含まれていた800人の会社の場合、これは会社全体が次の2、3年にわたってほとんどの時間をC/C++。
おかしなことに、この大失敗の約20年前、私は別の会社にいて、技術リーダーがクイックソートに置き換えるのではなく、アセンブラーでソートロジック（バブルソート）を再コーディングする必要があると決定しました-- アルゴリズムはパフォーマンスを向上させません。パフォーマンスを向上させる唯一の方法は、アセンブラーで同じロジックを書き換えることでした。
どちらの場合も、命令が下がった直後に私は去った。
これは、コーディング標準がないとどのように害を及ぼす可能性があるかを示す例です。
大手銀行で働いている請負業者は、基準に従うことがこれまでで最高だと主張しました。アプリケーションはdBase/Clipperで作成され、彼は唯一の開発者であり、もちろん標準を思いつきました。
- すべて大文字です。彼がした珍しいコメントを含むすべてを意味します。
- インデントなし。
- 変数の命名は、APRGNAMEに沿ったものでした。 A =変数のスコープ、たとえばPはパブリック、PRG =変数を作成したソースファイルの最初の3文字、NAME = dBase/Clipperで許可されている残りの6文字の変数名。
- ソースコードの最初の4行と最後の4行は80 *の長さでした。どうして？したがって、ドットマトリックスプリンターがファイルの印刷を開始および終了するのを聞くことができました。メモリは、プログラム全体がメインフレーム経由で毎週20,000ページ印刷されたものです。
- 脳から捨てることができたものはもっとたくさんあったと思います。
私はその段階で非常に新しい独学のプログラマーでしたが、私がプロジェクトを引き継ぐように頼む前に、狂った科学者の話を聞いて地獄から抜け出せないほど十分に知っていました。
はい、私たちは経営陣にこれらの慣行がいかに悪いかを話しましたが、いつも「この請負業者に、彼が話していることを知らなければならない最高のドルを払っていた」という常識を得ました。
多くのプログラマーのように（しかし十分ではありません）、私はコードの装飾が嫌いです。ゲッター/セッターがなくても、変数名にドル記号（$）プレフィックスを使用したり、プライベート変数にアンダースコアを使用したりする必要がある場合、私は腹立たしいです。それを理解するためにコードを装飾する必要がある場合は、地獄を取り除く必要があります！
これはずっと前のことです-正確には1976年。私の上司はEdsger Dijkstraについて聞いたり、CACMの問題を読んだりしていませんが、どこかから「GOTOが悪い」という噂を聞いていたため、COBOLプログラムでGOTOを使用することはできませんでした。これは、COBOLが「end if」を追加する前だったので、当時は3つの古典的な制御構造（シーケンス、if/then/else、実行（つまり、do while））の2つと半分しかありませんでした。彼は私たちの基本プログラムでGOTOを容赦なく許可し、アセンブラー言語プログラムで分岐命令を許可しました。
これは一種の「あなたはそこにいなければならなかった」物語です。私の知る限り、1976年以降に発明されたすべての言語には、GOTOを使用する必要がないように適切な制御構造があります。しかし要点は、上司はなぜGOTOが有害であると考えられたのか、どの言語が乳児障害であり、どの言語が致命的な病気であるのかを決して知らなかったことです。
私がプロジェクトで働いたのは、（あまりにも）明示的なコードを書くことを建築主任から要求されたときでした。私がコードで見つけた（そして彼が喜んで承認した）最悪の例の1つは次のとおりです。
private string DoSomething( bool verbose )
{
if ( verbose ) { return someString; }
else if ( !verbose ) { return otherString; }
else { return string.Empty; }
}
でも ReSharper はこれが間違っているとあなたに言いました！
私はしばらくの間、渡されたすべてのパラメーターにP1、P2、P3などの名前を付ける必要があるWebシステムで作業してきました。詳細なドキュメントがなければ、何がどこにあるかを知ることはできません。
また、厳密にはコーディング標準ではありませんが、同じシステムでは、すべてのファイルにxyz0001.ext、xyz0002.ext、xyz0003.extなどの名前を付ける必要があり、xyzはアプリケーション自体のコードです。
私の最後の仕事では、「基準」は私を雇った男から私に与えられたものを表す非常に強力な言葉になります。 ColdFusion およびSQLでWebサイトをプログラミングすると、次のようなコーディング要件が与えられます。
- インクルードは使用しないでください。大きなページが好き
- 変数名と列名の単語は常にアンダースコアで区切ります（isactive、firstnameなどを除く）。
- 省略形を使用しないでください-常に名を書き留めます（彼はfnameなどを頻繁に書きました）
- 紛らわしい名前を使用しないでください（amount_chargedやcharge_amountなど、異なるが関連するものを測定したもの）
- DIVs を使用せず、最小限の [〜＃〜] css [〜＃〜] を使用する-代わりにネストされたテーブルを使用する（6層の深さを1回見つけた） 。
- クエリをキャッシュしないでください。ずっと。
- 複数のページで変数を使用しますか？アプリケーションのスコープ。
- 各ページは独自のtry/catchブロックです。グローバルエラーハンドラーは必要ありません。
彼が辞めるとすぐに私はこれらを変え始めました。
ほぼ変数のタイプ、可変性、スコープ/ストレージクラス、および/またはそれらの参照を繰り返す、あらゆる種類の変数命名規則。基本的に、言語に固有の構成要素。これは21世紀の最新のIDEではもはや必要ありません（そして私の考えでは、元々貧弱なコードレイアウト/プラクティスを解決するだけでした）。これには、ハンガリー語表記とその変形が含まれます。
- bigBlobStr-文字列。
- bigBlobStrCurLocPtr-上記の文字列の「現在の場所」へのポインタ。
- someIntArray-整数の配列
または次のようなもの：
- e_globalHeading-外部変数
- sg_prefPoolSz-静的グローバル変数
そしてもちろん、OOPで最も遠くに届く目障りなもの、すべてのメンバーにとってm_。どの変数がローカル、メンバー、グローバル、静的、またはfinal/constであるかわからない/追跡できない場合は、mightが不明確になっている、因数分解が不十分なスパゲッティコード。
これは、min、max、avg、size、count、indexなどの接頭辞/接尾辞の規則を指定する場合とはまったく異なります。
すべてのクラスとクラスメンバーのXMLドキュメントを用意する必要があります。プライベートを含む。デフォルトのghostdocコメントを使用するように勧められています。
public class User
{
/// <summary>
/// the _userID
/// </summary>
private int _userID;
}
私が今まで直面しなければならなかった最悪の基準：
StyleCop C＃の場合
これまで無意味なすべての標準を取り、設計時にIDEではなく、コンパイル時に実行するツールに入れます。
//this is not a legal comment.
// nor is this
//の後には単一のスペースが必要です。デバッグする場合は、////を使用してコードにコメントを付けます。プロパティには「トリプルスラッシュ」のコメントも必要で、最後にピリオドを付けた「Gets or Sets xxxxx」と読み、正しく大文字にする必要があります。
ああ。多分広く公開されているAPIにポイントがあるかもしれませんが、私の主な牛肉は、それらが確かにR＃のプラグインとしてそれを構築できたということです。
私は日本で短時間働きました。複雑な数学的コーディングを行っていました。会社のコーディング基準には、コメントは一切ありませんでした。複雑な計算を説明するコメントをいくつか追加し、数週間後に自分を忘れないようにしたかったので、それは困難でした。コードが何をしているかを理解するために私の後に来る次の男に同情してください。
コーディングのコメントが禁止されたのは初めてのことでした。
前のジョブでは、C＃標準では、宣言内の型名と変数名の間に少なくとも2つのスペースが必要でした。メソッド名は、アクセス修飾子と戻り値の型の次の行で開始する必要があります。スペースは、句読点の前に置く必要があります。 （かっこまたは角かっこ）、メソッドの最初のすべての変数宣言、割り当てとは別の宣言、インデントは3つのスペースでした。例：
private static int
ThisIsTheMethod (int code, string message)
{
int i;
int j;
int k;
for (i = 0; i < message.Length; i++)
{
if (message [i] == '!') return -1;
}
j = SomeMethod (code);
k = OtherMethod (j);
return k;
}
醜いが、それはVisual Studioが本当にそのように物事を望んでいないことを除いて実行可能であり、それを「通常のように」コーディングした後、それをこのように再フォーマットするための追加のステップでした。
3か月前に喜んで辞職した前職で：
データベース：
- テーブル名は大文字でなければなりませんでした。
- テーブル名の前にTBL_を付ける必要がありました
- フィールドにプレフィックスを付ける必要がありました：DS_（varcharの場合、意味がありません）NU_は数値CD_は（「ビットフィールド」）DT_は日付
- データベースフィールドも大文字でなければなりませんでした[CD_ENABLED]
- sp名[SP_INFINITY_USER_GROUPS_QRY]およびデータベース名[INFINITY]と同じ
- spの名前が実際にそのようなものだったとは言ったかSP_プレフィックス、次にデータベース名SP_INFINITY_、次にテーブル名、SP_INFINITY_USER_GROUPS、そして実際にspが期待すること（QRY、UPD、DEL、INS）のイエス、CRUDクエリだけではないクエリから始めないでください。
- すべてのテキストフィールドは、明確にvarchar（MAX）である必要がありました。
- 他の型を使用できたとしても、数値はintまたはdoubleでした。
- 「ブール」フィールド（ビット）はintであり、理由はありません。
- ストアドプロシージャには、sp_productname_というプレフィックスを付ける必要がありました。
asp.net/c＃/ javascript
- すべての単一の関数をtry {} catch {}でラップする必要があったため、アプリケーションが「爆発」しませんでした（少なくともそれが公式の理由でした）。
- パラメータの前にpを付ける必要があります（pCount、pPageなど）。
- スコープ変数の前にwを付ける必要がありました（ "working"のように、それは一体何を意味しているのでしょうか？）
- gによる静力学など.
- とにかくlinqとジェネリックスを実際に使用していたように、フレームワーク1.1以降のすべてが立ち入り禁止でした。 （ただし、jqueryを使用できるように強制することを強調しましたが、少なくともそれは成功しました）。
SCCが時代遅れのバージョンのPVCSである場合の$ Log $情報の必須の包含、拡張。$ Log $情報が多く、実際のコードよりもはるかに長いファイルがいくつかありました。
PHPスクリプトのすべての出力は、行ごとにエコーする必要があります。
<?php
echo "<div id=\"foo\">";
echo "<h1>" . $title . "</h1>";
echo paragraphs($body); // just an example
echo "</div>";
?>
（免責事項：私はそれに従う必要はありませんでしたが、私が一緒に働いたチームはそうしました。）
最悪は、クラスの前にモジュールの省略形が付けられたプロジェクト（C++）でした。
たとえば、MessagePassingモジュールに何かがあり、Responseメカニズムの一部である場合、MESPAS_RESSomeobjectと呼ばれることがあります。
そのコードに取り組んだので、目を丸くしたくなりました。
最悪ではありませんが、私の現在の仕事では、クラスにc_プレフィックスと列挙型にe_プレフィックスが必要です。構造体には何もありません。しかしtypedefの_t postfix。それもかなり醜いです。
ああ、もちろん.hと.cpp（宣言と定義）の両方の関数ヘッダーコメントは、ほとんど一致しません。
私のお気に入りは、無知に適用された「マジックナンバーなし」ルールです。たとえば、コードレビューで「マジックナンバーはありません」というルールが次のコード行に違反しているというコメントを見たことがあります。
if (fscanf(file, "%s %hd",name, nbrObject ) != 2 )
私はレビュアーが#define TWO 2のような2ではなく定数を望んでいたと思います
メソッド名は、「Get/Set/Add/Delete」+ターゲットオブジェクトの名前+すべてのパラメーターの名前の形式である必要があります。
GetUserById(userId);
InsertUser(user);
DeleteUser(user);
十分に公正ですが、ルールは非常に厳格です。複雑なオブジェクトタイプの省略は許可されておらず、操作がどんなにばかげていても、常にすべての要求パラメーターをリストする必要がありました。
GetCustomerOrderDeliveryDetailsByCustomerIdAndDeliveryDateAndOrderStatus(...
完全な変数名（短縮することもできませんでした）を追加した後、いくつかの単純なメソッド呼び出しがどれくらいの長さであったかを想像できます。言葉は折り返し長い。
ここで私が作業している場所は、データベースを処理するための変数の命名プロセスです。
- ステートメントの$ sql
- クエリ結果の$ result
これは理にかなっていますが、慣例があまりに一般的であり、これが変数のオーバーラップで終わるという点を私が持ち出したとき、応答は「use result_altまたはsql_alt」でした。コメントに対する私の気持ちですが、目的を示す適切な変数名を使用した場合、コメントは必要ありません。
私が従わなければならなかった最悪のコーディング標準は、「すべてのオブジェクト変数名の前に「obj」を付ける必要がある」でした。これは大きなJava=プロジェクトなので、ほとんどすべてがオブジェクトでした。最悪の部分は、 "obj"を前に付けるだけで変数に名前を付けるというポリシーを採用したことですコード全体でPerson objPerson1のようなもので締めくくりました。私は一度反対し、他の開発者の1人に、「変数について考える必要がないため、彼女がこの規則を気に入っていると間違えました。名前」。その場所は本当にホラーショーだった...
多分Huawei Software Companyのコーディング標準。彼らはあなたにすべてのメンバーを公開することを望んでいます:)）
Fortran （ [〜＃〜] watfor [〜＃〜] 、 FORTRAN 77 ）に何かを書き込む場合、1列目に空白以外の文字があるコメントであり、72カラムを超えてもコンパイラは警告を発しませんでした。黙って無視します。
少なくとも私はこれを行うのに7年しか費やしませんでした。
Javaプロジェクトで、Cヘッダーファイルに相当するものを持っています。
いくつかの正当な理由でインターフェースが存在しますが、この標準はインターフェース（foo.Java）すべてのクラス（fooImpl.Java）意味があるかどうか。同期を維持するための多くの要素、Eclipseのメソッドへのクリックインメソッドの完全な中断、無意味な忙しい作業。
ビルドシステムはそれを強制しましたが、私は本来の目的が何であったか想像できません。幸い、新しいバージョン管理とビルドシステムに切り替えたときに、新しいコードのためにそれを捨てましたが、それでもまだ多くのことが残っています。
同時に、必須であった愚かなバージョン管理情報情報ファイルコメントの習慣も捨てました。
私は現在、SQLクエリが「リクエストクラス」と呼ばれるものを介して行われる会社で働いています。とんでもない：
「include/request.class.php」内
class RequestClass
{
// ... some code.
public function getUser($where)
{
global $initrequest
$sql = $initrequest['users']
$sql.= $where;
return execute($sql);
}
}
Initrequest.phpで：
$initrequest['users'] = 'SELECT * FROM users WHERE ';
そして、アプリケーションから次のように呼び出されました。
$request = new request();
$tmpquery = "username = $username AND password = $password";
$request->getUsers($tmpquery);
そして、それらは「ブロック」に基づいた同様のテンプレートシステムを持っていますが、私がここに示すものを理解した後、私はソフトウェア全体をゴミ箱に捨て、Symfonyでそれを書き直すことを強く求め続けました。
Main（）で許可されるコードは1行のみ
私の幸運なことに私の大学の教授は、彼女のジュニアC＃の学生がコンソールアプリケーションのエントリポイントに複数行のコードを入れることは許されないことを主張しませんでした。
これは、専門的なアプリケーションを開発する場合には妥当な量ですが、プログラムの唯一の目的がいくつかの基本的な入力を取り、単一の出力（つまりMultiplyTwoNumbers.exe）を生成することである場合、そのような要件は良いというよりは苦痛です。
「メインの1行のコード」に加えて、教授はすべてのコード行に説明コメントがあり、すべてのクラスメンバーにはverbosely説明名があると主張しました。これらの要件が「適切に」満たされていると教授が感じなかった場合、ポイントは失われます。
これらの規則に固執することを強いられた学生は、プログラミングの初心者であり、したがって、私は、適切な命名と懸念の分離などの行為を強制することの価値を理解できます。それにもかかわらず、私の大学の.NET講師として、私は彼女の学生がコードを取得してからずっとずっと、これらの平凡で不愉快な要件を満たすために常に助けていましたworking。
私の意見では、プログラミング言語に慣れていない人を教育するときの最初の関心事は、コードを作成する方法ではなく、標準ベースコードを作成する方法ではないはずです。
「CコードにはC++コメントスタイルを使用しないでください」。
プログラムを古いコンパイラに移植する必要があるリスクがある場合、この値はまだ小さい可能性がありますが、ほとんどの場合面倒です。私の最大の反対は、それが/*開発または単体テスト中に大きな領域をコメントアウトすることをブロックします。 */
私のADA講師は、すべてのメソッドに前提条件、事後条件、およびビッグOを概説するコメントがあると主張しました。これに関する最大の問題は、ビッグOが実際に何を意味するのかを説明したり、それらが正しいかどうかを確認したりしないことでした。このコメントを貼り付けると、何百回もブロックされます。
-- Method_Name
-- PRECONDITIONS: none
-- POSTCONDITIONS: none
-- O(n) = n
（C++）
すべての戻り値はHRESULTS（ユーザー定義のhresultsではなく標準の値）である必要がありました
これはほんの数年前のことです。高齢者はまだCOMに夢中になっていて、他のベストプラクティスを読んだり、知りませんでした。それは驚くほど閉鎖された環境でした。
同じ場所でもSTLを使用できませんでした。
私はその一口を見つけた直後に出発しました。
Visual Basic 6. では、すべてのメソッドにエラー処理ブロックを追加する必要がありました。例外なく。だから私たちはしました。
次に、アプリケーションの一部が遅い理由を説明する必要がありました。
変数/オブジェクト名の限られたスペースは、おそらく私の最大の苛立ちです。私は、10文字しか使用できない比較的近代的な独自仕様の言語で作業しました。これは、元のバージョンからの引き継ぎです。
最終的には、許可された10の各文字が何を表すかを定義する面白い命名規則になってしまいます。何かのようなもの：
- 1-3：アプリケーション接頭辞
- 4-6：モジュール接頭辞
- 7-9：ユーザー定義セクション
- 10：2つまたは9つが同じ名前になっている場合に備えて番号。
私のお気に入りは、現在遵守しようとしているデータベースの命名ガイドラインでなければなりません。多対多の関係に使用されるすべてのテーブルには、リンクされたテーブルの名前を使用して名前を付け、 "Link"のサフィックスを付ける必要があります。そしてもちろん、テーブル名の複数形化はありません。
- OrderLines？いいえ。 OrderProductLinkと呼ぶ必要があります
- 友達？いいえ。 PersonPersonLinkである必要があります
各ファイルにファイルの説明を追加せざるを得ない（それは C＃ プロジェクトです）。
// --------------------------------------------------------------------------------------------------------------------
// <copyright file="User.cs" company="Company">
// Copyright (C) 2009 Company. All rights reserved.
// </copyright>
// <summary>
// The user.
// </summary>
// --------------------------------------------------------------------------------------------------------------------
ある会社では、機能の記述方法を説明する技術文書を作成する必要がありました。 UMLでプログラミングしているときは何も考えないので、時代遅れになってしまいました。