Java 제품의 빌드 시스템에 정적 분석 도구를 도입하고 있습니다. 우리는 Maven2를 사용 하고 있으므로 Checkstyle 과 PMD 통합은 무료입니다. 그러나 기본 스타일 규칙을 적용하는 측면에서이 두 도구간에 기능이 크게 겹치는 것처럼 보입니다.
이 두 가지를 모두 활용하면 이점이 있습니까? 하나가 작동한다면 두 가지 도구를 유지하고 싶지 않습니다. 하나를 선택하면 어떤 것을 사용해야하며 그 이유는 무엇입니까?
FindBugs도 사용할 계획입니다. 우리가 살펴 봐야 할 다른 정적 분석 도구가 있습니까?
업데이트 : PMD가 CheckStyle보다 선호된다는 것이 합의 된 것 같습니다. 두 가지를 모두 사용해야하는 확실한 이유가없고 2 세트의 규칙 파일을 유지하고 싶지 않으므로 PMD만을 목표로 할 것입니다. 또한 FindBugs를 도입 할 예정이며, 결국에는 Macker가 아키텍처 규칙을 시행 할 것입니다.
답변:
반드시 FindBugs를 사용해야 합니다. 내 경험상 오 탐률은 매우 낮으며,보고하는 최소한의 경고도 어느 정도 해결할 가치가 있습니다.
Checkstyle 대 PMD는 스타일에만 관심이 있기 때문에 Checkstyle을 사용하지 않을 것입니다. 제 경험상 Checkstyle은 완전히 무관 한 수많은 것들을보고 할 것입니다. 반면 PMD는 의심스러운 코딩 관행을 지적 할 수 있으며 그 결과는 일반적으로 더 관련성이 높고 유용합니다.
두 소프트웨어 모두 유용합니다. Checkstyle은 코딩 스타일 ( 예 : 중괄호, 이름 지정 등) 을 확인하여 프로그래밍하는 동안 도움이 될 것입니다 . 단순하지만 매우 다양합니다!
PMD는 클래스를 디자인하는 동안이나 복제 기능을 올바르게 구현하는 것과 같은 더 특별한 문제에 대해 더 복잡한 규칙을 확인하여 도움을 줄 것입니다. 간단히 말해 PMD는 프로그래밍 스타일 을 확인합니다.
그러나 두 소프트웨어 모두 유사한 규칙으로 인해 때때로 잘못 설명됩니다. 잘못된 구성으로 두 번 또는 두 번의 반대되는 사항을 확인할 수 있습니다. 즉, "쓸모없는 생성자 제거"와 "항상 하나의 생성자"입니다.
하나를 선택하면 어떤 것을 사용해야하며 그 이유는 무엇입니까?
이러한 도구는 경쟁적이지 않지만 보완 적이며 동시에 사용해야합니다.
규칙 유형 (Checkstyle)은 일관성없는 코드를 이해하는 데 시간과 에너지를 소비하는 대신 사람들이 함께 작업하고 창의성을 발휘할 수 있도록하는 접착제입니다.
체크 스타일 예 :
PMD는 나쁜 관행을 상기시킵니다.
출처 : http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/
기본 사용 장소가 Eclipse에서 개발하는 동안이면 인스턴스화의 CodePro가 가장 좋습니다. 이전에는 상용 도구 였지만 이제 Google이 인스턴스화를 구입했기 때문에 CodePro analytix는 현재 무료입니다.
http://code.google.com/javadevtools/download-codepro.html을 확인하세요 .
Checkstyle, PMD 및 Findbugs 규칙 목록을 검토 한 경우 세 가지 모두 귀중한 결과물을 제공하고 세 가지 모두 어느 정도 겹치며 테이블에 고유 한 고유 규칙을 가져 오는 것을 확인했습니다. 이것이 Sonar와 같은 도구가 세 가지를 모두 사용하는 이유입니다.
즉, Findbugs는 가장 구체적인 또는 틈새 규칙 (예 : "IllegalMonitorStateException의 중복 잡기"-얼마나 자주 발생할 가능성이 있습니까?)이 있으므로 구성이 거의 또는 전혀없이 사용할 수 있으며 경고를 심각하게 받아 들여야합니다. Checkstyle 및 PMD를 사용하면 규칙이 더 일반적이고 스타일과 관련되어 있으므로 사용자 지정 구성 파일과 함께 만 사용하여 관련없는 피드백의 눈사태로부터 팀을 보호해야합니다 ( "5 행에 탭 문자", "6 행에 탭 문자", "7 행에 탭 문자"... 그림이 표시됩니다.) 또한 자체 고급 규칙 (예 : Checkstyle DescendentToken) 을 작성할 수있는 강력한 도구를 제공합니다. .
세 가지를 모두 사용할 때 (특히 Sonar와 같은 도구를 사용하는 경우) 중복을 방지하기 위해주의를 기울이면서 (특히 Sonar와 같은 도구를 사용하는 경우) 모두 별도로 구성해야합니다 (모든 도구가 hashCode ()가 예를 들어 overridden 및 equals () not).
요약하면, 정적 코드 분석이 중요하다고 생각하고 세 가지 중 하나가 제공하는 값을 거부하는 것은 의미가 없지만 세 가지를 모두 사용하려면 유용한 피드백을 제공하도록 구성하는 데 시간을 투자해야합니다.
두 도구 모두 구성 가능하며 거의 동일한 작업을 수행 할 수 있습니다. 즉, 즉시 사용 가능한 항목에 대해 이야기하는 경우 겹치는 부분이 많지만 고유 한 규칙 / 검사도 있습니다. 예를 들어, Checkstyle은 Javadoc을 확인하고 매직 번호를 찾는 데 더 강력한 지원을 제공합니다. 또한 Checkstyle에는 Macker의 기능과 유사한 "가져 오기 제어"기능이 있습니다 (Macker를 사용하지 않았습니다).
PMD가 수행하지 않는 Checkstyle이 기본적으로 수행하는 중요한 작업이있는 경우 해당 검사 만 포함하는 최소 Checkstyle 구성을 고려할 수 있습니다. 그런 다음 Checkstyle 구성이 확장 될 수 없다는 정책을 도입하고 사용자 지정 PMD 규칙과 같은 유사한 기능을 구현할 때 검사를 제거하기 만하면됩니다.
또한 Checkstyle "import control"기능이 Macker에서 원하는 내용을 포함한다고 결정한 경우 PMD / Macker 대신 PMD / Checkstyle을 구현할 수 있습니다. 어느 쪽이든 두 가지 도구이지만 Checkstyle을 사용하면 PMD가 "무료로"기본적으로 수행하지 않는 작업을 얻을 수 있습니다.
Checkstyle과 PMD는 모두 코딩 표준을 확인하는 데 능숙하며 확장하기 쉽습니다. 그러나 PMD에는 순환 복잡성, Npath 복잡성 등을 확인하는 추가 규칙이있어 건강한 코드를 작성할 수 있습니다.
PMD 사용의 또 다른 장점은 CPD (Copy / Paste Detector)로, 프로젝트 간 코드 중복을 찾아 내고 JAVA에 제한되지 않으며 JSP에서도 작동합니다. Neal Ford는 Metrics Driven Agile Development 에 대한 좋은 프레젠테이션을 가지고 있으며 Java / Java EE 개발에 도움이되는 많은 도구에 대해 설명합니다.
Checkstyle과 PMD는 스타일 문제와 단순하고 명백한 코딩 버그를 적용하는 데 가장 적합합니다. 나는 Eclipse와 모든 경고를 사용하는 것을 좋아한다는 것을 알았지 만 그 목적에 더 적합합니다. 공유 된 환경 설정을 사용하고 실제 오류로 표시하여 항목을 시행합니다. 이렇게하면 처음부터 체크인하지 않습니다.
내가 강력하고 열정적으로 추천하는 것은 FindBugs를 사용하는 것입니다. 바이트 코드 수준에서 작동하기 때문에 소스 수준에서 불가능한 것을 확인할 수 있습니다. 공정한 몫의 쓰레기를 뱉어내는 동안 우리 코드에서 실제적이고 중요한 버그를 많이 발견했습니다.
그리고 10 년 후 ... 2018 년에는 모두 Checkstyle, PMD 및 FindBugs를 사용합니다.
FindBugs로 시작하십시오 . 나중에 PMD와 Checkstyle을 추가 할 수 있습니다.
기본 규칙을 맹목적으로 시행하지 마십시오 !
단계 :
이상적으로 각 프로젝트는 별도의 규칙을 가질 수 있습니다. 빌드 (maven 플러그인을 통해)를 통해 규칙을 실행하는 것을 좋아하고 프로젝트가 내가 정의한 모든 규칙을 통과한다는 것을 알게되면 규칙 오류에 실패합니다. 보고만으로는 충분하지 않기 때문에 개발자가 조치를 취해야합니다 . 프로젝트의 그 시점부터는 거의 방탄이되고 나중에 더 많은 규칙을 추가하거나 사용자 지정 규칙을 작성할 수도 있습니다.
지금까지 보지 못한 한 가지 점은 코드에 CheckStyle 규칙 세트를 적용하는 IDE 용 플러그인이있는 반면 PMD 플러그인은 위반 사항 만보고한다는 것입니다. 예를 들어, 여러 프로그래밍 팀에 걸친 다중 사이트 프로젝트에서는 단순히보고하는 것보다 적극적으로 표준을 시행하는 것이 중요합니다.
두 도구 모두 IntelliJ, NetBeans 및 Eclipse에 사용할 수있는 플러그인이 있습니다 (내 생각에는 대부분의 사용을 다룹니다). 저는 NetBeans에 익숙하지 않으므로 IntelliJ와 Eclipse에 대해서만 언급 할 수 있습니다.
어쨌든 IntelliJ 및 Eclipse 용 PMD 플러그인은 요청시 보고서 를 생성합니다 . 은 프로젝트 코드베이스 내에서 PMD 위반 .
반면 CheckStyle 플러그인은 즉시 위반 사항을 강조 표시하고 (적어도 IntelliJ의 경우 Eclipse에 대한 경험이 적습니다) 일부 문제를 자동으로 변환하도록 구성 할 수 있습니다 (예 : 'OneStatementPerLine'의 경우 CR-LF 배치). 문 사이, 'NeedBraces'의 경우 누락 된 곳에 중괄호를 추가합니다.) 분명히 더 간단한 위반 만 자동으로 수정할 수 있지만 레거시 프로젝트 또는 여러 위치에있는 프로젝트에서는 여전히 도움이됩니다.
PMD의 '주문형'은 개발자가 보고서 실행을 의식적으로 결정해야 함을 의미합니다. Checkstyle 위반은 발생하는 즉시 자동으로보고됩니다. PMD 는 에는 더 광범위한 규칙 세트 포함되어 , 제 생각에 IDE에서 위반 사항을 자동으로 적용 /보고하는 것은 2 개의 규칙 세트를 유지하는 번거 로움의 가치가 있습니다.
그래서 나는 우리가 두 도구를 사용하여 작업을 어떤 프로젝트, Checkstyle는 IDE 시행, PMD는 IDE에보고하고, 모두 빌드에서 (젠킨스를 통해)보고 및 측정.
Checkstyle, PMD, FindBugs 및 기타 몇 가지 정적 분석기를 결합하고 사전 구성하는 qulice-maven-plugin 을 살펴보십시오 . 이 조합의 장점은 모든 프로젝트에서 개별적으로 구성 할 필요가 없다는 것입니다.
<plugin>
<groupId>com.qulice</groupId>
<artifactId>qulice-maven-plugin</artifactId>
<version>0.15</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
settings.jar도움은.
PMD는 체크 스타일과 비교할 때 가장 훌륭한 도구입니다. 체크 스타일은 코드를 분석하는 기능이 없지만 PMD는 많은 기능을 제공합니다! Offcourse PMD는 javadoc, 주석, 들여 쓰기 등에 대한 규칙을 공개하지 않았습니다. 그런데이 규칙을 구현할 계획입니다 ....... 감사합니다.