Checkstyleプラグイン設定 - 設定はこうすれば楽なんじゃねーの?その2 - JavaDocコメントのデフォルトフォーマットがコードフォーマットの警告に引っかかってしまう点に対応
2008.11.17 ｜Category …Eclipse
Eclipse標準のコードフォーマットを使っている場合、Javadoc部分のフォーマットに余分なスペースが挿入される。
たとえば、
1:/**
2: * うんこ
3: *
4: * 死ねばいいのにね
5: */
というコメントを書いた場合、Eclipseのフォーマット(CTRL+SHIFT+F)をすると3行目が' *'=>' * 'と置換されてしまう。(余分なスペースが入る)
これは他の設定(どこだろ？わかったら書きます)に引っかかって警告になっています。
これをCheckstyleの警告から外すにはFilters->Suppression CommentでoffCommentFormatに 「\/**」、onCommentFormatに「\*/」と入力すればJavadoc部分の行末スペースが無視されるようになります。
たとえば、
1:/**
2: * うんこ
3: *
4: * 死ねばいいのにね
5: */
というコメントを書いた場合、Eclipseのフォーマット(CTRL+SHIFT+F)をすると3行目が' *'=>' * 'と置換されてしまう。(余分なスペースが入る)
これは他の設定(どこだろ？わかったら書きます)に引っかかって警告になっています。
これをCheckstyleの警告から外すにはFilters->Suppression CommentでoffCommentFormatに 「\/**」、onCommentFormatに「\*/」と入力すればJavadoc部分の行末スペースが無視されるようになります。
PR
Checkstyleプラグイン設定 - 設定はこうすれば楽なんじゃねーの?その1 - setterメソッドにフィールドを隠してるの警告はいらないと思う。
2008.11.17 ｜Category …Eclipse
Coding Problems -> Hidden Field ->
ignore ConstructorParameter をオン
ignore Setter をオン
そもそもそのクラスメンバに値を入れ込みたいのにあえて別変数を指定する必要はないよね。
むしろsetterに限っては値を編集しないで設定する場合に限りだが、パラメタ名はメンバ変数名と同一にするべきだと思う。
頭悪い人が使うと引数名に"p"をつけるとかやってEclipseの補完機能で意味のわからない変数名が出てきて実装者をイラっとさせるですよね。<実際、このCheckstyleのWarning回避の為に全ての引数の変数名にp、もしくはvをつける、という酷いルールを見たことがあります。
最低なのは全ての引数がarg1,arg2････(バグだらけで大変そうでした。)
ignoreAbstractMethodsはどうなんだろ?私はオフでいいとおもいますが･･･
メンバ変数も同時にいじりたいメソッドを抽象メソッドで定義する必要があるかどうかは知らないしもしあったとしても値をセットする部分はfinalメソッドかなんかに書いてその中身で抽象メソッドを呼んであげた方が安全かも。
ignore ConstructorParameter をオン
ignore Setter をオン
そもそもそのクラスメンバに値を入れ込みたいのにあえて別変数を指定する必要はないよね。
むしろsetterに限っては値を編集しないで設定する場合に限りだが、パラメタ名はメンバ変数名と同一にするべきだと思う。
頭悪い人が使うと引数名に"p"をつけるとかやってEclipseの補完機能で意味のわからない変数名が出てきて実装者をイラっとさせるですよね。<実際、このCheckstyleのWarning回避の為に全ての引数の変数名にp、もしくはvをつける、という酷いルールを見たことがあります。
最低なのは全ての引数がarg1,arg2････(バグだらけで大変そうでした。)
ignoreAbstractMethodsはどうなんだろ?私はオフでいいとおもいますが･･･
メンバ変数も同時にいじりたいメソッドを抽象メソッドで定義する必要があるかどうかは知らないしもしあったとしても値をセットする部分はfinalメソッドかなんかに書いてその中身で抽象メソッドを呼んであげた方が安全かも。
Checkstyleプラグイン
2008.11.17 ｜Category …Eclipse
プラグ印。IMEの変換、英単語ぐらいはしっかり変換してほしいぞ。
さて、Javaで開発業務を行うにおいて事実上標準になっているのがオープンソースのJava総合開発環境Eclipse
ですな。SunやBolandもIDEを出してるようですが、私が仕事するにおいてはほぼ全部Eclipseで開発してました。
(WSADを使ってたときもありましたがまぁ、Eclipseファミリ(捉え方は逆かもしれんが)ということで･･･)
さて、Eclipseを使う上で便利なことのひとつにプラグインが豊富という事があると思います。
その中でも今の私にはずせないもののひとつにCheckstyleプラグインなるものがあります。
(本当はFindbugsの方が重要度が高いんですがたまたま今いじってたのがCheckstyleだった^^;)
CheckstyleはEclipseで動く単なるコーディングチェックツールです。
単なるコーディングチェックツールなんですが、何気にコーディングチェックってのは厳密に行うのは難しく、小規模のプロジェクトでさえ気がつくともう当人以外見られたものではないソースコードが山ほどできてしまうもので、それを回避する術はコードレビューをマメに行うぐらいしかないのかと思っています。(可読性について気にしない人は自己チェックができないので他人の目を介する必要があります。)
実装者がコードを書いているときにリアルタイムにコードチェックができるのはすばらしいですね。
経験上、可読性の低いコードがバグってるときは改修により更にバグを生む傾向があると思われ、できるのであれば初回製造時点でコーディングを型にはめるべきだと思います。
欲を言えば変数やメンバの名前の意味まで考えてくれるといいんですけどねー。
・プロジェクトのコーディングルールで「値チェックメソッドは「validate～」とする。
・変数名(クラス名、メソッド名含む)は英語とする。
・キャメルケースに従うこと
とか開発開始前に周知してるのにも関わらずコードレビューで堂々と「kokyaku_jouhou_check」メソッドを披露してくれるケースもある程度防げるのかと。(アンダースコアはCheckstyleで拾えるか。)
さて、Javaで開発業務を行うにおいて事実上標準になっているのがオープンソースのJava総合開発環境Eclipse
ですな。SunやBolandもIDEを出してるようですが、私が仕事するにおいてはほぼ全部Eclipseで開発してました。
(WSADを使ってたときもありましたがまぁ、Eclipseファミリ(捉え方は逆かもしれんが)ということで･･･)
さて、Eclipseを使う上で便利なことのひとつにプラグインが豊富という事があると思います。
その中でも今の私にはずせないもののひとつにCheckstyleプラグインなるものがあります。
(本当はFindbugsの方が重要度が高いんですがたまたま今いじってたのがCheckstyleだった^^;)
CheckstyleはEclipseで動く単なるコーディングチェックツールです。
単なるコーディングチェックツールなんですが、何気にコーディングチェックってのは厳密に行うのは難しく、小規模のプロジェクトでさえ気がつくともう当人以外見られたものではないソースコードが山ほどできてしまうもので、それを回避する術はコードレビューをマメに行うぐらいしかないのかと思っています。(可読性について気にしない人は自己チェックができないので他人の目を介する必要があります。)
実装者がコードを書いているときにリアルタイムにコードチェックができるのはすばらしいですね。
経験上、可読性の低いコードがバグってるときは改修により更にバグを生む傾向があると思われ、できるのであれば初回製造時点でコーディングを型にはめるべきだと思います。
欲を言えば変数やメンバの名前の意味まで考えてくれるといいんですけどねー。
・プロジェクトのコーディングルールで「値チェックメソッドは「validate～」とする。
・変数名(クラス名、メソッド名含む)は英語とする。
・キャメルケースに従うこと
とか開発開始前に周知してるのにも関わらずコードレビューで堂々と「kokyaku_jouhou_check」メソッドを披露してくれるケースもある程度防げるのかと。(アンダースコアはCheckstyleで拾えるか。)
