체크 스타일 대 PMD

https://stackoverflow.com/questions/184563

06-07-2019
|

문제

우리는 Java 제품의 빌드 시스템에 정적 분석 도구를 도입하고 있습니다. 우리는 maven2를 사용하고 있습니다 체크 스타일 그리고 PMD 통합은 무료로 제공됩니다. 그러나 기본 스타일 규칙을 시행하는 측면 에서이 두 도구간에 기능이 크게 겹치는 것처럼 보입니다.

이 두 가지를 활용하면 이점이 있습니까? 작동하면 2 개의 도구를 유지하고 싶지 않습니다. 우리가 하나를 선택하면 어떤 것을 사용해야하고 그 이유는 무엇입니까?

우리는 또한 FindBugs를 사용할 계획입니다. 우리가 살펴 봐야 할 다른 정적 분석 도구가 있습니까?

업데이트: 합의는 PMD가 체크 스타일보다 선호된다는 것 같습니다. 나는 둘 다 사용해야 할 확실한 이유가 없으며 2 개의 규칙 파일 세트를 유지하고 싶지 않으므로 PMD를 독점적으로 목표로 할 것입니다. 우리는 또한 FindBugs, 그리고 아마도 Macker를 데려와 건축 규칙을 시행 할 것입니다.

해결책

당신은 확실히 사용해야합니다 FindBugs. 내 경험에 따르면, 허위 양성 비율은 매우 낮으며,보고 한 가장 중요한 경고조차도 어느 정도 해결할 가치가 있습니다.

CheckStyle vs. PMD는 스타일에만 관심이 있기 때문에 CheckStyle을 사용하지 않을 것입니다. 내 경험상, CheckStyle은 완전히 관련이없는 많은 것들에 대해보고 할 것입니다. 반면에 PMD는 의심스러운 코딩 관행을 지적 할 수 있으며 출력은 일반적으로 더 관련성이 높고 유용합니다.

다른 팁

두 소프트웨어 모두 유용합니다. CheckStyle은 프로그래밍 중에 귀하의 코딩 스타일 즉, 교정기, 이름 지정 등 간단한 것들이 있지만 매우 많습니다!

PMD는 수업 설계과 같은 더 복잡한 규칙을 확인하거나 클론 기능을 올바르게 구현하는 것과 같은보다 특별한 문제를 확인하여 도움이됩니다. 간단히 말해, PMD는 귀하의 점검을 확인합니다 프로그래밍 스타일

그러나 두 소프트웨어는 때때로 비슷한 규칙으로 고통 받고 있습니다. 구성이 좋지 않은 경우, "쓸모없는 생성자 제거"와 "항상 하나의 생성자"를 두 번 또는 두 번 반대 할 수 있습니다.

우리가 하나를 선택하면 어떤 것을 사용해야하고 그 이유는 무엇입니까?

이러한 도구는 경쟁하지 않지만 보완 적이며 동시에 사용해야합니다.

컨벤션 유형 (Checkstyle)은 사람들이 일관되지 않은 코드를 이해하는 데 시간과 에너지를 소비하는 대신 사람들이 함께 일하고 창의성을 확보 할 수있는 접착제입니다.

CheckStyle 예제 :

공개 방법에 대한 Javadoc이 있습니까?
Sun Naming Conventions에 이어 프로젝트가 있습니까?
코드는 일관된 형식으로 작성됩니까?

PMD는 나쁜 관행을 상기시켜줍니다.

아무것도하지 않고 예외를 포착합니다
죽은 코드가 있습니다
너무 많은 복잡한 방법
인터페이스 대신 구현을 직접 사용합니다
NOT EQUALS (Object) 메소드없이 hashcode () 메소드 구현

원천:http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-cemprementary/

우리는 둘 다 사용합니다.

팀의 모든 사람이 비슷한 MANER에 코드를 작성하는지 확인하는 CheckStyle
PMD 문제가있는 코드 영역 및 다음 리팩토링 대상을 찾습니다.

일식에서 개발 중에 1 차 사용 장소가 있다면, 인스턴스베이션에서 코드로가 가장 좋을 것입니다. 이전에는 상업적인 도구 였지만 이제 Google은 인스턴스열을 구입하여 Codepro Analytix가 무료입니다.

체크 아웃 http://code.google.com/javadevtools/download-codepro.html

CheckStyle, PMD 및 FindBugs 규칙 목록을 검토 한 경우, 세 가지 모두가 귀중한 출력과 세 가지 모두를 어느 정도 중첩하고 자신의 고유 한 규칙을 테이블에 가져 오는 것을 보았습니다. 이것이 Sonar와 같은 도구가 세 가지를 모두 사용하는 이유입니다.

즉, FindBugs는 가장 구체적이거나 틈새 규칙을 가지고 있습니다 (예 : "불법 모니터 스테이트 exception의 모호한 잡기" - 얼마나 자주 발생할 가능성이 있습니까?) 구성이 거의 또는 전혀없는 상태에서 사용할 수 있으며 경고는 심각하게 받아 들여야합니다. CheckStyle 및 PMD를 사용하면 규칙이보다 일반적이고 스타일과 관련이 있으므로 관련없는 피드백 ( "탭 char", "Tab char on 6"에서 팀을 예약하기 위해 사용자 정의 구성 파일 만 사용해야합니다. "7 행의 탭 char"... 사진을 얻습니다). 또한 고급 규칙을 작성하는 강력한 도구 (예 : CheckStyle DescendentToken 규칙.

세 가지를 모두 사용하는 경우 (특히 Sonar와 같은 도구)를 모두 사용하는 경우, 모두를 별도로 구성해야합니다 (모든 규칙을 다루는 데 최소한 며칠이 걸리기). 예를 들어 재정의 및 동등한 ().

요약하면, 정적 코드 분석의 가치를 고려하면 값을 거부하는 것은 세 가지 제공 중 하나라도 의미가 없지만 세 가지를 모두 사용하려면 사용 가능한 피드백을 제공하기 위해이를 구성하기 위해 시간을 투자해야합니다.

Sonar (http://www.sonarsource.org/)는 코드 품질을 관리하는 데 매우 유용한 오픈 플랫폼이며 CheckStyle, PMD, FindBugs 등을 포함합니다.

이것은 또한 3 개의 도구가 모두 존재할 권리가 있음을 나타냅니다 ...

CheckStyle 및 PMD는 모두 코딩 표준을 확인하는 데 능숙하며 확장하기 쉽습니다. 그러나 PMD에는 고리적 복잡성, NPATH 복잡성 등을 확인하는 추가 규칙이있어 건강한 코드를 작성할 수 있습니다.

PMD를 사용하는 또 다른 장점은 CPD (Copy/Paste Detector)입니다. 프로젝트 전체에서 코드 복제를 찾아 Java.it도 JSP에도 제한되지 않습니다. 닐 포드는 좋은 프레젠테이션을 가지고 있습니다 측정 항목 주도의 민첩한 개발, Java/Java EE 개발에 도움이되는 많은 도구에 대해 이야기합니다.

CheckStyle과 PMD가 스타일 문제와 간단한 명백한 코딩 버그를 시행하는 데 가장 적합하다고 생각합니다. 나는 Eclipse와 모든 경고를 사용하는 것을 좋아한다는 것을 알았지 만, 그 목적을 위해 더 나은 경고를 제공합니다. 공유 환경 설정을 사용하여 실제 오류로 표시하여 물건을 시행합니다. 그렇게하면 처음에는 체크인하지 않습니다.

내가 강력하고 열정적으로 추천하는 것은 FindBugs를 사용하는 것입니다. 바이트 코드 레벨에서 작동하기 때문에 소스 수준에서 불가능한 것을 확인할 수 있습니다. 그것은 쓰레기의 공정한 몫을 뱉지 만, 우리 코드에서 실제적이고 중요한 버그를 많이 발견했습니다.

두 도구 모두 구성 가능하며 거의 같은 작업을 수행 할 수 있습니다. 즉, 우리가 상자 외부에 대해 이야기하고 있다면 많은 중복이 있지만 뚜렷한 규칙/수표도 있습니다. 예를 들어, CheckStyle은 Javadoc을 점검하고 마법 번호를 찾는 데 더 강한 지원을 제공합니다. 또한 CheckStyle에는 Macker의 기능과 유사한 "Import Control"기능이 있습니다 (Macker를 사용하지 않았습니다).

CheckStyle이 PMD가하지 않는 상자를 벗어나는 것이 중요하다면 해당 점검만으로 최소한의 체크 스타일 구성을 고려할 수 있습니다. 그런 다음 CheckStyle 구성이 성장할 수 없다는 정책을 제정하고, 사용자 정의 PMD 규칙과 함께 유사한 기능을 구현할 때 단순히 검사를 제거하십시오.

또한 CheckStyle "Import Control"기능이 Macker에서 원하는 것을 포함한다고 결정하면 PMD/Macker 대신 PMD/CheckStyle을 구현할 수 있습니다. 어느 쪽이든 그것은 두 가지 도구이지만 CheckStyle을 사용하면 PMD가 "무료로"를 사용하지 않는 것들을 얻을 수 있습니다.

지금까지 보지 못한 한 가지 요점은 코드에 CheckStyle 규칙 세트를 시행하는 IDE 용 플러그인이 있지만 PMD 플러그인은 위반에 대해서만보고합니다. 예를 들어, 여러 프로그래밍 팀의 다중 사이트 프로젝트에서는 표준을보고하는 것이 아니라 표준을 적극적으로 시행하는 것이 중요합니다.

두 도구 모두 Intellij, NetBeans 및 Eclipse에 사용할 수있는 플러그인이 있습니다 (제 생각에는 대부분의 사용법을 다룹니다). 나는 NetBeans에 익숙하지 않으므로 Intellij와 Eclipse에 대해서만 언급 할 수 있습니다.

어쨌든, Intellij 및 Eclipse 용 PMD 플러그인은 보고서를 생성합니다. 주문형 프로젝트 코드베이스 내에서 PMD 위반.

반면에 CheckStyle 플러그인은 즉시 위반을 강조하고 (적어도 Intellij의 경우, Eclipse에 대한 경험이 적음) 일부 문제를 자동으로 변환하도록 구성 될 수 있습니다 (예 : 'OnestatementPerline', CR-LF를 배치합니다. 'Needbraces'에 대한 진술 사이에는 누락 된 곳 등이 추가됩니다). 분명히, 더 간단한 위반 만 자동으로 수정 될 수 있지만 여전히 레거시 프로젝트 나 여러 위치에 위치한 프로젝트에 도움이됩니다.

PMD에 대한 '주문형'은 개발자가 의식적으로 보고서를 실행하기로 결정해야한다는 것을 의미합니다. 점검 스타일 위반은 개발대로 자동으로보고됩니다. PMD 동안 하다 보다 광범위한 규칙 세트를 포함합니다. 제 생각에는 IDE의 위반에 대한 자동 집행/보고는 2 개의 규칙을 유지하는 데 번거로운 가치가 있습니다.

따라서 내가 작업하는 모든 프로젝트의 경우, 우리는 두 도구, IDE에서 시행 된 CheckStyle, IDE에서보고 된 PMD 및 PMD를 모두 사용합니다. 둘 다 빌드에서보고 및 측정 (Jenkins를 통해).

그리고 10 년 후 ... 2018 년에 나는 모두 CheckStyle, PMD 및 FindBugs를 사용합니다.

시작합니다 FindBugs. 나중에 PMD와 CheckStyle을 추가 할 수도 있습니다.

기본 규칙을 맹목적으로 시행하지 마십시오 !

단계 :

코드가 많은 프로젝트에 기본 규칙이있는 도구 하나를 실행합니다.
이 프로젝트에 규칙을 조정하고 일부 메모와 함께 쓸모없는 규칙을 설명하십시오.
낮은 교수형 과일 규칙에 중점을 둡니다 (NPE, Logger Checks, Undross Resource Checks, ...)
가치있는 규칙에 대한 몇 가지 수정 사항을 수행하십시오 (한 번에 하나씩!)
각 도구에 대해이 작업을 수행하지만 한 번에 모두 수행하지는 않습니다!
이 과정을 반복하십시오

이상적으로 각 프로젝트에는 별도의 규칙이있을 수 있습니다. 나는 빌드 (Maven 플러그인을 통해)를 통해 규칙을 실행하는 것을 좋아하고 프로젝트가 내가 정의한 모든 규칙을 전달한다는 것을 알게되면 규칙 오류에 실패합니다. 이로 인해 개발자들은 조치를 취해야합니다 보고만으로는 충분하지 않습니다. 프로젝트의 시점부터는 거의 방탄 증명이며 나중에 더 많은 규칙을 추가하거나 사용자 정의 규칙을 작성할 수도 있습니다.

보세요 Qulice-Maven-Plugin 이로 인해 CheckStyle, PMD, FindBugs 및 기타 몇 가지 정적 분석기가 결합되어 사전 구성됩니다. 이 조합의 장점은 모든 프로젝트에서 개별적으로 구성 할 필요가 없다는 것입니다.

<plugin>
  <groupId>com.qulice</groupId>
  <artifactId>qulice-maven-plugin</artifactId>
  <version>0.15</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

PMD가 Java 스타일/컨벤션 확인을위한 최신 제품이라는 의견을 반영합니다. FindBug와 관련하여 많은 상업 개발 그룹이 은폐를 사용하고 있습니다.

방금 CheckStyle과 PMD를 사용하기 시작했습니다. 나에게 PMD는 System.gc (), runtime.gc ()가 존재하는지 여부에 관계없이 XPATH 쿼리를 작성할 수있는 한, 전혀 어려운 XPATH 쿼리를 작성할 수 있도록 사용자 정의 된 규칙을 작성하는 것이 더 쉽습니다. 그러나 PMD는 열 번호를 표시하는 기능이 있음을 보여주지 않았습니다. 검사 열 제한과 같은 것들. CheckStyle을 사용하고 싶을 수도 있습니다.

PMD는 내가 더 많은 사람들을 언급하는 것입니다. CheckStyle은 사람들이 4 년 전에 언급 한 것이었지만 PMD가 더 지속적으로 유지되고 다른 IDE/플러그인이 무엇을 선택하도록 선택했는지 믿습니다.

PMD는 체크 스타일과 비교할 때 가장 훌륭한 도구입니다. 체크 스타일은 코드를 분석 할 수있는 기능이 없을 수 있으며 PMD는 많은 기능을 제공합니다! Offcourse PMD는 Javadoc, 의견, 들여 쓰기 등에 대한 규칙을 공개하지 않았습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow