Help us understand the problem. What is going on with this article?

checkstyleの設定ファイル「google_checks.xml」と「sun_checks.xml」の内容を調べてみた

More than 3 years have passed since last update.

はじめに

checkstyleで自社開発プロジェクト向けの設定を作ろうと考えたのだがどうすればいいのか見当もつかなかったので、checkstyle(7.7)にあるgoogle_checks.xml(Google Style)とsun_checks.xml(Sun Style)の設定を参考にしようと思い設定内容を調べてみた。なので今の所checkstyleの全ての設定は網羅していません。

また動作未確認の設定もあるのでそれらは随時修正していきたいと思います。

※ propertyの説明は省略しているので本家を参照してください。


checkstyle check 説明 Google Style Sun Style 備考
FileTabCharacter タブが含まれていないか -
OuterTypeFilename ファイル名とClassの型名が一致しているか -
IllegalTokenText 禁止した記述が無いか ○(禁止パターン未設定) - tokensでトークン種別を指定、formatで禁止するパターンを設定する
AvoidEscapedUnicodeCharacters Unicodeエスケープを使用していないか -
LineLength 1行の文字数が上限を超えていないか 100 80(default)
AvoidStarImport Import文にアスタリスク(*)が含まれていないか ClassやstaticImportなどは無視する設定も可能
OneTopLevelClass トップレベルクラスが自身のソースファイル以外で定義されていないか -
NoLineWrap 改行されていないか - デフォルトではPackege宣言とImport宣言、static Import 宣言
EmptyBlock 空ブロックが無いか デフォルトではIF-ELS,FOR,WHILE,TRY-CATCH-FINALLY,SWITCH,イニシャライザなどのブロック
NeedBraces コードが{}で囲まれているか デフォルトではIF,ELSE,FOR,DO,WHILE、1行で記述したら無視する設定もできる
LeftCurly {の記述ルール eol(行末)*デフォルト,nl(行頭),nlow(条件文が複数行なら行頭)
RightCurly }の記述ルール。主にIF-ELEやTRY-CATCH-FINALLYのように条件文が分岐する場合の書き方 same(}の後に次の条件を書く)*デフォルト,alone(}の後の記述は認めず、改行する),alone_or_singleline(基本はaloneで1行文のみ{と同じ行を認める)
WhitespaceAround Tokenの’前後’に空白スペースが無いか
OneStatementPerLine 1行に1つのstatmentが記述されているか -
MultipleVariableDeclarations 変数の宣言が1行にまとめられているか -
ArrayTypeStyle 配列の宣言の記述をチェックする true true true=Java Style:Classに配列を定義する(String[] args)/false=C Style:変数に配列を定義する(String args[])
MissingSwitchDefault Switch文にdefaultが記述されているか
FallThrough switch文の各条件内の処理にbreak,return,throw,continueなどが記述されているか - 意図的にThroughさせたい場合は条件式にコメントでfallthruとつける。
UpperEll long型の定数宣言が大文字のLとなっているか
ModifierOrder 修飾子の順番がJavaの推奨に従っているか
EmptyLineSeparator tokenの間に空行を入れているか - Google Styleは、フィールド間の空行はなくても良いOptionを指定している。
SeparatorWrap 改行の仕方が規定通りか ドット(.)は改行後の新しい行につける -
PackageName packageの命名規則 ○(大文字は不可) 規則は正規表現で設定する
TypeName Class,Interface,enum,annotationの命名規則
MemberName メンバ変数の命名規則 ○(2文字目も大文字不可)
ParameterName メソッドのパラメータの命名規則
CatchParameterName chatchパラメータの命名規則 -
LocalVariableName ローカル変数の命名規則
ClassTypeParameterName クラスの型パラメータの命名規則(総称型の仮型引数など) - デフォルトは大文字一文字
MethodTypeParameterName メソッドの型パラメータの命名規則 -
InterfaceTypeParameterName インターフェースの型パラメータの命名規則 -
NoFinalizer ファイナライザーが呼ばれていないこと -
GenericWhitespace 総称型の宣言<>にスペースが入っていないか
Indentation インデントレベルが正しいか ○(basicOffset=2) - basicOffsetのデフォルト値は4
AbbreviationAsWordInName 略称が規定通りか - googleは大文字の連続記述を4文字に規定している
OverloadMethodsDeclarationOrder オーバーロードメソッドがまとまって宣言されていること -
VariableDeclarationUsageDistance 変数を宣言してから使用するまでのSTEP数が規規定通りか 3 -
CustomImportOrder Import宣言の順番を規定する - 順番のルールは公式ページを参照
MethodParamPad メソッドのパラメータの記述が規定通りか パラメータの改行やスペースの許可など
ParenPad 括弧とパラメータの間の記述が規定通りか デフォルトはnospace
OperatorWrap 演算子で改行する際の改行位置のルール nl nl デフォルトはnlで、演算子は次行の先頭に記述する
AnnotationLocation アノテーションを付ける位置に関する規約 -
NonEmptyAtclauseDescription JavaDocTokenに説明があるか @param,@return,@throw,@deprecatedが対象
JavadocTagContinuationIndentation Javadocの説明を改行するときのインデントルール -
SummaryJavadoc Javadocに非推奨なフレーズが無いか -
JavadocParagraph Javadocの段落定義 - デフォルトのルールは公式を参照(Google Styleの設定もデフォルト)
AtclauseOrder Javadoの@の宣言順 - Google Styleは@param, @return, @throws, @deprecatedの4種類だけ定義
JavadocMethod メソッドのJavadoc定義 Google Styleは定義を色々変えているので注意
MethodName メソッドの命名規則
SingleLineJavadoc Javadocが1行で収まる場合に@が含まれていないこと -
EmptyCatchBlock 空のcatchブロックが無いこと - 指定したコメント文であれば無視することも可能
CommentsIndentation コメント行のインデントをコードのインデントと揃えるか -
JavadocPackage packageコメントファイルがあるか -
NewlineAtEndOfFile ファイルの最後が改行コードであるか -
Translation localが違うpropertyファイル同士でkeyに一貫性があるか -
FileLength ソースファイルの行数をチェックする - max:2000行
RegexpSingleline 指定した正規表現に該当する行があるか - 行末にスペース
JavadocType ClassとInterfaceのJavadocが定義されているか - デフォルトでは@author@versionはチェックしない
JavadocVariable 変数にJavadocが定義されているか - serialVersionUIDはチェック対象外
JavadocStyle Javadocのフォーマットをチェックする -
ConstantName 定数のフォーマットをチェックする - デフォルトは、大文字英数字とアンダーバー
LocalFinalVariableName ローカルのfinal変数のフォーマットをチェックする - デフォルトは、小文字の英字で始まり、英数字を許可
StaticVariableName static変数のフォーマットをチェックする - finalが付く変数は対象外
IllegalImport 不正なパッケージのImportをチェックする - デフォルトは、sunで始まるパッケージ
RedundantImport 冗長なImport宣言があるか -
UnusedImports 未使用のImportパッケージがあるか -
MethodLength 1メソッドあたりの行数をチェックする - デフォルトは、max150行。空行やコメント行も含める。
ParameterNumber メソッドやコンストラクタのパラメータ(引数)の数をチェックする - デフォルトはmax7個
EmptyForIteratorPad iteratorの空のパディングをチェックする - (チェック内容がよく理解できていません。)
NoWhitespaceAfter tokenの後に空白スペースがないか -
NoWhitespaceBefore tokenの前に空白スペースがないか -
TypecastParenPad castの括弧に対する空白チェック - defaultは、開始の括弧の後と終了の括弧の前にspaceを許可しない
WhitespaceAfter tokenの後の空白スペースが無いかチェックする -
RedundantModifier 冗長な修飾子が無いか -
AvoidNestedBlocks ネストされたブロックが無いか -
AvoidInlineConditionals インラインでの記述が無いか
EmptyStatement 空のステートメントを検出する -
EqualsHashCode equalsメソッドとhashCodeメソッドの療法をオーバーライドしているか -
HiddenField ローカル変数やメソッドのパラメータがフィールド変数と名称が同じとなっていないか(シャドウ化のチェック) - setterメソッドは無視することもできるがデフォルトではチェックしている
IllegalInstantiation Factoryメソッドを使わずにインスタンス化していないか - デフォルトでは対象Classなし
InnerAssignment 変数の代入の際に、そのステートメントのサブ式で別の変数を宣言していないか - ex.String s = Integer.toString(i = 2)
MagicNumber マジックナンバーを使用していないか - デフォルトでは、-1,0,1,2は許可している
SimplifyBooleanExpression 過度に複雑なブーリアン式を記述していないか - とりあえずこのチェックに該当したら更にシンプルにできないかを考える
SimplifyBooleanReturn 過度に複雑なブーリアンをreturnしていないか - 同上
DesignForExtension 継承しやすいClass設計になっているか - Javadocに拡張方法が書かれているかを見ている
FinalClass privateなコンストラクタしか持たないClassにfinalがつけられているか -
HideUtilityClassConstructor staticなメソッドやフィードしか持たないClassにpublicなコンストラクタを宣言していないか - このようなクラスをユーティリティークラスとみなしている模様
InterfaceIsType インターフェースにメソッド宣言があるか -
VisibilityModifier classのメンバーはprivateで定義され、アクセッサがあるか -
FinalParameters メソッドやコンストラクタのパラメータにfinal修飾子をつけているか -
TodoComment TODOコメントが残っているか -

命名規則の正規表現

checkstyleのDefaultは、 ^[a-z][a-zA-Z0-9]*$が基本で先頭だけ小文字の英字としている。Sun Styleはこれに則っている。

Google Styleでは多くの命名規則を、^[a-z]([a-z0-9][a-zA-Z0-9]*)?$とし、先頭だけでなく2文字目も小文字にしている。(ハンガリアン記法の禁止?)


考察

  • google_checksをベースにプロジェクトのstyleを作りたい。
    とはいえ、そのままだと一部のコードで不都合があるからpropertyレベルの変更は必要。
  • sun_checksの設定内容は、IDEのinspectionと重複しているものが多い印象だった。
    だけどウチの規約上で入れておいた方が良いチェックもあった。
  • ここまで来たら、全部のスタイルの定義を調べておきたいので、いずれ更新したいと思う。
kazokmr
自分のための記録用です
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away