5

私は、年間 10 から 15 のプロジェクトのプロジェクト負荷を持つ約 15 人の開発者のチームのためにコーディング標準文書を書いています。他のセクション (それらにたどり着いたらここに投稿するかもしれません) の中で、コードのフォーマットに関するセクションを書いています。まず、何らかの理由で、基本的で一貫したコードのフォーマット/命名基準を確立するのが賢明だと思います。

過去 3 年間にこのチームが作成した約 10 件のプロジェクトを調べましたが、明らかに、かなり幅広いスタイルを見つけています。請負業者が出入りすることもあり、時にはチームの規模が 2 倍になることもあります。

私は、実際に成果を上げたコードのフォーマットと命名基準に関するいくつかの提案を探しています...しかし、それは実際に正当化することもできます. 一貫性と共有パターンは、コードをより保守しやすくするのに大いに役立つと思います...しかし、上記の標準を定義するときに考慮すべき他のことはありますか?

  • 括弧をどのように並べますか？クラス、メソッド、try catch ブロック、switch ステートメント、if else ブロックなどを扱うときに、同じ括弧のガイドラインに従っていますか?

  • 列にフィールドを並べますか? プライベート変数にアンダースコアを付けたり前に付けたりしますか? ファイル内の詳細を見つけやすくするために、命名規則に従っていますか? クラスのメンバーをどのように並べますか?

名前空間、パッケージ、またはソース コード フォルダー/組織の標準に関する提案についてはどうですか? 私は次のようなことから始める傾向があります。

<com|org|...>.<company>.<app>.<layer>.<function>.ClassName

これらの基準を口述する前に、私が慣れ親しんでいる以外の、より受け入れられている慣行があるかどうかを知りたいと思っています。すでにオンラインで公開されている標準へのリンクも素晴らしいでしょう。

4

4 に答える 4

3

まず、ご使用の言語で機能する自動コードフォーマッターを見つけます。理由：文書が何を言おうと、人々は必然的に規則を破るでしょう。コードレビューを選択するよりも、フォーマッターを介してコードを実行する方がはるかに簡単です。

既存の標準（Java、C＃など）の言語を使用している場合は、それを使用するのが最も簡単です。少なくとも、最初のドラフトとして使用することから始めてください。Sunは、フォーマット規則に多くの考慮を払いました。あなたはそれを利用したほうがよいでしょう。

いずれにせよ、多くの研究が、ブレースの位置や空白の使用などのさまざまなものが、生産性、理解可能性、またはバグの蔓延に測定可能な影響を与えないことを示していることを忘れないでください。基準を設定することが重要です。

于 2008-09-07T03:34:30.563 に答える
3

自動車業界から来た、具体的な理由で使用されるいくつかのスタイル標準は次のとおりです。

制御構造では常に中括弧を使用し、それらを別々の行に配置します。これにより、コードを追加して、それを制御構造内に誤って含めたり含めなかったりする問題が解消されます。

if(...)
{

}

すべてのスイッチ/選択にはデフォルトのケースがあります。有効なパスでない場合、デフォルトのケースではエラーがログに記録されます。

上記と同じ理由で、if ... elseif ...制御構造は、デフォルトのelseで終了する必要があります。これは、有効なパスでない場合にもエラーをログに記録します。単一のifステートメントはこれを必要としません。

ループまたは制御構造が意図的に空になっている場合は、これが意図的なものであることを示すために、常にセミコロンが内部に配置されます。

while(stillwaiting())
{
   ;
}

命名基準には、typedef、定義済み定数、モジュールグローバル変数などのスタイルが大きく異なります。変数名にはタイプが含まれます。名前を見て、それがどのモジュールに関連しているか、そのスコープ、およびタイプについてよく理解できます。これにより、タイプなどに関連するエラーを簡単に検出できます。

他にもありますが、これらは私の頭の一番上です。

-アダム

于 2008-09-07T03:57:54.377 に答える
2

ジェイソンの2番目の提案に行きます。

私は、主にPerlで作業する10〜12人のチームの標準ドキュメントを完成させました。このドキュメントでは、「複雑なデータ構造にパーティディのようなインデントを使用する」と書かれています。また、この基準を満たすためにコードをクリーンアップするための適切な設定の例をすべての人に提供しました。それは非常に明確で、言語の業界標準であるため、チームはそれを大いに活用しました。

このドキュメントを書き始めるとき、私はリポジトリ内の優れたコードの例をいくつか尋ね、テンプレートを作成するよりも賢いアーキテクトである他の標準ドキュメントを見つけるために少しグーグルで検索しました。マイクロマネージャーの領域に侵入することなく、簡潔で実用的であることは困難でしたが、それだけの価値はあります。基準を持つことが確かに重要です。

それがうまくいくことを願っています！

于 2008-09-07T03:55:53.273 に答える
1

言語や技術によって明らかに異なります。あなたの名前空間の例を見て、私は Java を推測するつもりです。また、すべてのプロジェクトを似たものにする maven の標準ディレクトリ構造のようなものを見たいと思うかもしれません。

于 2008-09-06T17:01:46.747 に答える