Question 1

Bashスクリプトで関数やMavenコマンドが失敗しても処理が続行されるのはなぜですか？また、失敗した時点で即座に終了させる（fail fast）にはどうすればよいですか？

Accepted Answer

`CS_version=$(getCheckstylePomVersion)` のようなコマンド置換は、それ自体ではスクリプトを停止させません。Maven が失敗した場合、スクリプトは無効な出力や空の出力のまま処理を続行し、後で `Unrecognized option` のような分かりにくいエラーを発生させる可能性があります。呼び出しの後に明示的なステータスチェックを追加してください：

```bash
CS_version="$(getPomVersion)" || {
  echo "Failed to determine Checkstyle POM version" >&2
  exit 1
}
```

堅牢なフェイルファスト動作を実現するために、スクリプトの先頭に以下も追加してください：

```bash
set -euo pipefail
```

`pipefail` は、関数が Maven の出力を `grep` や `sed` などのコマンドにパイプする場合に重要です。これがないと、Maven が失敗してもパイプライン全体が成功として扱われる可能性があります。バージョンの取得はヘルパーにまとめ、Checkstyle の `.ci/util.sh`、`validation.sh`、`no-exception-test.sh`、およびリリーススクリプトで行われているように、すべての呼び出し箇所にガードを適用してください。

Question 2

allowMissingPropertyJavadoc が有効な場合、Checkstyle の MissingJavadocMethod がブロックコメントを含むゲッターやセッターを誤って報告するのはなぜですか？

Accepted Answer

これは、14.2.0 などのバージョンにおける Checkstyle のバグです: アクセサの検出は `//` の単一行コメントをスキップしますが、`/* ... */` のブロックコメントはスキップしないため、ブロックコメントがあると有効な getter/setter が認識されなくなる可能性があります。issue #21755 の修正を含む Checkstyle リリースにアップグレードしてください。回避策としては、アクセサ内のブロックコメントを単一行コメントに置き換えるか、削除するか、影響を受けるメソッドに対して `MissingJavadocMethod` を抑制してください。たとえば、メソッド本体では `/* block comment */` の代わりに `// comment` を使用してください。

Question 3

Checkstyle の RegexpSinglelineJava が、ignoreComments が true で正規表現にゼロ幅マッチが含まれる場合にハングするのはなぜですか？

Accepted Answer

Checkstyle 14.1.0 では、コメント内の `(?=TODO)` のように抑制されたマッチがゼロ幅の場合、`SinglelineDetector.checkLine` が無限ループに陥る可能性があります。このコードは `matcher.find(startPosition)` を呼び出して `startPosition = matcher.end()` を設定しますが、ゼロ幅のマッチでは `start` と `end` が等しいため、同じマッチが繰り返し検出されてしまいます。

マージされた修正では、`matcher.find(startPosition)` が `matcher.find()` に置き換えられ、マッチャーが空のマッチを越えて先に進めるようになりました。issue #21519 の修正を含む Checkstyle リリースにアップグレードしてください。

回避策として、ゼロ幅のパターンを文字を消費するパターンに置き換えてください。この例では、次のように指定します。

```xml
<property name="format" value="TODO"/>
```

`ignoreComments=true` を使用すると、コメント内のマッチは引き続き抑制され、コード内の `TODO` は報告されます。修正版を実行するまでは、先読みやその他の空のマッチを生成し得るパターンは避けてください。

Question 4

同名の継承フィールドを持つ匿名クラス内で発生する Checkstyle RequireThis の誤検出「Reference to instance variable needs 'Enclosing.this'」の修正方法

Accepted Answer

これは既知のCheckstyle `RequireThisCheck` のバグ（#5353）であり、少なくともCheckstyle 8.8に影響します。匿名クラスが、外側のクラスのフィールドと同じ名前のフィールドを宣言する型を継承している場合、修飾されていない参照は匿名オブジェクトが継承したフィールドに解決されますが、Checkstyleはそれを誤って外側のフィールドとして報告します。

修正方法: #5353の修正を含むCheckstyleリリース（できれば最新バージョン）にアップグレードし、再実行してください：
```bash
java -jar checkstyle-latest-all.jar -c TestConfig.xml TestClass.java
```

すぐにアップグレードできない場合は、継承された参照を明示的に修飾してください：
```java
f = 1;
```
を次のように変更します：
```java
this.f = 1;
```
`this.f` は引き続き `AbstractClass` から継承されたフィールドを参照します。意図的に外側のインスタンスのフィールドを参照したい場合を除き、`TestClass.this.f` は使用しないでください。フィールドの一方の名前を変更することも、もう一つの回避策です。

Question 5

深くネストされた文字列連結に対する Checkstyle の DescendantToken チェックで発生する StackOverflowError を修正する方法

Accepted Answer

`DescendantTokenCheck.countTokens` は AST を再帰的に走査するため、極端に深い式(単一のステートメント内に数千個の `+` オペランドを含むもの、例えば生成コードなど)が1つあるだけで、違反が報告される前に JVM スタックがオーバーフローします。PR #21902 で修正されており、再帰的な走査が反復的なトラバーサルに置き換えられています(パーサーの非再帰的な処理と同じ方式です。`JavaAstVisitorTest#testNoStackOverflowOnDeepStringConcat` を参照)。その修正を含む Checkstyle リリースにアップグレードしてください。それまでの回避策: (1) スレッドスタックを拡大する: `java -Xss8m -jar checkstyle-14.3.0-all.jar -c config.xml Test.java`(実行が完了するまで `-Xss` を増やしてください); (2) 式を複数の短いステートメントや中間変数に分割して AST の深さを減らす; (3) `BeforeExecutionExclusionFileFilter` で問題のあるファイルや生成されたファイルを除外する。なお、`SuppressionFilter`/`SuppressionXpathFilter` は効果がありません。クラッシュは走査中、つまり違反イベントが作成される前に発生するためです。

checkstyle

概要

README プレビュー

FAQ (5)

同类型项目

hermes-agent

firecrawl

go

markitdown