352.PMD(2)
初回：2024/02/21
前回は、PMDのインストールと実行までできたと思います。今回は、カスタマイズについて、軽く述べたいと思います。
P子「カスタマイズするのが通常なの？」※1
前回も少し書きましたが、『すべての警告を無くす』のではなく『プロジェクトごとに必要な分だけ確認する』というスタンスが正しい使い方だと思います。
まずは、前回動作させた、『rulesets/java/quickstart.xml』をカスタマイズしてみましょう。
1.ルールファイルの作成
まずは、前回のカスタマイズ前の状態からです。
pmd.bat check -d c:\src -R rulesets/java/quickstart.xml -f text
前回も書きましたが、javaのパスと、PMDインストールディレクトリの bin フォルダ内へのパスも必要です。このままだと、標準出力に書き出されるので、ファイルに書き出すようにしてみましょう。
call 《独自にJavaの環境設定を行うbatファイル》
set SRC_PATH=c:\src
call bin\pmd.bat check --dir=%SRC_PATH% --rulesets=rulesets/java/quickstart.xml --report-file=pmd_check.txt
標準出力なら、結果が画面に流れるので、後でコピー＆ペーストする必要がありますが、ファイルにセーブすれば後で見るのが簡単です。さらに、処理の進捗バーも表示されるので、良いと思います。
もう一つ、設定しておきましょう。
set CACHE_FILE=c:\cache\pmd.cache
cache というフォルダを作成して、pmd.cache ファイル名を指定します。
call bin\pmd.bat check --dir=%SRC_PATH% --rulesets=rulesets/java/quickstart.xml --cache %CACHE_FILE% --report-file=pmd_check.txt
これで、処理結果のキャッシュが有効になるので処理時間の短縮が図れます。
この状態で動くことを確認したうえで、独自ルールを作成してみましょう。まずは、rulesets フォルダを作成して、quickstart.xml というファイルを作成してみます。といっても参考になるファイルが必要なので、github から、オリジナルのファイルを持ってきましょう。
https://github.com/pmd/pmd/blob/master/pmd-java/src/main/resources/rulesets/java/quickstart.xml
ここから、quickstart.xml を持ってきますが、そのまま使いません。
xml の ruleset の属性情報だけ持ってきて、rule に、rulesets/java/quickstart.xml を使うようにします。
ファイル名を、customset.xml にします。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset name="customset"
xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 https://pmd.sourceforge.io/ruleset_2_0_0.xsd">
<description>
Github Collect Rule Set
https://docs.pmd-code.org/latest/pmd_rules_java.html
</description>
<rule ref="rulesets/java/quickstart.xml" />
</ruleset>
先ほどと異なり、呼び出す rulesets はこちら側です。
call bin\pmd.bat check --dir=%SRC_PATH% --rulesets=rulesets/customset.xml --cache %CACHE_FILE% --report-file=pmd_check.txt
これが、先の rulesets/java/quickstart.xml を指定したときと同じになることを確認してください。
2.カスタマイズ
今回は、最も簡単なカスタマイズ...ルールを除外する方法を示します。
ルールを除外する最も簡単な方法は、exclude でルール名を指定します。
<rule ref="rulesets/java/quickstart.xml" >
<exclude name="UnnecessaryImport"/>
</rule>
削除できる import を見つけてくれますが、static import を誤検知するのでいったん削除します。
同様に、rulesets/java/quickstart.xml に含まれる 自分のプロジェクトにとって不要なチェックは削除します。
<rule ref="rulesets/java/quickstart.xml" >
<exclude name="UnnecessaryConstructor"/>
</rule>
UnnecessaryConstructor は、不要なコンストラクタ の警告で、空のデフォルトコンストラクタのみのクラスで警告を出しますが、私は常にデフォルトコンストラクタを作成します。
P子「コンストラクタの無いクラスは、デフォルトコンストラクタをJavaのコンパイラが自動作成してくれるのよね」
職場によっては書く必要のないコードは書かないとか、自動で作成されるのだからコンパイラに任せるべきという考えもあります。それも正しい判断です。
この自動生成には条件があって、例えば引数付きのコンストラクタを作成した場合は、デフォルトコンストラクタは自動生成されません。例えば、自動生成の場合、new Foo(); で、オブジェクトを生成していた場合、引数付きの Foo(Strong val) みたいなコンストラクタを追加した場合、忘れずに、デフォルトコンストラクタの作成も必要です。もし、作り忘れた場合、他のプログラムから、new Foo(); で、オブジェクトを生成できなくなります。同時にコンパイルを作成している場合は気づきますが、利用している他のプログラムからは、実行時にエラーが出てしまいます。
なら、初めから、どのようなケースでも、デフォルトコンストラクタを作成しておくというのは『有り』の戦略だと思っています。
3.まとめ
今回は、カスタマイズの中でももっとも単純な、ルールの削除を取り上げました。
次回は、個別のルールの条件を変更するというカスタマイズのお話をしていきたいと思っています。
ほな、さいなら
======= <<注釈>>=======
※1 P子「カスタマイズするのが通常なの？」
P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。