12

大規模なレガシーJavaコードベースでのソナー違反の数を減らしたいのですが、これらすべての条件文を中括弧を持つように更新することが「迅速な勝利」になるようです。これは簡単なことのように思えますが、簡単に自動化できない理由がわかりません。

このような一括操作を実行できるツールを知っている人はいますか? または、自分で何かを書くことに時間を費やす前に、なぜそのようなことをするのは悪い考えなのですか? 自分で作成する場合、使用するのに最適なツールは何ですか? 理想的には、Java 言語に対応しているもので、コーナーケースの書式設定などに対処する必要がありません。

ちなみに、このルールは譲れないものなので、これが本当に最善の方法です。

4

8 に答える 8

13

Control flow statement without bracesまず、検査設定で有効にします。

IntelliJ Idea->コード検査の実行->クイックフィックス（少なくとも商用バージョンで機能します）

于 2012-11-11T22:55:16.950 に答える
7

最も簡単な方法は、EclipseClean-upを使用してプロジェクト全体をクリックすることです。Clean-upプロファイル構成で、タブを選択しますCode style。Use blocks in if/while/for/do statementsとして選択できますAlways。

于 2012-11-11T22:50:35.320 に答える
6

レガシ コードに注意することは賢明ですが、レガシ コードのバグを検出することも良いことです。少なくとも、バグを見つけやすくします。

ブライアン・アグニューの困難なケースを考えてみましょう:

// Case #1
if (x) doMethodA(); doMethodB();

実際、JLS と Java コンパイラに関する限り、これは次のことを意味します。

if (x) doMethodA();
doMethodB();

そのため、トランスフォーマーがコードを次のように書き換えると:

if (x) { 
    doMethodA();
}
doMethodB();

コードの意味を変更するわけではありませんが、誰かがコードを読み違えたり、コードに既に存在する潜在的なバグを見逃す可能性がある問題を修正しています。つまり、2番目の呼び出しが条件付きであると想定されている場合...

// Case #2
if (x) 
    // doMethodA();
    doMethodB();

もう一度書き直すと、次のようになります。

 if (x) {
    // doMethodA();
    doMethodB();
 }

これは原文と同じ意味です。さらに、これはプログラマーの意図を反映している可能性が最も高いです...インデントが信じられる場合。しかし、これを考慮してください：

// Case #2a
if (x) 
    // doMethodA();
doMethodB();

それを次のように書き直すと

if (x) {
    // doMethodA();
    doMethodB();
}

コードの実際の意味は変わらず、間違ったインデントが誤解を招くこともありません。プログラマーが最初の呼び出しのコメントを解除することにした場合、以前のコメント アウトが意図しない結果をもたらしたことに気付かない可能性があります。(証拠は、元のインデントに「修正済み」でした。) しかし、潜在的な解決策があります。下記参照。

コード変換ツールが Java の構文とセマンティクスを適切に理解して動作すると仮定すると、まだ壊れていないものを壊すことはなく、既存の壊れた部分を (ある程度) 誰かにとってより明白にすることができます。コードを読んでいます。私にとっては、レガシー コードであってもリスクゼロの勝利です。

ここで、トランスフォーマーをよりスマートにすると、元のインデントがバグの可能性を示しているケース (上記のケース #1 と #2a など) を検出し、より詳細なコード検査のためにフラグを立てることができます。

于 2012-11-12T00:04:01.490 に答える
3

これは潜在的に非常に危険だと思います。単体テストを包括的にカバーしていますか?

私はいくつかのすぐに困難なケースを見ることができます。

if (x) doMethodA(); doMethodB();

と

if (x) 
  // doMethodA();
  doMethodB();

思い浮かぶのは 2 つであり、単純に処理することはできません(これらに取り組むには、言語を認識している必要があります)。言語に対応した信頼できるツールがない限り、そのようなタスクを自動化しようとはしませんが、他の理由でコードを変更するときにコードを修正し、その段階で単体テストを通じてコードカバレッジを主張できるというポリシーを適用しますコードを変更する前に。

于 2012-11-11T22:51:00.120 に答える
2

ロバートはコメントで次のように述べています。「@ira私もこの真に言語を意識したツールを聞くことに興味があります！」

いじめでごめんなさい。いじめの原因については、私の経歴を確認してください。

解き放つ：基盤エンジンとしてhttp://www.semanticdesigns/Products/DMS/DMSToolkit.htmlを参照し、http：//www.semanticdesigns.com/Products/FrontEnds/JavaFrontEnd.htmlを参照してください。このペアは、完全に言語を認識するソースからソースへのプログラムプログラム変換システムを作成します。

このタスクは、2つのソースからソースへの変換ルールを使用したDMSで実行できます。

  rule curlies_for_then_statement:(c:expression, s: statement}: 
             statement->statement
       " if (\c) \s " -> "if (\c) { \s } ";


  rule curlies_for_else_statement:(c:expression, b: block, s: statement}:
              statement->statement
       " if (\c) \b else \s " -> "if (\c) \b else { \s } ";

DMSは正式な文法（この場合はJavaの場合）から完全に駆動され、生のテキストではなく抽象構文木で動作するため、これは確実に機能します。これもレイアウトに依存しません。（「ブロック」、「式」、「ステートメント」は文法の非終端記号であるという規則を理解することはおそらく有用です。

于 2012-11-12T13:56:06.663 に答える
1

それは簡単なソナーの勝利かもしれませんが、あなたはいくつかの危険なことをしています。推奨されるアプローチは、レガシーコードを再検討する必要がある場合にのみ、そのコードを修正することです。これらの包括的なアプローチは、非常に微妙なバグを引き起こす可能性があります。ポリシーが変更されたため、管理チームはこれが大規模な作業であることを理解する必要があり、将来のすべてのコードが標準に合わせて開発されることを保証する必要があります。

于 2012-11-11T22:53:40.463 に答える