본문으로 건너뛰기
cccskills
무료GitHub에 공개

fe-code-style

Diagnoses and fixes Java style violations in the FE module using Checkstyle, a tool that checks coding rules. It interprets errors, applies the project's formatting and import restrictions, and reruns checks to verify fixes.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Fix FE (Java) code style issues using Checkstyle

설치 방법 보기

이럴 때 유용합니다

  • Checking FE Java changes before committing
  • Fixing build failures caused by Checkstyle violations
  • Understanding project-specific style and import rules
  • Aligning IntelliJ formatting with the project configuration

포함된 파일(1)

  • SKILL.md3.5 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

What I do

Diagnose and fix Java code style issues in the FE module using the project's Checkstyle configuration.

When to use me

  • Before committing FE Java code changes
  • When FE build fails due to checkstyle violations
  • When you need to understand FE style rules

Procedure

Step 1: Run checkstyle

Checkstyle is integrated into the Maven build and runs automatically during mvn validate. To check style only (without full compilation):

cd fe && mvn checkstyle:check -pl fe-core

Or as part of the normal build:

./build.sh --fe -j${DORIS_PARALLELISM}

If checkstyle fails, the build will fail with error messages showing the file, line number, and rule violated.

Step 2: Interpret violations

Checkstyle output looks like:

[ERROR] src/main/java/.../Foo.java:[42:5] (imports) UnusedImports: Unused import - java.util.List.
[ERROR] src/main/java/.../Bar.java:[10] (header) RegexpHeader: Line does not match expected header line...

Each error shows: [file]:[line:col] (category) RuleName: description.

Step 3: Fix common violations

ViolationFix
RegexpHeaderAdd/fix Apache License header at file top
UnusedImportsRemove unused import statements
LineLength (>120 chars)Break long lines
IllegalImport (shaded classes)Use the non-shaded equivalent (see import-control.xml)
FileTabCharacterReplace tabs with spaces
NewlineAtEndOfFileEnsure file ends with a newline
MergeConflictMarkerResolve git merge conflicts

Step 4: Verify fix

After fixing, re-run checkstyle to confirm:

cd fe && mvn checkstyle:check -pl fe-core

Key Configuration

FilePurpose
fe/check/checkstyle/checkstyle.xmlMain rules (license header, line length 120, encoding, imports)
fe/check/checkstyle/suppressions.xmlRule exclusions (test files, nereids, large files)
fe/check/checkstyle/import-control.xmlImport restrictions (no shaded classes, no old logging APIs, no Lombok in nereids)
fe/check/checkstyle/checkstyle-apache-header.txtApache License 2.0 header template
build-support/IntelliJ-code-format.xmlIntelliJ formatter scheme (120 col, import organization)

Suppression Rules

Some files/packages have relaxed rules (see suppressions.xml):

  • Test files: Javadoc rules suppressed
  • Non-nereids code: Some strict rules suppressed
  • Specific large files: Individual suppressions

Excluded Code

The following are excluded from checkstyle (see fe/pom.xml):

  • **/apache/doris/thrift/**/* (generated Thrift code)
  • **/apache/parquet/**/* (generated Parquet code)

Import Restrictions (key rules from import-control.xml)

  • No shaded imports: Do not use org.apache.doris.thirdparty.* directly
  • No old logging: Do not use org.apache.commons.logging or java.util.logging
  • No SimpleDateFormat: Use java.time APIs instead
  • No Lombok in nereids: lombok is disallowed in org.apache.doris.nereids package

Troubleshooting

ProblemSolution
Build fails on validate phaseRun mvn checkstyle:check -pl fe-core to see specific violations
Can't find checkstyle configEnsure you're running from the fe/ directory
IntelliJ formatting differsImport build-support/IntelliJ-code-format.xml via Settings → Editor → Code Style

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Format C++ code in the BE and Cloud modules using the project's clang-format v16 rules. Use the provided scripts to fix formatting or check for violations without changing files, then review the resulting differences before committing.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Format BE or Cloud C++ code before committing
  • Fix formatting failures reported by CI
  • Check formatting without modifying files
apache/doris1.6만2026년 10월 18일 업데이트

Run clang-tidy static analysis, which checks code without executing it, on added or modified BE and Cloud C++ files. Focus diagnostics on changed lines, investigate bug, performance, and readability warnings, and verify fixes with another check.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Check changed C++ code before committing
  • Investigate clang-tidy warnings reported by CI
  • Review changes against a specific branch
apache/doris1.6만2026년 10월 18일 업데이트

Review Doris code changes using project-specific checklists for data correctness, concurrency, memory safety, compatibility, performance, and tests. Trace related code paths and explain findings with concrete failure scenarios, using query plan trees when reviewing optimizer behavior.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Review newly completed Doris code changes
  • Check concurrency and memory management in related code paths
  • Assess compatibility and test coverage before merging
apache/doris1.6만2026년 10월 18일 업데이트

Prepare a clean Doris package and run Docker regression tests, which check whether changes break existing behavior. Restore configuration and startup files from Git, build the test image, and investigate failures using configuration checks and runtime logs.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Run Docker regression tests before submitting Doris changes
  • Test without local configuration changes affecting results
  • Investigate missing test suites or startup failures
apache/doris1.6만2026년 10월 18일 업데이트

apache의 스킬 모두 보기

이 스킬의 문제 신고