以前の
投稿で、私の同僚は、検証モジュール（チェック）の1つの例を使用して、コード内の「
ファシズム 」のプラスの影響のアイデアを明らかにしようとしました。 例とともに、プラグインアセンブリにはいくつかの拡張機能が提供されました。 私たちのチームは、Eclipseでいくつかの新しいチェックを開発し、インストールを簡素化しました。
Checkstyleプロジェクトの使用によるコードの「ファシズム」...そのようなイデオロギーよりも優れているものは何でしょうか？ 通常のコードレビュー中にプログラマーが行ったコメントの半分以上は、コードの記述段階でも修正できます（許可されません）。 テストモジュールの使用は、外観と可読性、ひいてはプログラムのサポート性に大きな影響を与えます。 著者がコードの記述方法と最も人気のあるエラーを表示する方法についての経験を共有する多くの本があります。 すべての自尊心のあるプログラマーは、J。BlochによるEffective Java、J。BlochによるJava Puzzlers、Java Pitfallsなどの本を読んでいます。 しかし、あなたはすべてのヒントを使用していますか？ 実践が示すように、真面目なプログラマーでさえありふれた間違いを犯します。
最初のリリース後、ベストプラクティスを使用するプロセスを簡素化することにしました。 ソリューションは、EclipseのCheckstyleプラグインへのアドオン（機能）として、Checkstyleリリースに含まれていないチェックを使用してプロジェクトを整理することでした。 簡略化されたインストールプロセスは次のように要約されます。
- プラグインCheckstyleプラグイン（update-site： eclipse-cs.sourceforge.net/update ）をインストールします（まだインストールされていない場合）。
- アドオンを追加します（更新サイト： sevntu-checkstyle.github.com/sevntu.checkstyle/update-site ）。
chextileの設定でチェックしたグループを取得します。
図1-テストモジュールの構成のダイアログボックス（チェック）
モジュールをインストールすると、既存のモジュールのリストに「
SevNTUチェック 」という名前で表示され
ます 。 したがって、メインのCheckstyleリリースを待たずに、チェックを完全に使用してJavaコードの品質を自動的に制御できます。 それらの最後について簡単に説明します。
検証モジュール「
ForbidAnnotationCheck 」-チェック構成で指定された注釈の使用をチェックします。 例：
@Autowired
private DataSource dataSource;このチェックを使用すると、クラスのフィールドで
@Autowiredを無効にし、プログラマーを遅延させずに
@Autowiredのセッターを使用
@Autowiredます。
検証モジュール「
VariableDeclarationUsageDistanceCheck 」-
変数の定義とその最初の使用との間の距離をチェックするために使用されます。 距離が初期値を超えると、ユーザーにメッセージが通知されます。 このチェックは、変数の定義とその使用が同じスコープ内にある場合に実行されます。 次のオプションが含まれます。
- allowedDistance-変数の定義とその最初の使用との間の許容距離を設定します。
- ignoreVariablePattern-スキャンから除外される変数名の正規表現を設定します。
- validateBetweenScopes-変数の定義とその使用が異なるスコープ内にある場合の距離チェック。
- ignoreFinal-定義が
finalキーワードを使用する変数を無視します。
検証モジュール「
AbbreviationAsWordInNameCheck 」-クラス、インターフェース、変数、および大文字の略語を見つけるためのメソッドの名前をチェックします。 例：「XMLReader」は「XmlReader」である必要があります。 次のオプションが含まれます。
- allowedAbbreviationLength-略語の連続した大文字の数。 たとえば、「
interface ABCDInterface 」。 ここでは、略語「 ABCD 」と「 Interface 」という言葉。 このケースを無視するには、このオプションで、略語の連続する大文字の数を4に設定する必要があります。 - allowedAbbreviations-無視される略語のリスト。
- ignoreFinal-定義が
finalキーワードを使用する変数を無視します。 - ignoreStatic-定義が
static使用するフィールドを無視します。
検証モジュール "
OverridableMethodInConstructorCheck "-コンストラクター、
readObject 、および
clone mktodovクラスからオーバーライド可能（オーバーライド可能）
public/protectedメソッドの呼び出しをチェックします。
constructor -> private method -> public/protected methodなど、コールスタック全体がチェック
constructor -> private method -> public/protected methodます。
検証モジュール「
ReturnNullInsteadOfBoolean 」-返されたオブジェクトのタイプがメソッド宣言で
Booleanであるが、メソッド自体が
nullを返すことができる状況を監視するのに役立ち
null 。
検証モジュール「
AvoidNotShortCircuitOperatorsForBooleanCheck 」-短絡論理の通常のブール型演算子の代わりにビット演算子（ "|"、 "＆"、 "| ="、 "＆="）を使用するための条件式をチェックします。
検証モジュール「
AvoidConstantsInInterfacesCheck 」-クラスで定数を定義する必要があります（J.Bloch「Effective Java」項19を参照：型を定義するためだけにインターフェースを使用する）。
検証モジュール「
AvoidHidingCauseExceptionCheck 」-例外の原因を隠したことをユーザーに通知します。 例：
catch (IllegalStateException e) {
// your code
throw new RuntimeException();
}このコードスニペット
"IllegalStateException"例外を
"IllegalStateException"ます。
検証モジュール「
IllegalCatchExtendedCheck 」
-catch catch()ブロックをチェックして、
java.lang.Exception 、
java.lang.Error 、
java.lang.Errorなどの例外を
catch() java.lang.RuntimeException 。 次のオプションが含まれます。
- allowThrow-新しい例外がスローされた場合、
catch()ブロックを無視します。 - allowRethrow-
catch()れた例外がスローされた場合、 catch()ブロックを無視します。
検証モジュール「
ReturnBooleanFromTernary 」-三項演算子ブランチの検証を実行します。 ブランチの唯一のコンテンツとして「
true 」または「
false 」を見つけると、メッセージでユーザーに通知します。 たとえば、文字列「
boolean b = a ? false : true; 」の代わりに、「
b = !a; 」を使用することをお勧めします
これらのチェックが誰もが知っている真実であると考える場合、コードをチェックしてください。驚かれることでしょう！
このトピックに興味があり、プロジェクトのチェックを試してみたい人は
、プロジェクトのウェブサイトに招待します。 ウィキは、「開発者を支援するため」に注意してい
ます 。
ご清聴ありがとうございました！
PS FindBug、PMD、Sonar ...これらの製品の存在を知っており、それらからいくつかのアイデアが借りられました。 しかし、いくつかの理由で、特にSheckstyleに力を注いできました。