7

ソース管理のコミット、チェックアウト、差分などの前後にコードを自動フォーマットできる場合、企業は標準的なコード スタイルを本当に必要としているのでしょうか?

プログラミングが始まって以来、「括弧を次の行に置く」または「( を適切にインデントする」などの標準的なコーディング スタイルの議論は、もはや不可欠ではなくなったように感じます。

空白が重要な言語では差分を考慮する必要があることは理解していますが、スタイルが個人的な好みである言語では、それについて心配する必要は本当にありますか?

4

6 に答える 6

5

自動フォーマットは、実際には空白のみに対処できます。

変数に奇妙で意味のない名前を付けている開発者には対処しません。一部の開発者は、関数がエラー時に null を返し、例外をスローすることに対処しません。

他の人はもっと多くの例を思いつくことができると確信しています。

于 2009-12-10T17:45:59.247 に答える
3

これは私たちが私の仕事で行っていることです：

私たちは皆Eclipseを使用しています。Eclipse を使用するためのポリシーはありませんが、どういうわけか、誰も IDEA/IntelliJ の専門家ではありません。また、コードはレガシーを念頭に置いて作成する必要があると考えています。これは、誰が書いたとしても、またその人が会社にいなくても、( #1 ) 何年も経った後でも、特定の方法でコードを読み取ることができる必要があることを意味します。

Eclipse には、いくつかの便利な機能、保存時の自動フォーマット、および特定のFormatter ツールがあります。リンクされたスクリーンショットからわかるように、XML で構成できます。したがって、社内のすべての従業員が使用できる一連の事前作成された XML:s が用意されているため、新しい人が入ってきたときに、プロセス全体を説明し、Eclipse を構成します (はい、これを行うのは少し悪いことです) 。私たちが提供した書式設定の XML:s を実際に使用していることを確認してください。保存時に自動フォーマットを強制することはありません。完全に邪魔になりたくはありません。すべての開発者を正しい方向に進めたいだけです。互換性をさらに高めるために、主にJCCで定義されたルールを使用します。

次に、重要な部分である実際のビルドが続きます。私たちは自動ビルドを採用しており、そのためにHudson Continuous Integration Serverを使用しています。これ以外にも、構成には 2 つの重要な部分があります。

Checkstyle プラグインは、コード スタイルの強制ガイドラインの魔法使いです。

  1. コードを CVS にコミットした後、Hudson ビルドがトリガーされます
  2. ビルドが正常に完了した後 (すべての単体テストがパスするなど)、Checkstyle は実際のソース ファイルを検査します。
  3. Checkstyle は、定義したコードベースのルールをランク付けします
  4. 継続的インテグレーション ゲームは、Checkstyle の結果を確認し、コードの関連部分の所有者にポイントを付与/取得します
  5. リーダーボードには、システム内のすべてのコミッターの合計ポイントが表示されます

基本的にこれは、誰かが醜いコードを CVS にコミットすると、ビルド サーバーが自動的にその人のポイントを減らすことを意味します。

これは、最終的には、デメテルの法則、循環的複雑度などの OO 原則と外観の両方の一般的なコード品質に基づいて、リーダーボードにランク付けされる可能性があることを意味します。当然、これは完全に深刻な統計ではありませんが、 CI でビルドを開始するときに何か間違ったことをしているという良い兆候は、ポイントを減らすことにはなりません。ほとんどのコミットは 1 ～ 5 ポイントの価値があります。

そして、それは機能していますか？私の職場では、醜いコードや保守不可能なコードを書く人は誰もいないと思います。個人的には、あらゆる種類のスコアを探すのが大好きなので、見栄えがよく、私が知っているすべての OO パラダイムに従うコードを作成する動機になっています。

そして、私たちは会社として本当にそれを必要としていますか? この回答全体を読んでわかるように、私たちはそうしていると思います。それがもたらす進歩の良い実践と考えることができます.

#1: 関連するメモとして、これらの標準を使用する 2002 年のレガシー コードを今日リファクタリングしましたが、元の形式でもまったく「悪く」見えず、新しい形式でも確かに悪くはありませんでした。

于 2009-12-10T18:10:49.680 に答える
2

いいえ、そうではありません。

実際に一貫して動作させることができ、コードのレイアウトのスタイルが異なるためにコードが変更されたことにフラグを立てないようにすることができます。

ただし、これはコーディング標準のほんの一部です。複数の return ステートメント、三項演算子の使用の有無などについては説明しません。

于 2009-12-10T17:42:20.090 に答える
0

はい、同種のコード ベースが必要な場合は、コーディング スタイルが必要です。このようなコード ベースは、コード ベースの一部を個人が所有することを防ぐのに役立ちます。これは、人々がチームを離れるときに問題を引き起こす可能性があります。大きく異なるスタイルとそのすべてを理解するのに問題があることを想像できない場合は、さまざまなコミュニケーションで英語のテキストを整理するさまざまな方法を見てください。 、掲示板の投稿等、フォント、大文字、装飾等の変更

于 2009-12-10T18:49:54.003 に答える
0

チームの全員が、ソース コードが「正しく」フォーマットされていることを確認できれば、おそらくそれほど重要ではなくなります。ただし、それを実行できるシステムは見たことがありません。その一部を実行できます (チェックイン/チェックアウトの前後に再フォーマットするなど)。バージョン管理システムなどと直接対話します。

標準コード スタイルの主な目的は (IMHO)、すべてのコードが同じ種類の指針に従って書かれているため、リバース エンジニアリングを開始することなく、他のチーム メンバーのコードを簡単に読めるようにすることです。インデントと括弧の配置は、これに関する大きな問題のようですが、それらは非常に小さいものであり、私の意見では、やや誇張されており、コードの一貫性を保つ必要がある部分としてはあまり重要ではありません。

残念ながら、一貫したコーディング原則をソースコードに自動的に適用できるツールを知りません...

于 2009-12-10T17:43:00.557 に答える
0

ショップが使用するコーディング スタイルが、開発ツールも従うものと同じであれば、それは常に素晴らしいことです。

それ以外の場合、ツールの標準と同じではないショップ標準にすでに準拠している大量のコードがある場合は、次の 2 つの選択肢があります。

  1. ツールの標準に従うようにすべてのコードを変更する、または
  2. 既存のショップ標準を維持します。

多くのショップは後者を行っています。とにかく、何らかの基準が必要であり、それに従う必要があります。

一部の開発ツールでは、標準を微調整できます。場合によっては、ツールをショップの標準に合わせることができる場合があります。

于 2009-12-10T17:41:02.180 に答える