Checkstyle so với PMD

Chúng tôi đang giới thiệu các công cụ phân tích tĩnh vào hệ thống xây dựng cho sản phẩm Java của chúng tôi. Chúng tôi đang sử dụng Maven2 để tích hợp Checkstyle và PMD miễn phí. Tuy nhiên, có vẻ như có sự trùng lặp lớn về chức năng giữa hai công cụ này, về việc thực thi các quy tắc kiểu cơ bản.

Có lợi ích từ việc sử dụng cả hai điều này không? Tôi không muốn duy trì 2 công cụ nếu một công cụ sẽ hoạt động. Nếu chúng ta chọn một, chúng ta nên sử dụng cái nào và tại sao?

Chúng tôi cũng đang có kế hoạch sử dụng FindBugs. Có các công cụ phân tích tĩnh khác mà chúng ta nên xem xét không?

Cập nhật: Sự đồng thuận dường như là PMD được ưu tiên hơn CheckStyle. Tôi không thấy lý do chắc chắn để sử dụng cả hai và tôi không muốn duy trì 2 bộ tệp quy tắc, vì vậy chúng tôi có thể sẽ nhắm đến PMD riêng. Chúng tôi cũng sẽ đưa FindBugs vào, và có lẽ cuối cùng là Macker để thực thi các quy tắc kiến ​​trúc.

Bạn chắc chắn nên sử dụng FindBugs . Theo kinh nghiệm của tôi, tỷ lệ dương tính giả là rất thấp và ngay cả những cảnh báo ít quan trọng nhất mà nó báo cáo cũng đáng được giải quyết ở một mức độ nào đó.

Đối với Checkstyle so với PMD, tôi sẽ không sử dụng Checkstyle vì nó chỉ liên quan nhiều đến kiểu dáng. Theo kinh nghiệm của tôi, Checkstyle sẽ báo cáo về rất nhiều thứ hoàn toàn không liên quan. Mặt khác, PMD cũng có thể chỉ ra các thực hành mã hóa có vấn đề và đầu ra của nó nói chung là phù hợp và hữu ích hơn.

Cả hai phần mềm đều hữu ích. Checkstyle sẽ giúp bạn trong quá trình lập trình của bạn bằng cách kiểm tra kiểu mã hóa của bạn, ví dụ như dấu ngoặc nhọn, đặt tên, v.v. Những điều đơn giản nhưng rất nhiều!

PMD sẽ giúp bạn bằng cách kiểm tra các quy tắc phức tạp hơn như trong quá trình thiết kế các lớp của bạn, hoặc các vấn đề đặc biệt hơn như triển khai chính xác chức năng sao chép. Đơn giản, PMD sẽ kiểm tra phong cách lập trình của bạn

Tuy nhiên, cả hai phần mềm đều bị các quy tắc tương tự đôi khi giải thích không tốt. Với một cấu hình xấu, bạn có thể kiểm tra những thứ hai lần hoặc hai điều ngược lại, tức là "Loại bỏ các hàm tạo vô dụng" và "Luôn luôn là một hàm tạo".

Nếu chúng ta chọn một, chúng ta nên sử dụng cái nào và tại sao?

Các công cụ này không cạnh tranh nhưng bổ sung cho nhau và nên được sử dụng đồng thời.

Kiểu quy ước (Checkstyle) là chất kết dính cho phép mọi người làm việc cùng nhau và giải phóng khả năng sáng tạo của họ thay vì dành thời gian và năng lượng để hiểu mã không nhất quán.

Ví dụ về kiểu kiểm tra:

• Có javadoc trên các phương thức công khai không?
• Dự án có tuân theo quy ước đặt tên Mặt trời không?
• Mã có được viết với một định dạng nhất quán không?

trong khi PMD nhắc nhở bạn các phương pháp không tốt:

• Bắt một ngoại lệ mà không cần làm gì cả
• Có mã chết
• Quá nhiều phương pháp phức tạp
• Sử dụng trực tiếp các triển khai thay vì giao diện
• Triển khai phương thức hashcode () mà không có phương thức not = (Đối tượng đối tượng)

nguồn: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

Chúng tôi sử dụng cả hai:

• Kiểu kiểm tra để đảm bảo rằng mọi người trong nhóm viết mã trong một trình vẽ tương tự
• PMD để tìm các vùng mã có vấn đề và các mục tiêu tái cấu trúc tiếp theo

Nếu nơi sử dụng chính của bạn là khi đang phát triển trong eclipse, thì CodePro từ Instantiations sẽ là tốt nhất. Trước đó, nó là một công cụ thương mại, nhưng bây giờ Google đã mua Instantiations nên CodePro analytix hiện miễn phí.

Xem http://code.google.com/javadevtools/download-codepro.html

Nếu bạn đã xem xét danh sách quy tắc Checkstyle, PMD và Findbugs, bạn đã thấy rằng cả ba đều cung cấp đầu ra có giá trị và cả ba đều trùng lặp ở một mức độ và cũng đưa các quy tắc riêng, độc đáo của chúng vào bảng. Đây là lý do tại sao các công cụ như Sonar sử dụng cả ba.

Điều đó nói rằng, Findbugs có các quy tắc cụ thể hoặc thích hợp nhất (ví dụ: "Bắt được IllegalMonitorStateException" - bạn có thường xuyên gặp phải vấn đề đó không?) Vì vậy, nó có thể sử dụng được với ít hoặc không có cấu hình và các cảnh báo của nó nên được xem xét nghiêm túc. Với Checkstyle và PMD, các quy tắc tổng quát hơn và có liên quan đến phong cách, vì vậy chúng chỉ nên được sử dụng với các tệp cấu hình tùy chỉnh để giúp nhóm tránh khỏi một đợt phản hồi không liên quan ("Tab char trên dòng 5", "Tab char trên dòng 6", "Tab char trên dòng 7" ... bạn sẽ có được hình ảnh). Họ cũng cung cấp các công cụ mạnh mẽ để viết các quy tắc nâng cao của riêng bạn, ví dụ: quy tắc Checkstyle DescendentToken .

Khi sử dụng cả ba (đặc biệt là với một công cụ như Sonar), tất cả chúng nên được định cấu hình riêng biệt (mất ít nhất vài ngày để bao gồm tất cả các quy tắc) đồng thời chú ý để ngăn chặn sự trùng lặp (cả ba công cụ đều phát hiện rằng hashCode () đã được ví dụ: overridden và bằng () not).

Tóm lại, nếu bạn coi phân tích mã tĩnh là có giá trị, thì việc từ chối giá trị mà bất kỳ phương pháp nào trong ba cung cấp sẽ không có ý nghĩa gì, nhưng để sử dụng cả ba, bạn phải đầu tư thời gian để định cấu hình chúng để cung cấp cho bạn phản hồi có thể sử dụng được.

Sonar (http://www.sonarsource.org/) là một nền tảng mở rất hữu ích để quản lý chất lượng mã và bao gồm Checkstyle, PMD, Findbugs, v.v.

Điều này cũng chỉ ra rằng cả 3 công cụ đều có quyền tồn tại ...

Cả hai công cụ đều có thể định cấu hình và có thể thực hiện những việc giống nhau. Điều đó nói lên rằng, nếu chúng ta đang nói về những thứ độc đáo, sẽ có rất nhiều sự chồng chéo, nhưng cũng có những quy tắc / kiểm tra riêng biệt. Ví dụ: Checkstyle có hỗ trợ mạnh mẽ hơn để kiểm tra Javadoc và tìm các con số kỳ diệu, để đặt tên cho một cặp đôi. Ngoài ra, Checkstyle có một tính năng "kiểm soát nhập khẩu" trông tương tự như chức năng của Macker (Tôi chưa sử dụng Macker).

Nếu có những thứ quan trọng đối với bạn mà Checkstyle thực hiện được mà PMD thì không, bạn có thể xem xét một cấu hình Checkstyle tối thiểu chỉ với những lần kiểm tra đó. Sau đó, thiết lập một chính sách mà cấu hình Checkstyle không thể phát triển, chỉ cần xóa các kiểm tra khi bạn triển khai chức năng tương tự với các quy tắc PMD tùy chỉnh.

Cũng nên xem xét rằng nếu bạn quyết định rằng tính năng "kiểm soát nhập" của Checkstyle bao gồm những gì bạn muốn từ Macker, thì bạn có thể triển khai PMD / Checkstyle thay vì PMD / Macker. Dù bằng cách nào thì đây cũng là hai công cụ, nhưng với Checkstyle, bạn sẽ nhận được những thứ mà PMD không làm "miễn phí".

Checkstyle và PMD đều tốt trong việc kiểm tra các tiêu chuẩn mã hóa và dễ dàng mở rộng. Nhưng PMD có các quy tắc bổ sung để kiểm tra độ phức tạp theo chu kỳ, độ phức tạp Npath, v.v. cho phép bạn viết mã lành mạnh.

Một ưu điểm khác của việc sử dụng PMD là CPD (Copy / Paste Detector), nó phát hiện ra sự trùng lặp mã giữa các dự án và không bị ràng buộc với JAVA. Nó cũng hoạt động cho JSP. Neal Ford có một bài thuyết trình hay về Phát triển nhanh theo hướng đo lường , trong đó nói về nhiều công cụ hữu ích cho Phát triển Java / Java EE

Tôi thấy Checkstyle và PMD là tốt nhất để thực thi các vấn đề về phong cách và các lỗi mã hóa đơn giản rõ ràng. Mặc dù tôi thấy rằng tôi thích sử dụng Eclipse và tất cả các cảnh báo mà nó cung cấp tốt hơn cho mục đích đó. Chúng tôi thực thi nội dung bằng cách sử dụng các tùy chọn được chia sẻ và đánh dấu chúng là lỗi thực tế. Bằng cách đó, họ không bao giờ được đăng ký ngay từ đầu.

Điều tôi thực sự muốn giới thiệu và nhiệt tình là sử dụng FindBugs. Vì nó hoạt động ở mức bytecode nên nó có thể kiểm tra những thứ không thể xảy ra ở mức nguồn. Trong khi nó chia sẻ công bằng của nó, nó đã tìm thấy nhiều lỗi thực tế và quan trọng trong mã của chúng tôi.

Và 10 năm sau ... Vào năm 2018, tôi sử dụng tất cả chúng là Checkstyle, PMD và FindBugs.

Bắt đầu với FindBugs . Có thể thêm PMD và Checkstyle sau.

Không bao giờ thực thi một cách mù quáng các quy tắc mặc định !

Các bước:

• chạy một công cụ với các quy tắc mặc định trên một dự án có nhiều mã
• điều chỉnh các quy tắc cho dự án này, bình luận về các quy tắc vô ích với một số lưu ý
• tập trung vào các quy tắc quả treo thấp (NPE, kiểm tra trình ghi nhật ký, kiểm tra tài nguyên chưa được tiết lộ, ...)
• thực hiện một số bản sửa lỗi cho các quy tắc mà bạn thấy đáng giá (từng quy tắc một!)
• làm điều này cho từng công cụ nhưng không phải tất cả cùng một lúc!
• lặp lại quá trình này

Lý tưởng nhất là mỗi dự án có thể có các quy tắc riêng biệt. Tôi thích chạy các quy tắc thông qua bản dựng (thông qua các plugin maven) và không thành công với các lỗi quy tắc khi tôi biết một dự án vượt qua tất cả các quy tắc mà tôi đã xác định. Điều này buộc các nhà phát triển phải hành động vì báo cáo là không đủ . Từ thời điểm đó, dự án của bạn đã có khá nhiều gạch đầu dòng và bạn thậm chí có thể thêm nhiều quy tắc hơn sau này và / hoặc viết các quy tắc tùy chỉnh.

Một điểm mà tôi chưa thấy cho đến nay là có các plugin cho IDE sẽ thực thi các bộ quy tắc CheckStyle trên mã của bạn, trong khi các plugin PMD sẽ chỉ báo cáo về các vi phạm. Ví dụ: trong một dự án nhiều địa điểm với nhiều nhóm lập trình, điều quan trọng là phải tích cực thực thi các tiêu chuẩn, thay vì chỉ báo cáo về chúng.

Cả hai công cụ đều có sẵn các plugin cho IntelliJ, NetBeans và Eclipse (theo quan điểm của tôi, điều này bao gồm hầu hết việc sử dụng). Tôi không quen thuộc với NetBeans, vì vậy chỉ có thể nhận xét về IntelliJ và Eclipse.

Dù sao, các plugin PMD cho IntelliJ và Eclipse, sẽ tạo báo cáo theo yêu cầu về các vi phạm PMD trong cơ sở mã dự án.

Mặt khác, các plugin CheckStyle sẽ làm nổi bật các vi phạm ngay lập tức và có thể (ít nhất là đối với IntelliJ, tôi có ít kinh nghiệm hơn với Eclipse) được định cấu hình để tự động chuyển đổi một số vấn đề (ví dụ: đối với 'OneStatementPerLine', sẽ đặt CR-LF giữa các câu lệnh, đối với 'NeedBraces', sẽ thêm dấu ngoặc nhọn vào vị trí bị thiếu, v.v.). Rõ ràng, chỉ những vi phạm đơn giản hơn mới có thể được tự động sửa, nhưng nó vẫn giúp ích cho các dự án cũ hoặc các dự án nằm trên một số địa điểm.

'Theo yêu cầu' cho PMD có nghĩa là nhà phát triển phải quyết định một cách có ý thức để chạy báo cáo. Trong khi đó, các vi phạm Checkstyle được tự động báo cáo khi chúng phát triển. Mặc dù PMD có chứa một bộ quy tắc rộng rãi hơn, nhưng theo suy nghĩ của tôi, việc tự động thực thi / báo cáo vi phạm trong IDE là đáng để bạn phải duy trì 2 bộ quy tắc.

Vì vậy, đối với bất kỳ dự án nào tôi thực hiện, chúng tôi sử dụng cả hai công cụ, Kiểu kiểm tra được thực thi trong IDE, PMD được báo cáo trong IDE và cả hai đều được báo cáo và đo lường trong các bản dựng (thông qua Jenkins).

Hãy xem qua qulice-maven-plugin kết hợp Checkstyle, PMD, FindBugs và một vài trình phân tích tĩnh khác, đồng thời cấu hình trước chúng. Vẻ đẹp của sự kết hợp này là bạn không cần phải định cấu hình chúng riêng lẻ trong mọi dự án:

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

Tôi sẽ lặp lại nhận xét rằng PMD là sản phẩm hiện tại hơn để kiểm tra quy ước / kiểu Java. Đối với FindBugs, nhiều nhóm phát triển thương mại đang sử dụng Coverity.

PMD là thứ mà tôi thấy nhiều người đề cập hơn. Checkstyle là những gì mọi người đã đề cập đến 4 năm trước nhưng tôi tin rằng PMD được duy trì liên tục hơn và những gì IDE / plugin khác chọn để hoạt động.

Tôi mới bắt đầu sử dụng Checkstyle và PMD. Đối với tôi, PMD dễ dàng hơn trong việc tạo các quy tắc tùy chỉnh cho những thứ chẳng hạn như có tồn tại System.gc (), Runtime.gc (), miễn là bạn có thể viết Truy vấn XPath, điều này cũng không khó chút nào. Tuy nhiên PMD chưa cho tôi thấy nó có tính năng hiển thị số cột. Vì vậy, đối với những thứ như kiểm tra giới hạn cột. Bạn có thể muốn sử dụng Checkstyle.

PMD là công cụ tốt nhất khi so sánh với các kiểu kiểm tra. Các kiểu kiểm tra có thể không có khả năng phân tích mã trong khi PMD cung cấp nhiều tính năng để làm như vậy! Ngoại tình PMD đã không đưa ra các quy tắc cho javadoc, nhận xét, thụt đầu dòng, v.v. Và nhân tiện tôi đang lên kế hoạch thực hiện các quy tắc này ....... thanx