c# - コーディング標準の実装と施行

Question

私のチーム (私はその中で最も新しく、最も若いメンバーです) は、わずか 1 年で 3 人の開発者から 9 人の開発者に増えました。私たちの主要な製品は複雑さを増しており、Silverlight への 1 年にわたる移植/再書き込みに着手しようとしています。過去には、強制された特定のスタイル/標準はありませんでした。

私は上司に、今こそそのような基準を導入する良い機会だと提案しました。IDesign のドキュメントを彼に渡したところ、彼はそのアイデアを気に入ってくれました。彼には2つの懸念があります。

これは吸収すべき大きなドキュメントです。ここでの私の考えは、IDesign 標準が「マスター」であり、スリム化されたバージョンでカバーされていないものはすべて見られるべきであることを理解して、私たちが遭遇する可能性が高い最も一般的なアイテムのスリム化されたチートシートを開発することです。「マスター」ドキュメントにアップします。
これを強制する最良の方法は何ですか。それは口述しようとする問題ではありません。それは、特定の標準に合わせて開発することに人々を慣れさせることの問題です。チームには、数年前から現在の非標準に向けて開発を行っている人が少なくとも 2 人います。この懸念に対処するために、これらの標準を強制するように構成できるツールがあるかどうか、またはコンパイル時または設計時に標準の「違反」を最小限に警告するツールがあるかどうかを確認したいと思います。Microsoft の StyleCop を見つけましたが、私が判断できたところによると、これは構成可能ではなく、IDesign の標準と完全に一致しない Microsoft の標準に従うように設定されています。

ツールまたは私が検討しているアプローチに関する意見をいただければ幸いです。

score 10 · Accepted Answer

ReSharper、FxCop/StyleCop (少なくとも FxCop にはカスタムルールを定義する方法があります)、明確なコードガイドライン、および毎月のレビューを組み合わせることで、9 人のチームの仕事ができるはずです。誰かがルールを破ったら、鞭を使うしかありません :)

score 6 · Accepted Answer

定期的なコードレビューは良い方法です...

開発者は、特定の標準について、ツールだけに任せるよりも、対面で話し合った方が適切に対応することがわかりました。

ツールをコードレビューと一緒に使用することは良いことです。

score 4 · Accepted Answer

コーディング標準の重要性を誇張するのは難しい。重要なのは、誰もがすばやく読んで理解できる一貫したコードベースを用意することです。どの標準セットを選択するかはそれほど重要ではありません（全員がサインアップしている限り）。ただし、広く使用されている標準を選択すると、スタイルを調整する必要のある開発者が少なくなります。クラスライブラリ開発者向けのMicrosoftデザインガイドラインは私のお気に入りです（そしてReSharperにとてもフレンドリーです）。

私の同僚（Howard van Rooijen）と彼のオープンソースチームは、ReSharper用の優れたStyleCopを開発しています。これは、入力時にスタイル違反を強調表示することで、リアルタイムで表示します。心からお勧めする最近のリリースがあります。

score 4 · Accepted Answer

私の現在の会社でコーディング標準に賛同した経験からのメモ（複数のプロジェクトの小規模な開発者で、それぞれ1〜6人のプログラマーがいます。私たちは主にC ++ですが、答えはまだ当てはまると思います）：

コードレビューのチートシートは素晴らしいアイデアです。組織に合わせて調整し（たとえば、見落としがちなものや間違えやすいもの）、必要に応じて更新します（1か月に1回、戻ってきて、他の方法で適用されているものを削除します）。ウィキをお持ちの場合は、可能であれば、各ポイントの「理由」へのリンクを含めてください。

レビューを分割します。正式なレビューを求めるコミットもあれば、そうでないコミットもあります。いくつかのタイプを使用します。

Mini-Design-Docレビューでは、実装が開始される前に、短い（通常はwikiの1ページまたは2ページ）がグループによってコメントされます。「車輪の再発明」を早期に発見するのに最適です。
1人または複数のピアがコミットする前に元の作成者と一緒に座っているガイド付きの温かいレビュー（専門知識を広め、生協/インターンをスピードアップするのに最適です）。原作者は、これらのレビューアよりも多くの問題を見つける傾向があります。=）
ガイダンスのない誰か（チェックインコメントとドキュメント以外）がコードをレビューする、正式なコミット後のコールドレビュー。これにより、論理またはエラー処理の問題、および境界のバグが明らかになる傾向があります。

自動化してプッシュし、有用な情報をプルしないでください。ビルドサーバーからレポートをメールで送信します。通常、コミットごとに1回ビルドされます（ビジー状態によって異なります）。これらのレポートには、たとえば、現在のGimpelPC-Lintの実行と前回の実行の違いを含めることができます。これは、「情報が多すぎる」という懸念に対処します。説明とともに、責任があると思われる警告/エラーだけが表示されます。情報が絞り込まれてわかりやすい場合、人々はそれを学習ツールとして使用します。

私はこれを十分に強調することはできません：小さなものを汗を流さないでください。（すばらしいC ++コーディング標準の本のポイント＃0を参照してください。）

コーディング標準を「必須」セクションと「推奨」セクションの2つ以上のセクションに分割します。これにより、ユーザーは自由に推奨セクションを読み、必要なセクションを小さく保つことができます。
レビューするときは、今すぐ修正することが本当に重要なものとそうでないものを明確に描写してください。たとえば、「ウォームレビュー」の場合、ブラケットの配置と名前の不一致は、コミット前のレビューの前に行われたテストを無効にしたくないため、明示的に「後で修正」されます。ロジックのバグは「コミットする前に今すぐ修正」です。エラー処理の不整合や欠落しているケースはさまざまです。ピドリング違反もすぐに修正するように人々に要求すると、憤慨します。

最後に、参加を促し、時間の経過とともにコーディング標準を変更します。（これはwikiが役立つ場合があります。）誰かが標準の一部に従わない正当な理由がある場合（彼らがより良いものを持っているか、従うにはPITAが多すぎる）、聞いて応答します。人々が標準を単に手渡されるのではなく、実際に積極的に貢献して理解すれば、はるかに良い反応が得られます。

score 3 · Accepted Answer

3

StyleCop は大きな助けになるでしょう。

于 2008-12-04T20:29:00.447 に答える

score 1 · Accepted Answer

ReSharper を試してみてください。コードを自分のスタイルにフォーマットできます。ソリューション全体を一度に再フォーマットすることもできます。

score 1 · Accepted Answer

それよりもずっと短いものを見つけてください。開発者は覚えなければならないことが非常に多いため、1 ページ以上のルールを覚えることを期待するのは時間の無駄です。チートシートを提供したとしても、それが公式で唯一のドキュメントでない限り、残りの部分について独自のスタイルを発明する開発者になってしまうだけです。

従わない大きくて複雑なドキュメントよりも、従う単純な慣習を持つ方がよいでしょう。

余談ですが、チームからの正式な承認は得ましたか?

私が見たほとんどすべてのコード標準は、すべての if ステートメントに波括弧を含める必要があるなど、ばかげたものを義務付けています。

public bool compare (Object other){
  if(other == null) throw new NullPointerException("You twit, don't give me a null pointer");
  if(!(other instanceof CustomerObject)) throw new UnsupportedArgumentException("Give me the right argument, dammit");
  ...

そのようなものは現在 3 行を占めているため、書かれていません (または書かれている場合は、メソッドが何をしているかをプログラマーが理解できないようにしています)。

score 1 · Accepted Answer

アドバイスありがとうございます。もっと聞きたいです。たまたま、 Ilya Ryzhenkovの推奨に従って Resharper を調べていたときに、たまたま IDesign 標準を再ダウンロードしました。これは、このブログエントリへのリンクを含む zip ファイルで提供されています。良い点は、使用したい標準にデフォルト設定されていることです。安価で (寄付しない場合は無料で読むことができます)、たまたまCode-Rush の大ファンになったのです。と Refactor、だから私はすでにDXCoreをロードしています!

score 0 · Accepted Answer

AC＃ベースでTFSとVS 2010を使用して、次のようにします。

紙のコード標準として、編集されていないidesign標準を使用します。

許容度がゼロのリリースビルドで実行するコード分析とスタイルコップ定義のセットを1つ維持します。

また、互換性のあるResharperルート定義を維持しているため、開発者はコードを操作しながら、コードをすばやくフォーマットしてスタイルを設定できます。これにより、ビルド時チェックからのSA / CA警告を待つ必要がなくなるため、ワークフローが容易になります。

開発者がルート定義をオーバーライドできるようにします。

これらの2つの層で検出されない標準の競合は、レビュープロセスで検出され、解決されます。レビューにないものはコードメンテナンスにあります。

score 0 · Accepted Answer

弊社ではC#のリファレンスカードを使用しています。リファレンスカードは、2 枚のスライドを使用してパワーポイントで作成されます。表紙と裏表紙（2ページ印刷）。各スライドには 3 つの列があります (新聞のセットアップ)。各列の間に 1 cm の白が作られ、折り目を実現します。

会社の完全なコーディングガイドラインの最も重要な側面を 2 つのスライドに配置します (たとえば、コーディングスタイル、名前空間とソリューション構造、命名規則など)。

IDesign のすぐに使えるコーディングガイドラインを選択しました。MS コーディングスタイルに慣れる方が簡単かもしれませんが、それはあなたの選択です。ほとんどの開発者は MS ガイドラインに精通しているため、習得が容易です。

score 0 · Accepted Answer

チームが継続的なビルド (例: Hudsonを使用) を行っている場合、誰かがスタイルガイドラインに違反する変更をコミットしたときにビルドを失敗させるか不安定にすることで、スタイルの制約を強制できます。Hudson には、Checkstyle や StyleCop などのツールで使用できるViolationsプラグインがあります。

score 0 · Accepted Answer

構成管理のセットアップがどのようなものかを知らなくても、コードがリポジトリにコミットされる前にコードを評価するバージョン管理システムと統合するツールを最初に探す必要があると思います。私はこれを SVN セットアップで実行し、CVS でも同様に実行するのを見てきました...開発者に「正しい」コードを提出させ、リポジトリを整頓するように強制するため、ある程度効果的です。これの簡単な例は、ユーザーがコミットメッセージで特定の情報 (つまり、バグ番号、プロジェクトタスクなど) を提供しなかった場合にコミットを拒否することです。

ツールは別として、コーディング標準の価値を開発者に示す方法を見つける必要があります。単純なことのように聞こえますが、これまでで最も困難な部分でした。コードベースの維持に関しては、少しの努力が大いに役立つことを開発者に示してください。

c# - コーディング標準の実装と施行

13 に答える 13

Related

Reference