체크 스타일 대 PMD

체크 스타일 대 PMD

---

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

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

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

업데이트 : PMD가 CheckStyle보다 선호된다는 것이 합의 된 것 같습니다. 두 가지를 모두 사용해야하는 확실한 이유가 없으며 2 세트의 규칙 파일을 유지하고 싶지 않으므로 PMD만을 목표로 할 것입니다. 우리는 또한 FindBugs, 그리고 아마도 결국에는 Macker를 도입하여 아키텍처 규칙을 시행 할 것입니다.

---

반드시 FindBugs를 사용해야 합니다. 내 경험상 오 탐률은 매우 낮으며,보고하는 최소한의 경고도 어느 정도 해결할 가치가 있습니다.

Checkstyle 대 PMD는 스타일에만 관심이 있기 때문에 Checkstyle을 사용하지 않습니다. 제 경험상 Checkstyle은 완전히 무관 한 수많은 것들을보고 할 것입니다. 반면 PMD는 의심스러운 코딩 관행을 지적 할 수 있으며 그 결과는 일반적으로 더 관련성이 높고 유용합니다.

---

두 소프트웨어 모두 유용합니다. Checkstyle은 코딩 스타일 ( 예 : 중괄호, 이름 지정 등) 을 확인하여 프로그래밍하는 동안 도움이 될 것입니다 . 단순하지만 매우 다양합니다!

PMD는 클래스를 디자인하는 동안이나 복제 기능을 올바르게 구현하는 것과 같은 더 특별한 문제에 대해 더 복잡한 규칙을 확인하여 도움을 줄 것입니다. 간단히, PMD는 프로그래밍 스타일 을 확인합니다.

그러나 두 소프트웨어 모두 유사한 규칙으로 인해 때때로 잘못 설명됩니다. 잘못된 구성으로 두 번 또는 두 가지 반대되는 사항을 확인할 수 있습니다. 즉, "쓸모없는 생성자 제거"및 "항상 하나의 생성자"입니다.

---

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

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

규칙 유형 (Checkstyle)은 일관성없는 코드를 이해하는 데 시간과 에너지를 소비하는 대신 사람들이 함께 작업하고 창의성을 발휘할 수 있도록하는 접착제입니다.

체크 스타일 예 :

• 공용 메소드에 javadoc이 있습니까?
• 프로젝트가 Sun 명명 규칙을 따르고 있습니까?
• 코드가 일관된 형식으로 작성 되었습니까?

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

• 아무것도하지 않고 예외 잡기
• 데드 코드
• 너무 많은 복잡한 방법
• 인터페이스 대신 구현 직접 사용
• not equals (Object object) 메서드없이 hashcode () 메서드 구현

출처 : http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

---

우리는 둘 다 사용합니다 :

• 팀의 모든 사람이 비슷한 방식으로 코드를 작성하는지 확인하는 체크 스타일
• 문제가있는 코드 영역과 다음 리팩토링 대상을 찾기위한 PMD

---

기본 사용 장소가 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와 같은 도구를 사용하는 경우) 모두 별도로 구성해야합니다. 예를 들어 overridden 및 equals () not).

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

---

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

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

---

Checkstyle and PMD both are good at checking coding standards and are easy to extend. But PMD has additional rules to check for cyclomatic complexity,Npath complexity,etc which allows you write healthy code.

Another advantage of using PMD is CPD (Copy/Paste Detector).It finds out code duplication across projects and is not constrained to JAVA.It works for JSP too. Neal Ford has a good presentation on Metrics Driven Agile Development, which talks about many tools that are helpful for Java/Java EE Development

---

I find Checkstyle and PMD are best for enforcing style issues and simple obvious coding bugs. Although I've found that I like using Eclipse and all the warnings it provides better for that purpose. We enforce stuff by using shared preferences and marking them as actual errors. That way, they never get checked in in the first place.

What I would strongly and enthusiastically recommend is using FindBugs. Because it works at the bytecode level it can check things that are impossible at the source level. While it spits out its fair share of junks, it has found many actual and important bugs in our code.

---

Both tools are configurable and can do just about the same things. That said, if we're talking about out-of-the-box stuff, there is a great deal of overlap, but there are distinct rules/checks as well. For example, Checkstyle has stronger support for checking Javadoc and finding magic numbers, to name a couple. Additionally, Checkstyle has an "import control" feature that looks similar to the functionality of Macker (I've not used Macker).

If there are things that are important to you that Checkstyle does out-of-the-box that PMD doesn't, you might consider a minimal Checkstyle configuration with only those checks. Then institute a policy that the Checkstyle configuration cannot grow, simply remove checks as you implement similar functionality with, say, custom PMD rules.

Also consider that if you decide that the Checkstyle "import control" feature covers what you wanted from Macker, then you could implement PMD/Checkstyle instead of PMD/Macker. Either way it's two tools, but with Checkstyle, you'd get the stuff that PMD doesn't do out-of-the-box "for free."

---

One point I have not seen so far is that there are plugins for IDEs that will enforce CheckStyle rulesets on your code, whereas PMD plugins will only report on violations. For example, in a multi-site project over several programming teams, it's important to actively enforce standards, rather than just to report on them.

Both tools have plugins available for IntelliJ, NetBeans, and Eclipse (in my view this covers most usage). I'm not as familiar with NetBeans, so can only comment on IntelliJ and Eclipse.

Anyway, the PMD plugins for IntelliJ, and Eclipse, will generate reports on demand on PMD violations within the project codebase.

The CheckStyle plugins, on the other hand, will highlight violations on the fly, and can (at least for IntelliJ, I have less experience with Eclipse) be configured to automatically convert some issues (e.g. for 'OneStatementPerLine', will place CR-LF between statements, for 'NeedBraces', will add braces where they are missing, etc.). Obviously, only the simpler violations can be automatically fixed, but it's still a help on legacy projects, or projects located over several locations.

'On demand' for PMD means that the developer must consciously decide to run the report. Whereas Checkstyle violations are automatically reported to them as they develop. While PMD does contain a more extensive ruleset, in my mind the automatic enforecement/reporting of violations in IDEs is worth the hassle of maintaining 2 sets of rules.

So for any projects I work on, we use both tools, Checkstyle enforced in the IDE, PMD reported in the IDE, and both reported and measured in builds (through Jenkins).

---

And 10 years later ... In 2018 I use all of them Checkstyle, PMD and FindBugs.

Start with FindBugs. Maybe add PMD and Checkstyle later.

Never blindly enforce the default rules !

Steps:

• run one tool with default rules on a project which has a lot of code
• adapt the rules to this project, comment out useless rules with some notes
• focus on the low hanging fruits rules (NPE, logger checks, unclosed resource checks, ...)
• perform some fixes for rules you find worthwhile (one at a time !)
• do this for each tool but not all at once !
• repeat this process

Ideally each project can have separate rules. I like running the rules via the build (via maven plugins) and fail on rule errors once I know a project passes all the rules I defined. This forces developers to take action, because reporting is not enough. From that point on your project is pretty much bullet proof and you could even add more rules later on and/or write custom rules.

---

Take a look at qulice-maven-plugin that combines together Checkstyle, PMD, FindBugs and a few other static analyzers, and pre-configures them. The beauty of this combination is that you don't need to configure them individually in every project:

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

---

I would echo the comment that PMD is the more current product for Java style/convention checking. With respect to FindBugs, many commercial development groups are using Coverity.

---

I have just started to use Checkstyle and PMD. To me, PMD is more easier to create customized rules for things such that whether there exists System.gc(), Runtime.gc(), as long as you can write the XPath Query which is also not difficult at all. However, PMD has not shown me that it has the feature to show column number. So for things like check column limits. You might would like to use Checkstyle.

---

PMD is what I find more people referring to. Checkstyle was what people were referring to 4 years ago but I believe PMD is maintained more continuously and what other IDEs/plugins choose to work with.

---

PMD is the finest tool when compare with checkstyles. Checkstyles may not have the capability to analyse the code while PMD offering many features to do so! Offcourse PMD has not released rules for javadoc, comments, indentations and etc. And by the way i am planning to implement these rules.......thanx

참고URL : https://stackoverflow.com/questions/184563/checkstyle-vs-pmd