- PR -

プロジェクト途中からのCheckstyle導入

1
投稿者投稿内容
siop
ベテラン
会議室デビュー日: 2003/08/12
投稿数: 67
投稿日時: 2004-09-14 14:03
開始して２年くらい経つプロジェクトがあるのですが、ソースの統一化を図るため、Checkstyleを導入しようと考えました。
とりあえず、デフォルト設定(Sun規約)でチェックしてみたのですが、とても表示しきれる数ではありませんでした。

プロジェクトなりの設定を行なっていくつもりですが、どんな設定にしても何千、何万のエラーや警告が出るため、どんなチェックをすべきか決めかねています。

このような事象を経験した方、ご教授ください。
おばけ
ぬし
会議室デビュー日: 2002/11/14
投稿数: 609
お住まい・勤務地: 東京都江東区
投稿日時: 2004-09-14 15:22
引用:

とりあえず、デフォルト設定(Sun規約)でチェックしてみたのですが、とても表示しきれる数ではありませんでした。

あれでやったらとてもたまらないですよね。

ところで、Checkstyleはあくまでコーディング規約への準拠度をチェックするための
ツールですので、まずは規約ありきです。プロジェクト内で規約を作り、それを
Checkstyleの設定にマッピングし、実際にCheckstyleに掛ける、という手順が正だと
思います。

Checkstyleの設定は結構面倒くさいですが、EclipseのCheckstyleプラグインを使うと
設定ファイルをGUIで書けますから、結構良いですよ。
tak3
ベテラン
会議室デビュー日: 2004/04/15
投稿数: 80
お住まい・勤務地: 菜の花・銀杏
投稿日時: 2004-09-14 16:49
>プロジェクトなりの設定を行なっていくつもりですが、どんな設定にしても何千、何万のエラ
>ーや警告が出るため、どんなチェックをすべきか決めかねています。

「エラーがなるべく出ない規約を設定しようとしている」のでしょうか？
手順でいうなら、おばけさんの手順が正当だと思います。

ですが、エラーを直す工数を考えると・・・というのはありますんで。
ソースの整形ツールを一度はさんでみては、どうでしょうか？

http://astyle.sourceforge.net/
とか
http://jalopy.sourceforge.net/

適用したあとならエラーはかなり減ると思います。（整形前のバックアップは忘れずに！）
自分の知ってるjavaソース整形ってこんなもんですが、他におすすめありますか？
siop
ベテラン
会議室デビュー日: 2003/08/12
投稿数: 67
投稿日時: 2004-09-15 13:24
引用:

まずは規約ありきです。

コーディング規約はあるのですが、厳密には守られていない状況ですね。
「importの*はダメとか」

Checkstyleでチェックするのには、チェックすべき理由がありますよね。
単に可読性を高めるだけじゃなく、Javaの仕様的にやらない方がいいものもあるので、コーディング規約に追加していきたいと思ってます。

引用:

EclipseのCheckstyleプラグインを使うと設定ファイルをGUIで書けますから、結構良いですよ。

Eclipseのプラグイン使ってますよ。
xmlを直接編集すると大変ですからね〜。

でもEclipseのプラグインでは設定できないものもありそうですね。
Headerとかは設定タグに出てこないですね。
siop
ベテラン
会議室デビュー日: 2003/08/12
投稿数: 67
投稿日時: 2004-09-15 13:32
引用:

ソースの整形ツールを一度はさんでみては、どうでしょうか？

http://astyle.sourceforge.net/
とか
http://jalopy.sourceforge.net/

まずは、整形ツールを使わないとダメですね。
でもテスト工数はかかるので、悩みどころですね。

JUnitなども使ってないので・・・。(^^;
1

スキルアップ／キャリアアップ（JOB@IT）