モジュールの変更/追加中に別の開発者コードを再フォーマットしても大丈夫ですか？

グループ環境で開発し、一部のコードベースで機能を追加または変更しているとき。以前の開発者のコ​​ードを再フォーマットして現在のコーディング標準に合わせるのは不快または失礼と見なされますか？標準が変更され、おそらく変更され続けることを理解していますが、誰かがコードフォーマットを変更して変更した場合、あなたは気分を害するでしょうか？

明確にするために、タブやスペースなどをいじるだけで、ロジックの変更については話していません。

編集：コーディング標準のためにこれを行うだけでなく、コードを読んで最新にするので、重要なアプリケーションの変更を開始する前に実装されたロジックを完全に理解できます。

基準が合意されている限り、これは問題ないと思います。ただし、注意点が1つあります。ファイルが他のユーザーによって同時に変更されている可能性がある場合は注意してください。書式設定を変更しただけでマージを難しくすると、あまり人気がありません。

はい、コードはプロジェクトに属している必要があります。コードを標準に引き上げることで、プロジェクトの技術的な赤字を減らすことができます。変更する場合は、現在あなたが責任を負います。古いコードの場合、元の開発者はプロジェクトに参加していないか、新しい職務に就いている可能性があります。

この種の変更を行う場合、再フォーマット後に検証テストを実行することをお勧めします。合格した場合は、機能の変更を行う前にコードをチェックインします。

編集：この質問の文脈では、標準への再フォーマットが適切です。標準がない場合は、標準を推奨し、形式の標準があるまで再フォーマットしないことをお勧めします。プロジェクトに属するコードを使用して、個人の好み/標準に再フォーマットすることはできません。

特定のファイルを変更/追加するときにコードをリファクタリングすることは常に良い習慣だと思います。これには、変数/メソッドの適切な命名規則とコーディングスタイルを反映するようにコードのスタイルを更新することが含まれます。

私はいつもこれをしています。古いコードは新しいコードと同じ標準に準拠する必要があり、作業中に修正しなければ誰も修正しません。これはボーイスカウトルールにも当てはまると思います。

これは良い習慣であり、コード保守の必要な部分だと思います。

バージョン管理システムへの1回のコミットでフォーマットの変更をチェックインし、別のコミットで機能の変更をチェックインすることをお勧めします。

私はそれについて何の問題も持たず、おそらく感謝するでしょう...変更が「宗教的」でない限り。すべてのクラスを調べて、中括弧をメソッドの最初の行に移動しないでください。フォーマットが正当な「異なる人々のための異なるストローク」タイプのものである場合、誰かが入って最も頻繁に編集するコードにフォーマットを課すとき、それは少し面倒です。ただし、その特定のモジュールの主要なエディターになった場合は、適切なフォーマットの変更を行ってください。

はい。適切と思われるコードを「修正」してください。Pragmatic Programmersが本The Pragmatic Programmerで言っているように、壊れたウィンドウはありません。コードが標準に達していない場合、私はそれを壊れたウィンドウと見なします。

ソースを取得するプラットフォームに応じて、チェックイン時に自動的に再フォーマットを実行するさまざまなリポジトリや、取得時にCR / LFペアリングを変更するような小さなものがあります。

独自の再フォーマットを行うことには大きな欠点があります。デルタのチェックは大量の再フォーマットによって難読化され、回帰の問題がある場合は問題のあるコードブロックを見つけるのが難しくなります。

コードベースが古いため、コードベースを一度にまとめて現在の標準に再フォーマットし、どこにでもコードの明るい未来をもたらすことをリードに提案できます。

あなたは純粋に「フォーマット」の問題を話しているので（バグを修正するのではなく、自分の基準に合わせて見栄えを良くすることを意味します）、元の人がまだコードを維持しているかどうかに依存すると思います。

創始者がまだプロジェクトに取り組んでいる場合-それは失礼です。あなたにとって「見える」かもしれないのは、彼らにとって「見える」ということではなく、フォーマットのためにコードを修正することは丁寧ではありません。また、多くの時間を無駄にする可能性があります。

私は非常に所有権のある開発者と一度プロジェクトに取り組んでいました。長年にわたって、コードをフォーマットする非常に系統的な方法を開発してきましたが、これは読みやすく、暗黙のミスが少なく、自己文書化が容易だと感じています。一方、この男は、300文字幅に広がる長い行を持つすべての暗黙の機能を使用することを好み、読みやすさよりも行数の方が重要であると考えたため、30インチモニターを読む必要がありました。私のコードを吹き飛ばして彼の「好みの標準」に変えました...私はまだ並行して開発を続けていました！翌朝、彼の混乱に合わせてフォーマットされた2日間の作業を見つけました。

開発者がいなくなって、あなたが「より良いスタイル」を手に入れたら。

IDEで可能な場合は、常にコードを自動フォーマットします。

• 手動でのフォーマットの変更により、長期的にバージョン履歴が乱雑になるのを防ぎます
• フォーマッタープロファイルは、すべての開発者の間で同意する必要があります（デフォルトを選択しますか？）
• ファイルを保存するときに、書式設定コードとインポートの整理を習慣にする

たとえば、Eclipseでは、最初にフォーマッターを実行し、コードベース全体のインポートを整理できます。次に、保存する前にctrl + alt + fを忘れないでください。