すべての開発者に同じコード形式を課すことは良い考えですか？
プロジェクトに単一の標準コード形式（Eclipseでの保存アクションを備えた自動形式）を課すことを検討しています。その理由は、現在、複数（> 10）の開発者が使用するコード形式には大きな違いがあるため、ある開発者が別の開発者のコードに取り組むのが難しくなっているためです。同じJavaファイルは、3つの異なる形式を使用する場合があります。
だから私は利点が明確であると思います（読みやすさ=>生産性）が、これを課すことは良い考えでしょうか？そうでなければ、なぜですか？
[〜＃〜]更新[〜＃〜]
私たちは皆Eclipseを使用しており、誰もがその計画を知っています。ほとんどの人がすでに使用しているコード形式がありますが、独自のコード形式を使用することを好む人もいるため、強制されていません。上記の理由により、一部の人はそれを強制することを好むでしょう。
私は現在、標準のコード形式が適用されている場所で働いており、ファイルを保存すると、あなたがしようとしているように、コードは自動的にフォーマットされます。会社の新しいメンバーとして、共通のフォーマットルールが「彼らは何をしているか知っている」という温かく曖昧な感じを与えてくれるので、私は幸せになれなかった。 ;）関連する付記として、共通のフォーマットルールを使用して、Eclipseで特定のかなり厳密なコンパイラ警告設定を適用します。それらのほとんどはエラーに設定され、多くは警告に設定され、ほとんど無視されません。
プロジェクトで単一のコード形式を適用する主な理由は2つあると思います。最初はバージョン管理と関係があります。誰もが同じようにコードをフォーマットすることで、ファイル内のすべての変更が意味を持つことが保証されます。あちこちにスペースを追加または削除するだけでなく、実際に1行または2行だけを変更する「副作用」としてファイル全体を再フォーマットすることはできません。
第二の理由は、それがプログラマーのエゴを方程式から取り除くということです。誰もが同じ方法でコードをフォーマットすると、誰が何を書いたかを簡単に知ることができなくなります。コードはより匿名で一般的なプロパティになるので、「誰か他の人の」コードを変更することに不安を感じる必要はありません。
それらが主な理由ですが、他にもあります。保存時にEclipseが自動的にそれを行うので、コードのフォーマットについて考えることに煩わされる必要がないのは心地よいと思います。 LaTeXでドキュメントを書くように、それは気楽です：それは後でフォーマットされ、書くときにそれを心配する必要はありません。私はまた、誰もが独自のスタイルを持っているプロジェクトで働いてきました。次に、他の誰かのコードを自分のスタイルで変更してもよいか、代わりに自分のスタイルを模倣する必要があるかなど、愚かで無意味な問題について考える必要があります。
私があなたのケースについて考えることができる一般的なコードフォーマット設定に対する唯一の議論は、それが明らかに進行中のプロジェクトであるため、実際のファイル履歴を台無しにして、すべてのファイルに多くの不必要な変更を引き起こすことです。最良のシナリオは、プロジェクトの最初から設定の適用を開始できる場合です。
あなたが概説したまさにその理由のために、すべてのプロのソフトウェア開発者は、スタイルよりも福音主義の戦争に入るのではなく、（良い）標準を採用することを好みます。
多くのソフトウェア開発者が福音主義の戦争を繰り広げています......
チーム内での自分の位置とチームのダイナミクスによっては、戦争に勝つことができないと判断する場合があります。この場合、開始しないのが最善です...
はい、すべての開発者が1つのコード形式スタイルを使用できるのは良いことです。
コードスタイル形式を設計し、それをすべての開発者のEclipseにインポートします。
これは、「バージョン管理」システムのコードをmergingするときに役立ちます。
何を獲得しようとしているのか、それを実施するのにどの程度の保持力があるのか（そして、「ルール」が設定される詳細レベルで）、異なる言語で記述されたコードにそれを実施しようとするのか、既存のコードに遡及的に適用しようとするのですか？
- コードに共通のルックアンドフィールを使用すると、コードが読みやすくなるだけでなく、ルックアンドフィールが間違っていると状況が悪化する可能性があります。 _hUngarian_lpfstr表記は、主要な例です:)
- コメントブロック内の空白のスペース数、メソッド名のアルファベット順、およびその他のナンセンスを強制する「コード標準」を見てきました。しないでください。
- 言語が異なれば、人々は慣れ親しんだ標準を使用し、その使用経験は豊富です。これらの標準を義務付けているものさえあります（Python、Cobol、Visual Studioが自動的にC++スタイルのブレーシング規則を課す一方で、Javaは規則によってCスタイルを使用するなど）。
- コードを変更するために既存のコードを変更することはありません。その方法で新しい問題が発生するだけです。つまり、コードセクションとソースファイル全体を意味します。したがって、誰かが1000行のファイルの1行を変更したときに、既存のコードを再フォーマットしないでください。
- 経験豊富なプログラマーは、書いている内容が自動承認システムやレビュアーに「正しく見える」かどうかを半分の時間で考える必要がない場合、はるかに生産性が高くなります。彼らはまた、自然なスタイル間にわずかな違いがあっても、それが機能するので単純にクリーンなコードを書く習慣があります。
したがって、特定のスタイルと標準を課すことには十分な理由がありますが、厳密に（あまりに）行わないことには十分な理由があります。
はい、一貫性は良い考えです。理由は others have 言及 です。
私は他で使用されていないいくつかのポイントを追加したかっただけです：
- Oracleは、事実上の標準であるJava用の 一連の規則 を公開しています。
- これらを使用すると、どのスタイルに従うべきかについての議論を避けるのに役立つはずです。
- 多くのパブリックライブラリとオープンソースプロジェクトはこれらの規則を使用する傾向があるため、これらを参照する必要がある場合は、フォーマットをよく理解しておく必要があります。
- Eclipseフォーマッターには、これらの規則に一致する組み込みルールがあり、これも役立つはずです。
- メインブランチに入る前にコードが自動フォーマットされるように、ソース管理設定にフックを組み込むことを検討することをお勧めします。
- 標準に従うことを拒否する特に頑固なプログラマーとの戦いを避けることができます。作業中に独自のフォーマットを使用することもできます。これは後で標準化されます。
- 最終的にカスタムの書式設定を使用する場合（たとえば、多くの人が「1行あたり最大80文字」の規則を無視している場合）は、1か所で変更するだけで済みます。
私は Checkstyleプラグイン を使用するチームにいました。すぐに使える機能を使用するのではなく、関心のある開発者からなる小さな委員会を編成しました。不足しているように見えるもの、過度に見えるものについて議論し、物事を打ち出しました。私たちは全員、その過程で何かを学び、それらの開発者の筋肉を強化しました。
（私たちの決定の例：幅72文字は小さすぎますが、120が良かったです。静的な決勝戦には_ALLCAPSを使用する方が良いです。関数から単一出口を強制するのは良い考えです。）
コードレビューを行ったとき、最初の質問の1つは、「Checkstyleで実行しましたか？」でした。コーディング標準への準拠はほぼ自動化されており、レビュー担当者がうるさいということから注意をそらしました。 Checkstyleでメソッドシグネチャをハイライト表示し、右クリックして、変数をfinalに変更するのは驚くほど簡単でした。また、インデントと中かっこを修正して、すべてのコードの外観が同じになるようにすることもできます。 public関数のJavadocがありませんか？ Checkstyleは関数にフラグを立てます。
（コードのにおいを取り除くことは、一貫したフォーマットよりも重要です。これは自動化ツールの利点です。）
Checkstyleのような自動化ツールを同じフォーマットとしてimposeとして配置し、さらにencouraging同様のルックアンドフィール。また、猫を飼う場合は、自動化されたツールを使用すると、壊れやすいエゴを傷つけずにスキルを磨き、コードのにおいを減らすことができます。
同じIDEに固執し、いくつかの書式設定ツールを組み込む場合は、あまり労力を必要としないため、これは良い考えです。読みやすさとない 肛門保持力 。それは測定棒でなければなりません。
一貫してフォーマットされた泥のボールは、単なる泥のボールよりも優れていますが、ブラケットがどこに行くかについてあまりにうるさいのではなく、それを片付けるために時間を費やす方がよいでしょう。 新しいカバーシートがTPSレポートにある であることを確認しながら、コードのレビュー中にインデントスペースを数えることで仕事をしているように見える、頭の悪いマネージャーにはならないでください。
個人の好みはそれだけであり、生産を改善することはめったにありません： https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms
もしそうなら、それを乗り越えて何かを成し遂げる。
私は人間にコードのフォーマットを強制し、軽微な違反は礼儀正しく見落とされたり修正されたりすることを強くお勧めします。これの理由は、簡単に言えば、
- マシンは、最悪の場合、通常は新しい言語機能を使用しているときに、問題が発生します。 Javaなどでクロージャをどのように処理しますか？ Jalopyは、メンバー関数を持つ列挙型に問題があります。
- プログラマーに会社コードのような会社のコードを作成してもらうのは非常に合理的な負担だと思います。これがコードが「ここ」でフォーマットされる方法であり、すべてのコードがどこでもフォーマットされる方法ではないことを言及することは有用だとわかりました。以前の会社は別の方法を選択した可能性がありますが、それは問題ありません。固有言語とは異なり、コードカルチャーに固有のイディオムを持ち出します。
- コード構文の実施は、コードレビューで行うのが最善です。
- 書式設定が重要な場合は、組織がコードレビューを行う必要があるからです。これは非常に有益です。
- 書式設定ルールが違反している場合、人間はそれを見て、意図がより明確に伝えられていれば、マシンよりも適切に判断できます。これは非常にまれですが、ときどき発生します。
「読みやすさ=>生産性」については、コード構造（単一責任クラスや関数など）を使用すると、コードのフォーマットよりもはるかに速く購入できます。コードの書式設定は役立つ場合がありますが、考え方が異なるとステートメントの解析方法が異なります。誰もが「生産性」を高めるとは限りません。書式設定よりもコード構造を詳しく見ていきたいと思います。これは、コードのレビューを行い、チームが単一のループの外観ではなくプログラムのしくみについて考えるようになるためです。
私はドメインドリブンデザインの大ファンではありませんが、コードがどのように構造化されるべきか、およびコードフォーマッティング規則がドメインドリブンデザインの構造化プログラムから自然に流れ出すという非常に明確なアイデアを持つ最近のモデルの1つです。繰り返しますが、私はDDDは好きではありませんが、明確に定義されているため、良い例です。
この答えのテーマはDo code reviewであり、書式設定をカルチャーからレビュープロセスの外に流れさせると思います。
一般に、妥当な開発者を雇うことを想定して、ユニバーサルコード形式を課すことは悪い考えです。ただし、コードguidelinesを採用することをお勧めします。
すべてのケースで読みやすさを最適化する一連のコードフォーマットルールを見たことがありません。同様に、英語には100％適用可能な文法規則はありません。私たちの頭脳はそのように配線されていません。そのため、ガイドラインを使用しますが、開発者が適切と思われる場合はガイドラインをオーバーライドする自由を与えます。
そうは言っても、「ファイル/プロジェクトにすでに存在するコード規則に従う」というより難しいルールは良いものです。
ただし、書式設定は、単にコードがどのように論理的に構成されているかよりも、読みやすさへの寄与がはるかに少ないことに注意してください。完璧なフォーマットをした判読できないスパゲッティコードをたくさん見ました！
一般的なコーディングスタイルに対する私の主な議論は、経験豊富なプログラマーが自分のスタイルを読むために使用されるということです。特定のスタイルを書くように手を訓練することはできますが、嫌いなスタイルを理解するように目を訓練することはほとんど不可能です。プログラマーは、コードの一部を一度書き込んでから、開発およびデバッグ中に何度も読み取ります。彼が自分のコードを読むたびに、彼が悪いスタイルでそれを書かざるを得なかったので、彼はそれを理解するのに苦労しているなら、彼は非常に不幸で生産性が低くなるでしょう。これは私の経験からです。
私はEclipseに慣れていませんが、保存時の自動フォーマットは恐ろしいアイデアのように聞こえます。開発者は、コーディングスタイルが課されているかどうかに関係なく、コードを完全に制御する必要があります。 「保存」操作では、ユーザーの明示的な同意なしに単一の文字を変更しないでください。
会社がソースコードを販売している場合はコーディングスタイルの方が重要ですが、コンパイル済みのコードを販売している場合はそれほど重要ではありません。
コーディングスタイルが元のコーダーを区別しにくくし、自我戦争を防ぐことを期待することは、最良の場合はでたらめであり、最悪の場合は単純で愚かです。優れたプログラマーは、スタイルに関係なく常にエレガントなコードを生成します。
また、私はすべての開発者に特定のコードユニットの所有権を与え、誰もがすべてのコードに自由に触れることができないようにすることを強く推奨しています。コード内でユニット全体を開発し、それらの責任を負うことで、開発者は自分の作業に誇りを持ち、バグが戻ってくることを知ってくだらないコードを開発するのを防ぐことができます。
最後に、プロのコーディングスタイルを使用しているユーザーは、常に自分のコーディングスタイルが選択され、他のすべてのユーザーがそれに従うと見なします。標準として選択されているすべての共同開発者の中で最も嫌いなコーディングスタイルを想像してください。コーディングスタイルを課すことにまだ賛成ですか？
それらすべてを支配する1つのフォーマット...それは本当に最適ですか？
誰かの車を運転するようなものです...
もちろん、車に乗り込んで運転することはできますが、時間をかけてシート、ステアリングホイール、ミラーを調整すると、安全で快適になり、クラッシュする可能性も低くなります[〜＃〜] your [ 〜＃〜]設定。
コードの場合、書式設定はコードの読み取りと理解の快適さに影響します。あなたが慣れているものから遠すぎる場合、それはより多くの精神的な努力を必要とします。開発者にこれを与える必要がありますか？
これまでに述べたすべてのメリットに+1しますが...
自動適用には、考慮が必要なコストが伴います。
-1は、コードフォーマッタがコードフォーマットの美学を理解していないことを示します。コードフォーマッタで、表形式でうまく整列されたコメントブロックを破棄したことが何度ありますか？複雑な式を意図的に整列させて特定の方法で読みやすさを向上させた回数。自動フォーマットでは、「ルールに従う」ものの、はるかにless読みやすいものに変換されますか？
これらの問題には回避策がある場合がありますが、開発者は、自動フォーマッターがコードを変更しないようにする方法よりも、心に留めておくべき重要なことを持っています。
書式設定ルールはあるが、常識を適用するためにある程度の自由を認める。
これに対する簡単な答えはないと思います。それはイエスかノーの質問ではありません。私はスタイルと命名規則がある程度重要であると信じていますが、それについて考えるのにあまりにも多くの時間を浪費することも非常に簡単です。例で答えることが最善です。
私が携わっていた特定のプロジェクトでは、慣例はまったくありませんでした。すべての開発者が独自の方法で物事を行いました。このチームは比較的経験が浅いため、あるクラスから次のクラスに進むのは本当に耳障りでした。スタイルは、命名規則の問題ほど問題ではありませんでした。開発者の1人は、ひどいハンガリー語表記（最近のIDEの時代にはばかげた慣習）でUI要素を参照し、プライベートメンバーには何らかの方法で名前を付け、別の名前には別の名前を付けました。あなたは自分が何を見ているのかまったく知りませんでした。
反対の極端では、あるチームがビルドプロセスの一部としてStyleCop（これは.Netプロジェクトでした）を使用しました。さらに悪いことに、ほとんどのデフォルトルールも使用されていました。そのため、行間隔や中括弧の配置の点で完全に通常のことを行い、そのためにビルドが失敗します。スペースと行を追加するだけで多くの時間が無駄になり、StyleCopの使用を主張した男を含め、全員がほぼすべてのコミットを実行することになりました。時間とお金の浪費でした。
したがって、ここで私が主張していることは、柔軟性に欠けることは答えではないということですが、ワイルドウエストにいることもそうではありません。本当の答えは、最も理にかなった場所を見つけることです。私の意見では、自動化されたツールがものをチェックするのではなく、慣習を風に流すこともないということです。
優れた開発者は創造的な人々であり、芸術的なライセンスを与えます。 「Keep it simple」はプログラマーのスローガンでなければなりません。私には2つのルールがあります。
ルール1：変数/カーソル/オブジェクト/プロシージャ/すべてのSENSIBLE NAMESを指定します。コードに意味と理解をもたらす明確な名前。
ルール2：インデントを使用してコードの構造を示します。
それでおしまい。
私にとって、自動的に適用される一般的な形式の主な利点は、変更の追跡とコードのレビューに役立つことです。 git（および他のほとんどのソース管理ツール）は、以前のバージョンのファイルの差分を表示できます。共通のスタイルを適用することで、プログラマーの好みの相違を最小限に抑えます。