6

私たちのチームは最近、非常にまとまりのないコードを継承しました。

その結果、私のチームリーダーは、ファイルを保存する前にコードの自動フォーマットのポリシーを適用することを決定しました。Eclipse(選択したIDE)には、各保存アクションの前にコードを自動的に自動フォーマットするオプションもあります。

個人的には、適切なコーディングは(ほとんどの場合)厄介なコードを防ぐと思いますが、自動フォーマットは適切なコーディングを意味しないと思うので、私はそれに反対しています。

あなたの意見は何ですか?

4

12 に答える 12

16

私はあなたに同意しません。私にとって、フォーマットは、ソースコードを「提示」する方法にすぎない場合でも、重要なコード品質の指標でもあります。

自動フォーマットを使用すると、いくつかの利点があります。チームのすべての開発者の間でフォーマットを均質化します。これにより、SCM操作に関する問題を回避できます。たとえば、実際の変更がほとんどない2つのファイルをマージしますが、フォーマットの違いが多いのは悪夢です。

また、いくつかのエラーが表示されることもあります。例えば:

if (aCondition)
    foo();
    bar();

再フォーマットされます:

if (condition)
    foo();
bar();

2行目がステートメントにないことを示していますif

最後になりましたが、(Javaだけでなく)適切にフォーマットされたコードの方が読みやすくなっています。

于 2009-11-04T14:51:03.863 に答える
8

継承されたコードを1回だけ自動フォーマットしてから、自動フォーマットせずに続行します。

于 2009-11-04T14:47:44.167 に答える
5

私の意見では、一貫したコードフォーマットは読みやすさを向上させます。それは明らかに良いコードに代わるものではありませんが、一方で、だらしなくフォーマットされた最も素晴らしい構成は、良いコードとは言えません。

私にとっての自動フォーマットの問題は、ほとんどの場合、バージョン管理システムに影響を与えることです。ただし、フォーマットを1回変換するだけで、他の変更を加えることなく、ワークフローを改善できる可能性があります。

于 2009-11-04T14:52:39.990 に答える
3

一貫性のあるコードフォーマットは、コードを送信する際の差分などに役立ちます。

ソース管理スクリプトを、プッシュ時に「ハウススタイル」に自動フォーマットし、プル時に好みのスタイルに自動フォーマットするように構成したので、誰もが満足しています。

同じことを検討することをお勧めします。

于 2009-11-04T14:54:56.867 に答える
3

私はこれについてあなたのチームリーダーと一緒にいます、そして私はあなたに2つの提案があります:

  1. 各ファイルを1回保存します。唯一の変更は、これがすべて変更されたことを反映するコミットメッセージを含むフォーマットです。その後、戻って実際のコードを変更します。これにより、変更を比較する必要があるときに多くの時間を節約できます。フォーマットリビジョンでは、コードのほぼすべての行が変更されるため、同じリビジョンで実際の変更を見つけることは事実上不可能です。

  2. コーディング標準に同意し、その標準に従うようにEclipseの自動フォーマットツールをカスタマイズします。

于 2009-11-04T15:19:38.227 に答える
2

私たちは実際にEclipseで自動フォーマットを使用しており、多くの場合、たとえば多くの改行に挿入することで、コードが読みにくくなります。また、新しいEclipseバージョンに移行したため、同じ設定を使用したにもかかわらず、形式は同じではありませんでした。これは、バージョン管理システムと組み合わせると大きな欠点になります。一貫したコードスタイルを実現するには、CheckStyleプラグインの方が好きです。

しかし、前述のように、ファイルをリファクタリングするときに一度自動フォーマットを使用します。

于 2009-11-04T14:54:01.733 に答える
2

「無秩序」の意味によって異なります。私たちは文体の矛盾について話しているのですか、それともクラス構造は理解できない寄せ集めですか?オートフォーマッターで対処しているのなら前者だと思います。

「適切なコーディング」は、必ずしも「開発者間で一貫している」ことを意味するわけではありません。エディターを4スペースのハードタブに設定し、エディターを3スペースのソフトタブに設定している場合、両方で作業するコードはお尻のように見えます。(そして、私たちのプロジェクトマネージャーは、おそらく私たちの頭をひっくり返し、どの標準を使用すべきかを知らせてくれるはずです。)

オートフォーマッターは少しブルートフォースソリューションであり、時折異常であるが完全に読み取り可能なものを混乱に変えることがほぼ保証されています。コードが本当に混乱している場合、それは賢明な出発点です。ただし、既存のコードからSuckの大部分を自動フォーマットしたら、チームの好みのスタイル規則を確立して、そこから先に進むほうがよいでしょう。

于 2009-11-04T14:58:22.990 に答える
2

私は開発チームのリーダーとして、自動フォーマットに反対しています。読み取り可能なコードは重要であるため、責任ある開発者が必要に応じてコードをフォーマットできることが重要です。自動フォーマッタは、慎重に作成されたコメントを台無しにする可能性があり、明確にするために挿入された余分な空白行を削除します。

遵守しなければならない標準のルールセットを備えたcheckstyleのようなプラグインを使用します。チェックインされたコードには、checkstyleの警告がないはずです。構造化されていないコードが発生した場合、Eclipseフォーマッターは最初のクリーンアップを実行でき、checkstyleと友人は解決すべき問題を指摘します。

于 2009-11-04T17:14:04.463 に答える
1

コードのフォーマットは重要だと思います。与えられた例は、そのようなばかげたエラーが忍び寄る可能性を強調していますが、私はこの例を使用して、常に中括弧を使用することを主張します!

さまざまなフォーマットのソースファイルを見るときは、コードを理解するためにもっと努力する必要があると思います。通常のコードパターンでは、ステートメントがすべて「適切な場所に」あるため、セマンティクスを理解しやすくなります。

何が「適切」であるかについては少し曖昧に見えるので、「適切なコーディング」が何を意味するのかわかりません。通常の状況ではおそらく決して使用されるべきではない言語構造と、避けるべきソフトウェアエンジニアリングのアンチパターンがあります。これらが適切なコーディングの意味するものである場合は、これらが重要であることを確認してください。ただし、ソースファイルドキュメントのフォーマットには反映されません。

フォーマットビルドの失敗に違反することにより、ソースファイル内のコードフォーマットを強制するツールがあります。最初は、そのようなツールは少し厳しく見えるので懐疑的でしたが、コードの構造が均一であると、生産性が大幅に向上することがわかりました。

PS最後のステートメントは、バックアップするメトリックがないため、完全に逸話的です。

于 2009-11-04T15:11:04.273 に答える
0

あなたのキャリアにおいて、あなたは個々の会社の基準に従うことが期待されます。つまり、多くの場合、ポリシーに同意できない可能性があります。

自動フォーマットに会社の標準を使用しなければならないことについて不平を言うことは専門家ではなく、あなたがチームプレーヤーではないと彼らが考えるので、上司や上司があなたを見る方法にとって最終的には悪いことです。あなたはそれがあなたが望むものからどれほど離れていても標準的なフォーマットに慣れ、いつかあなたがマネージャーであるとき、あなたはフォーマットがどのように行われるかを選ぶことができます。その間、それはあなたの電話ではなく(あなたはコードベースを所有していません、会社は所有しています)、あなたはあなたがするように頼まれたことをする必要があります。

自動フォーマットによってコードが読みにくくなるという有効な例がいくつかある場合は、それらを上司と共有できますが、正直なところ、これは勝つ可能性が低い戦いであり、試してみると見栄えが悪くなります。

于 2009-11-04T20:03:31.407 に答える
0

Eclipseで自動フォーマットを有効にすることで考えられる問題の1つは、ソース管理を使用している場合(ソース管理を使用している場合)、差分が大きくなり、何があったのかを解読するのが困難になる可能性があることです。実際のコード変更とフォーマット変更。

そうは言っても、適切にフォーマットされたコードを持つことは、堅実なソフトウェアを作成するために重要です。

于 2009-11-04T14:54:38.900 に答える
0

コードのフォーマットは非常に重要です。

  • コードを適切にインデントしておくことで、中規模または大規模のファイル間を移動しやすくなります。
  • すべてのプロジェクトで一貫したコーディングスタイルを維持することにより、人々が他のプロジェクトに移動するときに、コードに慣れることができます。もちろん、これはコーディングガイドライン、変数の命名方法などにも関連しており、共通の立場で比較的正規化する必要があります。
  • 適切なコードフォーマットルールを実行することに時間を費やすと、より多くのユーザーがコードを表示できるようになります(残念ながら、テキスト[メモ帳やemacs]を手作業で何度も編集する必要がありました。行の長さは80列程度になります)
  • 最も重要なことは、フォーマットの一貫性を保つことで、2つのファイルをはるかに簡単に比較できることです。
于 2009-11-04T15:19:14.513 に答える