開発チームでさまざまなコーディングスタイルをサポートする方法はありますか

問題：2人の開発者=>インデントに関する3つの意見、改行の有無など

私たちは通常、プロジェクトで3人または4人で作業し、それぞれに独自のコードスタイルがあります。共通の解決策はコードスタイルに同意することであり、誰もが使用する必要がありますが、クリエイティブプログラマーにそれらに合わない訴訟を強いることは望みません。

質問は次のとおりです。各プログラマーが独自のスタイルを生きながら、リポジトリ内に共通のコードベースを持っている方法はありますか？私は、いくつかのgit / svn / whateverプラグインについて考えます。これは、チェックアウト時とコミット時に個人的なスタイルと一般的なスタイルの間で変化します。このアプローチのトリッキーな部分は、ファイルのバージョン間の正しい差分をサポートすることであるように思えます

いいえ、標準を作成する必要があります。チームメンバーBが（自動IDEツールを使用して、または手動で）変更した場合、チームメンバーAが作成したコードのヒープ全体がコミットされ、変更として表示されます。

これはほとんどすべてのチームが直面しているものであり、この理由から標準は「強制」されています。言語当局の基準をベースラインとして、チームに合わせて採用することをお勧めします。

一貫したコーディングスタイルを持つことは、プロジェクトの保守性にも役立ち、コードに取り組んでいる新しい人々の参入障壁を減らします。

いいえ、コーディング標準（できれば既存のもの）を定義し、開発者にそれを遵守させる必要があります。プロのプログラマーであるということは、作業中のプロジェクトで使用されているコーディング標準に適応できることを意味します。

はい、スタイルがすべて理にかなっており、他の人のコードを好みに合わせて変更したり、スタイルを単一のコードファイルに混在させたりしない限り、機能します。
理想的ではありませんが、作成された古いコードを自分の「標準」とは異なるものに継承し、コードベースと統合する必要があることと違いはありません。
あなたがそれをしなければならない場合、いくつかのガイドライン：

• 好みに合わせて異なるスタイルのコードを変更する必要はありません。時間がかかり、バグが発生します
• 単一のファイル内で一貫性を保ちます。したがって、スタイルAを最初に記述するために使用された場合、誰もがスタイルAを変更するときに使用します
• パブリックインターフェイスの共通標準を作成して、外部に公開されるすべての要素を作成します（そして、はい、システムの他のサブコンポーネントは外部です）。

短い答えはいいえです。

特にソフトウェア開発などの知識ベースの仕事では、仕事で意見を評価する必要がありますが、開発者は意見が単なる意見であり、どの行インデント標準が最適であるかを議論しないソフトウェアを書くためにそこにいることを認識しなければなりません。

標準文書の目標は、対処する共通のコーディング標準/規約のセットを実施/提案することです。

1. タブ、インデント、{、（の使用などのレイアウト項目
2. 変数、オブジェクト、関数名、つまりキャメルケース、ハンガリー語表記
3. 例外処理方法/いつ/どこで実行されるか
4. コードのコメント。常に設計ドキュメント、バグ番号などを参照していますか

標準ドキュメントは、コードが読みやすく、保守しやすく、規約に一貫性があることを保証するのに役立ちます。

これは、チェックイン前にコードをレビューしたり、他の人のコードをデバッグしたり、元の開発者が会社を辞めてから数年後にコードを変更したりする場合に非常に役立ちます。

通常、コーディング標準文書を作成するときは、使用している言語（C、C＃、SQL）の業界標準を確認し、最も適切な標準を使用し、コメントのために最も上級/影響力のある開発者に配布し、必要に応じてコメントを組み込みます。ドキュメントをリリースします。

理論的には、バージョン管理システムにコミットされる前にコードを自動的に再フォーマットすることは可能です。

ただし、1つの大きな問題があります。自動コードフォーマットツールは100％信頼性がありません。したがって、実際にこのシステムでコードに問題を引き起こす可能性があります。私の考えでは、それはアイデアを殺します。適切にスタイル設定されたコードよりも機能的なコードを使用することが常に重要です！

プロジェクトが区分化されていて、コードのほとんどの部分が個々のプログラマーによって「所有」される傾向がある場合は、独自のスタイルを（理由の範囲内で）使用しても構いません。ただし、複数の人が同じコードで頻繁に作業している場合は、おそらくスタイルを強制する必要があります。

Stack Overflowに関する同様の議論があります。

次の場合は、一方向の自動再フォーマットコードが実行可能なソリューションである可能性があります。

1. 実装したい規則とプログラミング言語で実際に機能するオートフォーマッタを見つけてください。
2. 事前にコミットして、再フォーマットが実際の機能変更と混同されて区別できない変更ログに表示されないようにすることができます。
3. 少なくとも、私が知っている限りではないが、開発者の個人的な好みにチェックアウトする際に「戻る」ことができないため、どの規約を適用すべきかをチームに同意させることができます。

多くの場合、これらはどれも簡単に実行できるものではないため、ここで戦闘を選択することを検討してください！開発者のPCで既に再フォーマットが行われているC＃/。NETプロジェクトに対して、チームがこれを正常に実行するのを見てきました。そのため、状況によっては可能です。

絶対にできます。その小さなものを発汗しないことについてのすべて。

重要な唯一の標準は、「変更を既存のコードと同じスタイルに保つ」ことです。好みのものではないコーディングスタイルに身を任せることができれば、どのコーディングスタイルでも作業できます。

それで、同じ会社内で3つの異なるスタイルで働くことの大したことは何ですか。あなたの開発者は、方法、彼らのようにコードを書くことが自分のコードのために見つけることですが、彼らは別のスタイルを使用して別のファイルに変更を加えた後、彼らは、このことを理解する必要がある必要があり、そのスタイルを維持するために（またはそれは本当に悪い見ていきます） 。再フォーマットは許可されていません（または継続的に再フォーマットしているだけなので、scm diffは役に立たないでしょう）（これを行う場合は、自動フォーマットを採用する必要があります）。

チャンスは、一度これを使用すると、どのスタイルを使用するか、またはほとんどの場合スタイルが一緒にドリフトするかについて、コンセンサスが得られることです。彼らがそれについて子供っぽくなり、常にお互いのコードを再フォーマットする場合は、インターネットから標準をダウンロードして、それを使用するよう要求する時が来ます。とにかくこれをやりたいと思うかもしれません、彼らの顔に「ナイスプレイまたはその他のプレイ」カードとしてそれを振るだけです。