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
}
```

견고한 fail-fast 동작을 위해 스크립트 상단에도 다음을 추가하세요:

```bash
set -euo pipefail
```

`pipefail`은 함수가 Maven 출력을 `grep`, `sed` 또는 유사한 명령어로 파이프할 때 중요합니다. 그렇지 않으면 Maven이 실패하더라도 파이프라인이 성공할 수 있습니다. 버전 조회는 헬퍼에 유지하고, Checkstyle의 `.ci/util.sh`, `validation.sh`, `no-exception-test.sh` 및 릴리스 스크립트에서처럼 모든 호출 지점에 가드를 적용하세요.

Question 2

allowMissingPropertyJavadoc이 활성화된 경우 Checkstyle MissingJavadocMethod가 블록 주석을 포함하는 getter나 setter를 왜 오탐합니까?

Accepted Answer

이것은 14.2.0과 같은 버전에서 발생하는 Checkstyle 버그입니다: 접근자 감지가 `//` 단일 행 주석은 건너뛰지만 `/* ... */` 블록 주석은 건너뛰지 않으므로, 블록 주석이 유효한 getter/setter가 인식되지 못하게 할 수 있습니다. issue #21755에 대한 수정이 포함된 Checkstyle 릴리스로 업그레이드하세요. 해결 방법으로, 접근자 내부의 블록 주석을 단일 행 주석으로 교체하거나, 제거하거나, 영향을 받는 메서드에 대해 `MissingJavadocMethod`를 억제하세요. 예를 들어, 메서드 본문에서 `/* block comment */` 대신 `// comment`를 사용하세요.

Question 3

ignoreComments가 true이고 정규식에 zero-width 매치가 있을 때 Checkstyle RegexpSinglelineJava가 멈추는 이유는 무엇인가요?

Accepted Answer

Checkstyle 14.1.0은 억제된 매치의 너비가 0인 경우(예: 주석 안의 `(?=TODO)`) `SinglelineDetector.checkLine`에서 무한 루프에 빠질 수 있습니다. 이 코드는 `matcher.find(startPosition)`를 호출하고 `startPosition = matcher.end()`로 설정하지만, 너비가 0인 매치에서는 `start`와 `end`가 동일하므로 동일한 매치가 반복적으로 발견됩니다.

병합된 수정 사항은 `matcher.find(startPosition)`를 `matcher.find()`로 대체하여 매처가 빈 매치를 지나 계속 진행할 수 있도록 합니다. issue #21519에 대한 수정이 포함된 Checkstyle 릴리스로 업그레이드하세요.

해결 방법으로, 너비가 0인 패턴을 문자를 소비하는 패턴으로 교체하세요. 이 예제에서는 다음을 사용하세요:

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

`ignoreComments=true`를 사용하면 주석 내의 매치는 여전히 억제되고 코드 내의 `TODO`는 보고됩니다. 수정된 버전을 실행할 때까지 전방 탐색(lookahead)이나 빈 매치를 생성할 수 있는 다른 패턴은 피하세요.

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를 재귀적으로 순회하므로, 극도로 깊은 표현식 하나(단일 문장 내 수천 개의 `+` 피연산자, 예: 생성된 코드)는 위반 사항이 보고되기 전에 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