すべての開発者に同じコード形式を課すことは良い考えですか？

プロジェクトに単一の標準コード形式（Eclipseでの保存アクションを伴う自動形式）を課すことを検討しています。その理由は、現在、複数（10人以上）の開発者が使用するコード形式に大きな違いがあるため、ある開発者が別の開発者のコ​​ードで作業することを難しくしているためです。同じJavaファイルが3つの異なる形式を使用する場合があります。

だから私は利点が明確であると信じています（読みやすさ=>生産性）が、これを課すことは良い考えでしょうか？そうでない場合、なぜですか？

更新
私たちは皆Eclipseを使用しており、誰もがこの計画を認識しています。ほとんどの人が既に使用しているコード形式がありますが、一部の人は独自のコード形式に固執することを好むため、強制されていません。上記の理由により、強制することを好む人もいます。

私は現在、標準のコード形式が適用され、ファイルを保存するときにコードが自動的にフォーマットされる場所で働いています。会社の新しいメンバーとして、共通のフォーマットルールが「彼らは何をしているのかを知っている」という温かくて曖昧な気持ちを与えてくれたので、私は幸せになれなかったことがわかりました。;）関連する副次的な注意事項として、共通のフォーマットルールを使用して、Eclipseの特定のかなり厳しいコンパイラ警告設定も適用します。

プロジェクトで単一のコード形式を強制する主な理由は2つあると思います。まず、バージョン管理に関係します。コードをすべて同じようにフォーマットすると、ファイルのすべての変更が意味のあるものになることが保証されます。あちこちにスペースを追加または削除するだけでなく、実際に1行または2行だけを実際に変更する「副作用」としてファイル全体を再フォーマットすることは言うまでもありません。

2番目の理由は、プログラマーの自我を方程式から取り除いてしまうからです。誰もが同じ方法でコードをフォーマットすると、誰が何を書いたかを簡単に知ることができなくなります。コードはより匿名で共通のプロパティになるため、「他人の」コードを変更することに不安を感じる必要はありません。

これらが主な理由であり、他にもあります。Eclipseが保存時に自動的に行うので、コードのフォーマットについて考える必要がないので安心です。LaTeXでドキュメントを書くのと同じように気にせず、後でフォーマットされますので、書き込み中に心配する必要はありません。私はまた、誰もが独自のスタイルを持っているプロジェクトで働いてきました。次に、自分のスタイルで他の人のコードを変更してもよいか、代わりにスタイルを模倣する必要があるかなど、愚かで意味のない問題について考える必要があります。

あなたのケースについて考えることができる一般的なコードフォーマット設定に対する唯一の議論は、明らかにすでに進行中のプロジェクトであるため、実際のファイル履歴を台無しにして、すべてのファイルに多くの不必要な変更を引き起こすことです。最良のシナリオは、プロジェクトの最初から設定の実施を開始できる場合です。

すべてのプロのソフトウェア開発者は、あなたが概説したまさにその理由のために、スタイルよりも福音主義的な戦争に入るよりも、（良い）標準を採用することを好むでしょう。

多くのソフトウェア開発者が福音宣教戦争を行っています......

チーム内でのあなたの立場とチームのダイナミクスに応じて、戦争に勝つことは不可能であると決めるかもしれません。この場合、開始しないことが最善の場合があります...

はい、すべての開発者が1つのコード形式スタイルを使用するのは良いことです。

コードスタイル形式を設計し、それをすべての開発者Eclipseにインポートします。

これはmerging、「バージョン管理」システムのコードを作成するときに役立ちます。

何を獲得しようとしているのか、どのように肛門保持性を強化するのか（および「ルール」が設定される詳細レベルで）、異なる言語で書かれたコードにそれを施行しようとするのか、既存のコードに遡及的に適用しようとしていますか？

1. 一般的なコードのルックアンドフィールは、実際にコードを読みやすくするのに役立ちますが、ルックアンドフィールが間違っていると事態が悪化する可能性もあります。_hUngarian_lpfstr表記法が主な例です:)
2. コメントブロック内の空白スペースの数、メソッド名のアルファベット順、その他のナンセンスを強制する「コード標準」を見てきました。しないでください。
3. 異なる言語には異なる標準があり、その使用経験のある人は慣れています。これらの標準を強制するものもあります（Python、Cobol、Visual StudioはC ++スタイルのブレース規則を自動的に課し、Javaは規則ごとにCスタイルを使用するなど）。
4. それを変更するために既存のコードを変更することはありません、あなたはその方法で新しい問題を導入しているだけです。つまり、ソースファイル全体だけでなくコードセクションも意味します。そのため、誰かが1000行のファイルの1行を変更したときに既存のコードを再フォーマットしないでください。
5. 経験のあるプログラマーは、書いているものが自動承認システムまたはレビューアーのどちらに「正しく見える」かを半分の時間で考える必要がなければ、はるかに生産的です。また、自然なスタイルにわずかな違いがあったとしても、それがうまくいくからという理由だけで、きれいなコードを書く習慣になります。

そのため、特定のスタイルと標準を課す正当な理由がありますが、厳密に（あまりにも）そうしない正当な理由があります。

はい、他の人が述べた理由から、一貫性は良い考えです。

他で使用されていないポイントをいくつか追加したかっただけです。

• Oracle は、事実上の標準であるJavaの一連の規則を公開しています。
  • これらを使用すると、どのスタイルに従うべきかという議論を避けることができます。
  • 多くの公立図書館とオープンソースプロジェクトはこれらの規約を使用する傾向があるため、これらを見る必要があるときは、フォーマットはよく知っているはずです。
  • Eclipseフォーマッターには、これらの規則に一致する組み込みルールがあり、これも役立つはずです。
• コードがメインブランチに入る前にコードが自動フォーマットされるように、ソース管理設定にフックを構築することを検討してください。
  • 標準に従うことを拒否する特に頑固なプログラマーとの戦いを避けることができます。作業中に独自の書式設定を使用することもできます。これは後で標準化されます。
  • カスタム書式設定を使用することになった場合（たとえば、多くの人が「1行あたり最大80文字」の規則を無視します）、1か所で変更を加えるだけで済みます。

私はCheckstyleプラグインを使用するチームに所属していました。すぐに使える機能を使用するのではなく、関心のある開発者の小さな委員会を形成しました。欠けているように見えるもの、過度に見えるものについて議論し、物事を打ち出した。私たちは皆、その過程で何かを学び、それらの開発者の筋肉を強化しました。

（決定の例：72文字の幅は小さすぎますが、120文字の方が優れています。静的なファイナルには_ALLCAPSを使用することをお勧めします。関数からの単一出口の実施は良い考えです。）

コードレビューを行ったとき、最初の質問の1つは「Checkstyleで実行しましたか？」でした。コーディング標準への準拠は大部分が自動化されており、レビュアーがうるさいことから注意をそらしました。Checkstyleでメソッドシグネチャを強調表示し、右クリックして変数をfinalに変更するのは驚くほど簡単でした。また、インデントとブレースを修正して、全員のコードが同様のルックアンドフィールを持つようにすることもできます。パブリック関数のJavadocが見つかりませんか？Checkstyleは関数にフラグを立てます。

（コードのにおいを取り除くことは、一貫したフォーマットよりも重要です。これは、自動化ツールの利点です。）

Checkstyleのような自動化されたツールは、同じフォーマットを押し付けるのではなく、同様のルックアンドフィールを奨励することに重点を置きます。また、猫を放牧している場合、自動化されたツールは、脆弱なエゴを傷つけることなく、スキルを磨き、コードの臭いを減らすのに役立ちます。

同じIDEに固執し、いくつかのフォーマットツールを組み込む場合は、あまり労力を必要としないので、良いアイデアです。肛門の保持力ではなく読みやすさに重点を置いて、ルールをシンプルにしてください。それが測定スティックです。

一貫してフォーマットされた泥のボールは単なる泥のボールよりも優れていますが、ブラケットがどこに行くのかを気にしすぎるのではなく、時間をかけてそれを吸い上げる方が良いでしょう。新しいカバーシートがTPSレポートにあることを確認するとともに、コードレビュー中にインデントスペースをカウントすることで、仕事をしているように感じるピン頭のマネージャーになってはいけません。

個人的な好みはそれだけであり、生産を改善することはめったにありません：https : //stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

もしそうなら、それを乗り越えて何かを成し遂げてください。

人間がコードのフォーマットを強制し、軽微な違反は丁寧に見落とされたり修正されたりすることを強くお勧めします。この理由は、簡単に言えば、

1. マシンは、最悪のタイミングで、通常は新しい言語機能を使用しているときに誤動作します。Javaなどでクロージャをどのように処理しますか？Jalopyには、メンバー関数を使用した列挙型に関する問題があります。
2. 会社のコードのように見える会社のコードを作成してください、プログラマーにかけることは非常に合理的な負担だと思います。これがコードの「ここ」でのフォーマット方法であり、すべてのコードをどこでもフォーマットする方法ではないことに言及することは有益であることがわかりました。彼らの以前の会社は別の道を選んでいたかもしれませんが、それは問題ありません。固有の言語とは異なり、あなたが引き出したいコード文化に固有のイディオムがあります。
3. コード構文の実施は、コードレビューで行うのが最適です。
   1. 書式設定が重要な場合は、組織がコードレビューを行うよりもフォーマットが重要です。これには大きなメリットがあります。
   2. 書式ルールが破られた場合、意図がより明確に伝えられれば、人間はそれを見てマシンよりも適切に判断できます。これは非常にまれですが、ときどき起こります。

「可読性=>生産性」に関しては、コード構造（単一責任クラスや関数など）を使用すると、コードのフォーマットよりもはるかに速く購入できます。コードの書式設定は助けになりますが、異なる考え方は異なる方法でステートメントを解析します-すべての人が「生産性を高める」わけではありません。書式設定よりもコード構造を二重にしたいと思います。これは、コードのレビューを行い、単一のループの外観ではなく、プログラムの動作についてチームに考えさせるためでもあります。

私はドメイン駆動設計の大ファンではありませんが、コードがどのように構造化されるべきか、ドメイン駆動設計の構造化プログラムからコードのフォーマット規則が自然に流出するという非常に明確な考えを持つ最近のモデルです。繰り返しますが、私はDDDが好きではありませんが、非常に明確に定義されているため、素晴らしい例です。

この答えのテーマは、コードレビューを行い、フォーマットを文化からレビュープロセスの外に流すことだと思います。

一般的に、合理的な開発者を雇うと仮定すると、普遍的なコード形式を課すことは悪い考えです。ただし、コードガイドラインを採用することをお勧めします。

すべてのケースで読みやすさを最適化するコードフォーマットルールのセットを見たことはありません。同様に、英語には100％適用できる文法規則はありません。脳はそのように配線されていません。そのため、ガイドラインを使用しますが、開発者が適切と思われる場合はガイドラインをオーバーライドする自由を与えます。

そうは言っても、「ファイル/プロジェクトに既に存在するコード規約に従う」というより難しいルールは良いルールです。

ただし、書式設定は、コードが論理的にどのように編成されているかよりも、読みやすさにはあまり寄与しません。完璧な書式設定のない読めないスパゲッティコードをたくさん見ました！

これに対する簡単な答えはないと思います。それはイエスかノーの質問ではありません。スタイルと命名規則はある程度重要だと思いますが、それについて考えるのに時間を浪費することはかなり簡単です。例で答えるのが最善です。

私が行っていた特定のプロジェクトで、コンベンションはまったくありませんでした。すべての開発者が独自の方法で物事を行いました。このチームは比較的経験が浅いため、あるクラスから次のクラスに行くのは本当に不快でした。スタイルは命名規則の問題ほど問題ではありませんでした。開発者の1人は、ひどいハンガリー語表記（現代のIDEの時代のばかげた習慣）でUI要素を参照し、ある方法でプライベートメンバーに名前を付け、別の方法で別の名前を付けます。あなたが見ているものを知らなかった。

反対の極端な例では、1つのチームがビルドプロセスの一部としてStyleCop（これは.Netプロジェクトでした）を使用しました。さらに悪いことに、ほとんどのデフォルトルールも使用していました。したがって、行間隔や中括弧の配置に関してはまったく普通のことをしますが、そのためにビルドはおかしくなります。スペースや行を追加するだけで多くの時間が無駄になり、StyleCopを使用すると主張した男を含む全員が、ほぼすべてのコミットを実行することになりました。それは膨大な時間とお金の浪費でした。

ですから、ここで私が主張しているのは、柔軟性に欠けることは答えではありませんが、ワイルドウェストにいることもそうではないということです。本当の答えは、最も理にかなっている場所を見つけることです。私が思うに、自動ツールで物をチェックするのではなく、風に慣らしているのではありません。

共通のコーディングスタイルに対する私の主な主張は、経験豊富なプログラマが自分のスタイルを読むために使用されるということです。特定のスタイルを書くように手を訓練することはできますが、嫌いなスタイルを理解するために目を訓練することはほとんど不可能です。プログラマーは、コードの一部を一度書いてから、開発およびデバッグ中に何度も何度も読み取ります。自分のコードを読むたびに、BADスタイルで書くことを余儀なくされたため、理解するのに苦労すると、非常に不幸で生産性が低下します。これは私の経験からです。

私はEclipseにはあまり馴染みがありませんが、保存の自動フ​​ォーマットは恐ろしいアイデアのように聞こえます。開発者は、コーディングスタイルが課されているかどうかに関係なく、コードを完全に制御する必要があります。「保存」操作は、ユーザーの明示的な同意なしに単一の文字を変更してはなりません。

会社がソースコードを販売している場合、コーディングスタイルがより重要ですが、コンパイルされたコードを販売している場合は、関連性がはるかに低くなります。

コーディングスタイルが元のコーダーの識別性を低下させ、自我戦争を防ぐことを期待するのは、最良の場合はでたらめであり、最悪の場合は愚かです。優れたプログラマーは、スタイルに関係なく常にエレガントなコードを生成します。

また、すべての開発者に特定のコードユニットの所有権を与え、すべてのコードに自由に触れさせないようにすることを強くお勧めします。コードでユニット全体を開発し、それらに責任を負うことで、開発者は自分の仕事に誇りを持ち、バグが戻ってくることを知ってくだらないコードを開発するのを防ぐことができます。

最後に、プロコーディングスタイルの人は、常に自分のコーディングスタイルが選択され、他のすべての人がそれに続くと想定します。すべての共同開発者のなかで最も好みのコーディングスタイルが標準として選択されていると想像してください。あなたはまだコーディングスタイルを課すことに賛成ですか？

それらすべてを支配する1つのフォーマット...それは本当に最適ですか？

それは誰かの車を運転するようなものです...

確かに、あなたはでホップし、任意の車を運転していますが、より安全、より快適に、そしてあなたがするシート、ステアリングホイールとミラーの調整に時間がかかる場合がクラッシュしにくくなりますができYOUR好みを。

コードの場合、フォーマットはコードの読み取りと理解の快適さに影響します。あなたが慣れているものからあまりにも遠い場合、より多くの精神的な努力が必要になります。開発者にこれを与える必要はありますか？

これまでに述べたすべての利点に+1が、しかし...

自動施行には、考慮する必要があるコストが伴います。

コードフォーマッターがコードのフォーマットの美学を理解していないという事実に-1。コードフォーマッタを使用して、表形式で適切に配置されたコメントブロックを破棄したことが何回ありますか？複雑な式を特定の方法で意図的に調整して読みやすさを向上させたのは、自動フォーマットで「ルールに従って」、読みにくいものに変換するためだけでした。

これらの問題に対する回避策がある場合もありますが、開発者は、自動フォーマッターがコードをマングルするのを防ぐ方法よりも、心に留めるべき重要な事項があります。

書式設定のルールはありますが、常識を適用する自由がある程度あります。

優れた開発者は創造的な人々であり、芸術的なライセンスを与えます。「シンプルに保つ」ことは、プログラマーのマントラでなければなりません。私には2つのルールがあります：

ルール1：変数/カーソル/オブジェクト/プロシージャ/わかりやすい名前を付けます。コードに意味と理解をもたらす明確な名前。

ルール2：インデントを使用してコードの構造を示します。

それでおしまい。

私にとって、自動的に適用される一般的な形式の主な利点は、変更の追跡とコードレビューに役立つことです。git（および他のほとんどのソース管理ツール）は、以前のバージョンのファイルの差分を表示できます。共通のスタイルを適用することにより、プログラマーの好みの相違を最小限に抑えます。

また、スタイルガイドを使用すると、さまざまな分析目的でコードをプログラムで簡単に解析できます。

グーグルは、これに関する論文「ビルド債務の検索：Googleでの技術債務の管理経験」を発表しました。

コードではなく言語です。私たち人間は6000以上の言語を持っているので、それらを翻訳します。そのため、「コード」に伝えたい場合は、調整を行う必要があります。データを失うことがないように、ユーザーはデータ形式を変更する必要があります。

私はそうではないと言うでしょう。チーム間で共通のコード構造/形式は、間違いなく良いことですが、自動的に強制することはよくありません。これは、コンピューターではなく人間が行う必要があります。

コンセプトに関する私の最大の問題は

1. 1つの形式でコードを作成し、自動的に再フォーマットされる場合、その形式を実際に学習するためのインセンティブはありますか？
2. その前のポイントに続いて、フォーマットを学習しないと、（コードをより読みやすく、変更しやすくするための）自動フォーマットのポイント全体が完全に失われます。まだコードを読んでいるので、そのフォーマットを学習していないため、フォーマットを理解するのに時間がかかる
3. ある日クラスを書き、それを閉じて、翌日に戻ってそれが完全に異なることを確認することは、開発者としての不快な経験になると思います。つまり、他の人がコードを学習するだけでなく、コードを学習する必要があります。
4. 遅延コーディングも促進される可能性があります。開発者に形式を学習させる代わりに、彼らは太陽の下で任意の形式で書くことができ、他の人が望むように自動的に見えます。これは、スタイルを学習せずに正しく読み取ることができない＃2に戻ります。

今、私はすべてがラップされているプロジェクトで自動フォーマットを実行することは良いアイデアだと言うかもしれません。これにより、後で機能の修正/追加を行うときに、プロジェクトのすべての開発者が同じ足元で開始されます。しかし、積極的な開発中は、非常に貧弱な選択だと思います。

基本的には、従業員に会社のスタイルを学ぶ責任を負わせて、自分のコードをそうでないものに強制しないでください。