McCall の Quality Modelによると、製品改訂は、ソフトウェア製品の品質属性を説明するための 3 つの主要な視点の 1 つです。製品改訂の観点では、保守性(欠陥を見つけて修正する能力) は、ソフトウェアを改訂する能力に影響を与える主要な品質要因として識別されます。
明らかに、改訂プロセスのある時点で、人間の関与、特にプログラマーの関与が必要になります。コードのフォーマットは、ソフトウェアを効果的かつ効率的に修正するプログラマーの能力に影響を与えます。
コード改訂プロセスでプログラマーの効率と有効性を最大化するために、一般的に受け入れられている、言語に依存しないコード フォーマット ガイドラインは何ですか?
私がこれまで取り組んできた最良のガイドラインは、一貫性です。何年にもわたって、私はさまざまなチームでさまざまなスタイルを使用してきました...私が見た最良の結果は、スタイルに関係なく、チーム全体が同じスタイルを使用することを余儀なくされた場合です:-)
言語にとらわれない概念について、いくつかの考えがあります。
1.) デッド コードを削除します。何かが絶対に不可欠でない限り、コメントアウトされたデッド コードは削除する必要があります。それはルーチンを乱雑にし、文字列を検索すると誤検知が発生することが多く、プロの開発者には適していない一般的なずさんさを示しています
2.) メンテナンス修正については、コメントで欠陥追跡番号を参照してください。何らかの欠陥追跡システムがあると仮定します。これにより、あなたの作業を保守している人は、あるリビジョンと別のリビジョンの間でコードが変更された理由を簡単に把握できます。
3.) それをサポートする言語では、変数を最初に使用する直前にできるだけ宣言します。
他にも言語にとらわれない概念がいくつかあると思いますが、これらは最初に頭に浮かぶいくつかです。私の知る限り、特定の言語がなければコーディング標準について議論することは比較的困難です。そして、私は上記の他の回答に同意します-最善のスタイルは通常、既存のスタイルと最もシームレスに調和するものです.
Steve McConnell のCode Completeをご覧になることをお勧めします。プログラミング言語に関係なく、ほぼすべての開発状況に適用できる優れたアイデアが満載です。
一貫性が鍵です。ガイドラインをどこかに書き留めて、準拠を要求します。
コードの書式設定について心配したり、議論したりする価値はありません。いくつかのルールを作り、それを守りましょう。
私はジョエルに同意します。そこには多くのスタイルの例があります。ほとんどが良いです。他のものほど役に立たないものもあります (ハンガリー記法?)。ただし、全体のポイントは一貫性です。個々の開発者の個人的なスタイルに慣れる必要がなく、新しい開発者がコードをすぐに理解できる限り、それは機能します。
毎年かそこらで基準を切り替えるのは、おそらく悪い考えです。
Joel に同意します。組織内で一貫性があると、保守性が大幅に向上します。私が別のチームに参加した場合、すべてのルック アンド フィールが現在のものと似ていれば、立ち上げ時間は大幅に短縮されます。 _var の代わりに mVar" / など
私たちが持っている優れた標準の 1 つは、変数の「接頭辞」です。ここに来るまではほとんどソロで書いていたので気にしていませんでした。
変数が何であるかを示す接頭辞を付けて変数に名前を付けることが「必須」です。したがって、dpVarName を見ると、これが double へのポインターであり、lVarName が long int であることがすぐにわかります。
最初は、ブロックをブラケットするための 2 つの選択肢が与えられたことをうれしく思いましたが、今では、いずれかの方法でそれを強制されただけでよかったと思います。