Google's Java Style の CheckStyle を使う - なにか作る
Google's Java Style Checkstyle の導入 Java の静的解析ツールの一つである Checkstyle は便利なものなんだけど、デフォルトの設定だと警告があがりすぎて正直ウザい。 なので、ちょこちょこと設定の微調整を行う必要があるんだけど、これがまた面倒くさい。 なにか便利なやり方はないかと探していたら、Checkstyle の公式サイトで Google Java Style 用の設定が配布されていることに気付いた。 checkstyle – Google's Style XML ファイルがダウンロードできるので、これを使うのが便利そうだ。 Google's Java Style Checkstyle の微調整 とはいえ、これもそのまま使うには気になるところがいくつか。何点かの微調整を行う。 パッケージ名にアンダースコアを使いたいときがあるので、パッケージ名のチ
mvn test で findbugs と checkstyle を走らせて，1つでも violation があれば fail させるの術 - その手の平は尻もつかめるさ
OSS で Java をやっていく場合，ロジックのテストだけではなく checkstyle や findbugs などによる静的解析を適用して，それを CI で回していかないととてもではないがやっていけない！！！ という感じになるので，そこら辺を何とかしたい． 具体的に言うと mvn test でこれらの静的解析をテストと一緒に走らせて，静的解析が1つでも violation を吐き出したら BUILD FAILURE にしたい (もちろんテストがコケても BUILD FAILURE になる)． ということで以下のように pom.xml を記述してやります． <build> <plugins> ... <!-- findbugs の設定 --> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>findbugs-maven-
Jenkins で静的解析のグラフを作るとコードを読まなくてもソフトウェアの品質が分かって面白い - おともだちティータイム
細かく書きたいけど、とりあえずメモだけ。 ステップ数が増ている なんらかの開発が行なわれている ステップ数が減っている リファクタリングが行なわれている? 単に仕様落ちしたコードが削除された可能性もある テストカバレッジが下がる テストが書かれていない ... ステップ数が増えている場合 テストが減っている ... ステップ数が変わらない場合 FindBugs 、 PMD 、 Android Lint の警告数が増えている 品質の低下、レビューが正しく行なわれていない CPD 警告数が増えている 品質の低下、レビューが正しく行なわれていない そろそろリファクタリングしたほうがいい Checkstyle 警告数が増えている 品質の低下、レビューが正しく行なわれていない Jenkins で継続的にビルドしたり、テストを行なうのは言うまでもなく大切だけど、こういった静的解析の数値をグラフ化してい
jenkins エレガントなコードを書くための執事のすすめ
The document discusses various plugins that can be used with Jenkins/Hudson for continuous integration. It mentions plugins for plotting test results over time, detecting duplicated code, performing static analysis with PMD and Checkstyle, and more. Links are provided to the plugins on the Jenkins wiki along with descriptions of how they work and what problems they aim to solve.Read less
PMDの独自ルールで、潜在的なバグを機械的に探す : toda_k
パッケージ製品の開発は大規模かつ長期間になり、コードの寿命も必然的に長くなります。また関わる開発者が多いことから、コードの可読性を高く保つことも難しくなります。この難問を解決する方法には個人の技術力向上やプロセス改善といったものも考えられますが、ここでは“悪いコード”を弾きだす機械的な方法を開発サイクルに組み込むことに着目してみましょう。 このためのツールとしてJava開発者の間で最も有名なのは、おそらくfindbugsです。findbugsはclassファイルを解析し、潜在的なバグを探してくれます。Eclipseプラグインの日本語解説記事もあるので、多くの人が一度は試したのではないでしょうか。 他にはcheckstyleやPMDなど、ソースコードを解析してくれるツールもあります。checkstyleはコーディング規約に従っていないコードを検出してくれるので、複数人数での開発では重宝するで
Checkstyleのカスタムルール作成と共有 - souta-bot log
導入しても反発が少なそうなCheckstyleのゆるいカスタムルールを考えてみた。 それとEclipseでのカスタムルール共有方法をメモ。 カスタムルール作成 雛形は既存(プラグイン付属？)の「Sun Checks (Eclipse)」のコピーを使用する(「Sun Checks」よりゆるいルールなのでこちらを選択)。 Javadoc Comments - Method Javadoc - scope をpackageに privateメソッドはJavaDoc無くてもおｋ Javadoc Comments - Method Javadoc - allowUndeclaredRTE をチェック 「RuntimeExceptionのサブクラスに対する@throws節の記述を許可するかどうか」 これがデフォルトで許可されていない理由は何だろ？ Javadoc Comments - Package
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Netty.news: New build server, powered by Clinker