プロジェクトをフォークして作業する場合、機能の実装やバグの修正とともに、コードの書式設定の修正を提供しても問題ありませんか?
これには次の例が含まれます。
プロの意見: フォーマットを修正すると、全体的なコードの品質が向上します。
短所: ファイルの無関係な部分のフォーマットを修正すると、ツールがコードの作成者としてあなたを指し示すようになり、後で同じ部分に取り組む人々は、あなたが作成したという誤った印象を受ける可能性があります。
適切な比較ツールは、空白を無視するように設定できますが、中括弧を新しい行に移動するなどのことを行った場合に役立つわけではありません。
私があなたなら、2 つの変更を提出します。1 つは実際のバグ修正で、もう 1 つはコードのフォーマットを修正したものです。
誰もがわずかに異なるコード スタイルを持っており、一部のスタイルは他のスタイルよりも適切または優れているとは限らないことに注意してください。そうは言っても、コードが本当にひどい方法でフォーマットされている場合は、それを修正する必要があります.適切にフォーマットされたコードは、デバッグとコードレビューに役立ちます. あなたは変更の作成者として表示されますが、モジュール自体の作成者と間違われてはなりません - まともなソース追跡ツールであれば、誰が何をいつ作成したかを表示する必要があります。
ここで私が提唱しているのは、コーディング スタイルの小さな違いは無視できるし、無視すべきだということです。十分な経験を積んだ開発者であれば、コードを読んで理解できるはずです。チームは、変数名のキャメル ケース、メソッド名の正しいケース、メンバー変数のアンダースコアなど、全体的に統一されたコーディング アプローチを持つ必要がありますが、LINQ ステートメントの書式設定などは個々の開発者に任せることができます (そうでない場合)。本当に読めません）。さまざまな文化や背景を持つメンバーと一緒にオープンソース プロジェクトに取り組んでいると、意見の相違に直面することになります。ReSharper のようなツールを使用すると、これらの違いの一部を解消できますが、共同プロジェクトでは、すべての人が ReSharper を持っているわけではありません (または、開発されているものによっては、半分まともな IDE でさえあります)。
醜いものは必ずフォーマットを修正してください。開発者は、エンジニア、アーティスト、そして人間の組み合わせです。違いが生まれます。素晴らしい開発者になるためには、何を受け入れ、何を変えなければならないかを学ぶ必要があります。
成功する開発チームになるための基本的なルールは、「全員が 1 つのスタイルにのみ従う必要がある」というものです。
フォーマットを修正するだけでなく、そのコードの作成者に通知する必要があります。コーディング スタイルに関して誰もが同じ認識を持っている場合、他の人が書いたコードを読むのに半分の労力がかかり、他の人が書いたコードをそのまま維持することができます。良い。