忍者ブログ
Admin§Write

ぷろぐらみんぐ徒然

文系4大卒がなぜか職業ぷろぐらまになって早10年。 とっくに三十路は過ぎた。 いつまでも派遣プログラマだと死亡フラグが立つのでそれよりきり前に脱出成功。今後の事はまだ良くわからん。 ここのところ愛してやまないバンドはFuzzy Control。 興味を持ってもらえたらうれしいです。 この欄だとタグが使えないみたいなのでURLも。 http://www.fuzzycontrol.jp/

HOME ≫ Entry no.3 「Checkstyleプラグイン」 ≫ [8] [7] [6] [5] [4] [3] [2] [1]

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。


Checkstyleプラグイン

プラグ印。IMEの変換、英単語ぐらいはしっかり変換してほしいぞ。

さて、Javaで開発業務を行うにおいて事実上標準になっているのがオープンソースのJava総合開発環境Eclipse
ですな。SunやBolandもIDEを出してるようですが、私が仕事するにおいてはほぼ全部Eclipseで開発してました。
(WSADを使ってたときもありましたがまぁ、Eclipseファミリ(捉え方は逆かもしれんが)ということで・・・)

さて、Eclipseを使う上で便利なことのひとつにプラグインが豊富という事があると思います。
その中でも今の私にはずせないもののひとつにCheckstyleプラグインなるものがあります。
(本当はFindbugsの方が重要度が高いんですがたまたま今いじってたのがCheckstyleだった^^;)

CheckstyleはEclipseで動く単なるコーディングチェックツールです。
単なるコーディングチェックツールなんですが、何気にコーディングチェックってのは厳密に行うのは難しく、小規模のプロジェクトでさえ気がつくともう当人以外見られたものではないソースコードが山ほどできてしまうもので、それを回避する術はコードレビューをマメに行うぐらいしかないのかと思っています。(可読性について気にしない人は自己チェックができないので他人の目を介する必要があります。)

実装者がコードを書いているときにリアルタイムにコードチェックができるのはすばらしいですね。
経験上、可読性の低いコードがバグってるときは改修により更にバグを生む傾向があると思われ、できるのであれば初回製造時点でコーディングを型にはめるべきだと思います。
欲を言えば変数やメンバの名前の意味まで考えてくれるといいんですけどねー。
・プロジェクトのコーディングルールで「値チェックメソッドは「validate~」とする。
・変数名(クラス名、メソッド名含む)は英語とする。
・キャメルケースに従うこと
とか開発開始前に周知してるのにも関わらずコードレビューで堂々と「kokyaku_jouhou_check」メソッドを披露してくれるケースもある程度防げるのかと。(アンダースコアはCheckstyleで拾えるか。)
PR

●Thanks Comments

●この記事にコメントする

お名前
タイトル
文字色
E-mail
URL
コメント
絵文字 Vodafone絵文字 i-mode絵文字 Ezweb絵文字
パスワード ※投稿者編集用
秘密? ※チェックすると管理人にしか見えません

●この記事へのトラックバック

TrackbackURL:

≪ Checkstyleプラグイン設定 - 設定はこうすれば楽なんじゃねーの?その1 - setterメソッドにフィールドを隠してるの警告はいらないと思う。 |PageTop| Windows再インストール ≫

※ 忍者ブログ ※ [PR]
 ※
Writer 【へっぽこPG】  Design by NUI.T  Powered by NinjaBlog