問題タブ [checkstyle]

私は、最大 10 人の開発者が取り組む新しい Java Web プロジェクトを開始しています。

コードベースが大きくなると、おそらく変更するのが難しくなるでしょう。では、methodLength と fileLength に使用するのに最適な checkstyle 設定は何ですか?

次の環境があります。Apache 2.2.14 を使用する Windows 2008 サーバーと、WebDAV を介した SVN 1.6.6 です。複数の開発者が、異なる Windows プラットフォームから Java コードをコミットします。

ここで、コミットされたコードで Checkstyle を実行するリポジトリに pre-commit フックを実装したいと考えています。これには SVNChecker ( http://svnchecker.tigris.org/ ) を使用しますが、これは非常にうまく機能します。残念ながら、Checkstyle がエラーを報告する場合、レポートの行番号は実際の行番号の 2 倍の値になります。

SVN で何かをコミットすると、新しいファイルを含む一時ディレクトリが作成されます。次に、pre-commit フックが実行され、成功すると、新しいファイルが実際にリポジトリにコミットされます。これらの一時ファイルを Hex Editor で分析したところ、すべての改行 (\n) がキャリッジ リターンと改行 (\r\n) に置き換えられていることがわかりました。ファイルで Windows の改行 (\r\n) を使用すると、\r\r\n になり、Checkstyle といくつかのテキスト エディターでは 2 つの改行と見なされます。驚くべきことは、リポジトリからチェックアウトするときに改行が正しいため、何らかの形で改行が変換されることです。

プロパティ svn:eol-style ( http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5を参照) をネイティブに設定することで、この問題を解決できました。. すべてが正常に機能しました。残念ながら、これはリポジトリ内のすべてのファイルにこのプロパティを追加する必要があることを意味します。私の知る限り、SVN クライアントには、新しいファイルを追加するたびに自動的にこれを行う設定がありますが、残念ながら、すべての開発者にこの設定を SVN クライアントに追加するように指示することはできません。

eol-style プロパティの説明には、「デフォルトでは、Subversion はファイルで使用されている行末 (EOL) マーカーのタイプに注意を払わない」と書かれています。それにもかかわらず、改行が変換されるのは SVN のバグのように見えます。

pre-commit フックで改行を手動で変換するなどの醜い回避策を使用せずに、この動作を修正する方法を知っている人はいますか?

助けてくれてありがとう、メミンガー

XHTML形式を使用して、多くのJSFページがあるプロジェクトに取り組んでいます。Sonar (および Checkstyle、PMD、FindBugs など)を使用してコードの品質を監視します。これは、アプリケーションの Java 部分に最適です。

ここで、アプリケーションの XHTML 部分をチェックするツール (理想的には、独自のプラグインを作成して Sonar にリンクできるもの) が必要です。

では、私のページのいくつかのルールをチェックできる checkstyle のようなツールはありますか? たとえば、このツールは、次のようなコードに遭遇すると警告を発します。

また ：

Checkstyle が正規表現に基づくルールを提供していることは承知していますが、ルールによってはソリューションが複雑すぎるのではないかと心配しています...

私はクラスのグループプロジェクトに取り組んでおり、CheckStyleを試しています。

私はJavaにかなり慣れていますが、これまでJDBCに触れたり、データベースの作業を行ったことはありません。

プリペアドステートメントの呼び出しでマジックナンバーエラーを回避するためのエレガントな方法があるかどうか疑問に思っていました。次のことを考慮してください。

setStringメソッドはマジックナンバーとしてフラグが立てられます。これまでのところ、マジックナンバーの無視リストに3〜10程度の数字を追加しましたが、これらの値をステートメントに挿入するより良い方法があるかどうか疑問に思いました。また、そのコードを見て頭に浮かぶ他のアドバイスをお願いします。たとえば、Statementを使用する必要があるのか​​、PreparedStatementで問題ないのかなど、厄介な習慣を身に付けないようにします。代わりに列名を参照できますか？それは理想的ですか？等...

ありがとう！

重複の可能性：
特定のコード行に対して特定のチェックスタイルルールを無効にする方法は？

コードのセグメントに対してCheckstyleをオフにする場合、特定のチェックのみを抑制する構文はありますか。

だから

// CHECKSTYLE：OFF
コード
// CHECKSTYLE：ON

あなたは次のようなものを持つことができます

// CHECKSTYLE：OFF：RequireThis、
コード
// CHECKSTYLE：ON

意図的にスタイルに例外を作成する場合は、例外の場合が何であるかを明確にするとよいでしょう。

1 行の構文を使用する単純な Java プロパティ アクセサーが必要なため、使用するスペースがはるかに少なくなり、読みやすくなります (アクセサーのセットをすばやく「見る」という点で)。しかし、checkstyle 構成の他のすべてに複数行のメソッド構文を適用したいと考えています。しかし、Checkstyle 構成でアクセサーに対してこの例外を作成する方法がわかりません。それが可能ではない可能性があると思われます。

したがって、アクセサは次のようになります。

[実際には、些細なアクセサーをまったく持たず、代わりにプライベート メンバー変数に@Propertyまたは何かで注釈を付け、アクセサーを生成してもらいたいと考えています。これは、無限の get および set コードを記述しても実際の利点は得られないためですが、それは一般的な Java の不満です。この質問に関する限り、余談です。]

私はmavenとchekstyleが初めてなので、質問する必要があります... mavenベースのプロジェクトでcheckstyleを使用したいのでpom.xml、依存関係を追加しました

また、プラグインタグにエントリを追加しました:

しかし、コマンドで maven ビルドを実行するとmvn clean install、checkstyle は何もしません。そしてcheckstyle.xml、システムにまだ何も持っていないので、エラーについて不平を言うべきではありませんか?

他にどのような構成がありませんか?

私は最近、eclipse 用の checkstyle アドオンをインストールしました。コードの一部をより明確にするのに役立ちますが、愚かなルールがいくつかあります。using ++ is not allowed ルール以外のほとんどを無効にすることができました。それを無効にする方法を知っている人はいますか？

I just been given a new assignment which looks like its going to be an interesting challenge.

The customer is wanting a code style checking tool to be developed for their internal (soon to be open sourced) programming language which runs on the JVM. The language syntax is very Java like.

The customer basically wants me to produce something like checkstyle.

So my question is this, how would you approach this problem? Given a clean slate what recommendations would you make to the customer?

I think I have 3 options

1. Write something from scratch. Id prefer not to do this as it seems like this sort of code analysis tool problem has been solved so many times that there must be a more "framework" or "platform" orientated approach.

2. Fork an existing code style checking tool and modify the parsing to fit with this new language etc etc

3. Extend or plug into an existing static code analysis tool. (maybe write a plugin for Yasca?)

フィールドとクラスが Java 並行性で適切に注釈付けされていることを確認するルールが必要です: http://mvnrepository.com/artifact/net.jcip/jcip-annotationsによって提供される実際の注釈

フィールドには @GuardedBy で注釈を付ける必要があり、クラスには @Immutable、@ThreadSafe、または @NotThreadSafe のいずれかで注釈を付ける必要があります。

現在、Spring Dao クラスに @Service または @Component の代わりに @Repository でアノテーションを付けるルールが適用されています。

このアプローチの問題は、いくつかの注釈をチェックして、代わりに他の注釈を使用する方がよいことを伝えることしかできないことです。「特定の注釈が存在しない」ことを確認できないため、これは jcip 注釈チェックには役立ちません。

手始めに、上記の Dao チェックを、名前が Dao で終わるクラスに @Repository が存在することを保証するチェックに変換する方法を誰かが知っていれば素晴らしいでしょう。そのパターンを使用して、jcip 注釈チェックを開発できます。

あるいは、正規表現チェックを変換しようとする代わりに、checkstyle のトークン サポートを使用して jcip ルールを実装する方法があるのではないでしょうか? これにより、ルールが堅牢になる可能性があります。

とにかく、checkstyle を介して特定の要素に特定の注釈が存在する必要があることを確認する方法を知りたいです。うまくいけば、誰かがこれを知っています。:)