Checkstyle เทียบกับ PMD

เรากำลังนำเสนอเครื่องมือวิเคราะห์แบบคงที่ในระบบบิลด์สำหรับผลิตภัณฑ์ Java ของเรา เราใช้ Maven2 ดังนั้นการผสานรวมCheckstyleและPMDจึงฟรี อย่างไรก็ตามดูเหมือนว่ามีการทำงานที่ทับซ้อนกันระหว่างเครื่องมือทั้งสองนี้ในแง่ของการบังคับใช้กฎสไตล์พื้นฐาน

มีประโยชน์จากการใช้ทั้งสองอย่างนี้หรือไม่? ฉันไม่ต้องการบำรุงรักษาเครื่องมือ 2 ชิ้นหากจะใช้งานได้ ถ้าเราจะเลือกเราควรใช้อันไหนและทำไม?

เรากำลังวางแผนที่จะใช้ FindBugs มีเครื่องมือวิเคราะห์แบบคงที่อื่น ๆ ที่เราควรดูหรือไม่?

อัปเดต:ฉันทามติดูเหมือนว่า PMD เป็นที่ต้องการมากกว่า CheckStyle ฉันไม่เห็นเหตุผลที่ชัดเจนที่จะใช้ทั้งสองอย่างและฉันไม่ต้องการรักษาไฟล์กฎ 2 ชุดดังนั้นเราอาจตั้งเป้าไปที่ PMD โดยเฉพาะ เราจะนำ FindBugs เข้ามาด้วยและในที่สุด Macker ก็บังคับใช้กฎสถาปัตยกรรม

แน่นอนคุณควรใช้FindBugs จากประสบการณ์ของฉันอัตราผลบวกที่ผิดพลาดนั้นต่ำมากและแม้แต่คำเตือนที่สำคัญน้อยที่สุดที่รายงานก็ควรค่าแก่การกล่าวถึงในระดับหนึ่ง

สำหรับ Checkstyle กับ PMD ฉันจะไม่ใช้ Checkstyle เพราะมันค่อนข้างเกี่ยวข้องกับสไตล์เท่านั้น จากประสบการณ์ของฉัน Checkstyle จะรายงานสิ่งต่างๆมากมายที่ไม่เกี่ยวข้องโดยสิ้นเชิง ในทางกลับกัน PMD ยังสามารถชี้ให้เห็นถึงแนวทางปฏิบัติในการเข้ารหัสที่น่าสงสัยและโดยทั่วไปแล้วผลลัพธ์จะมีความเกี่ยวข้องและเป็นประโยชน์มากกว่า

ซอฟต์แวร์ทั้งสองมีประโยชน์ Checkstyle จะช่วยคุณในระหว่างการเขียนโปรแกรมของคุณโดยตรวจสอบรูปแบบการเข้ารหัสของคุณเช่นวงเล็บปีกกาการตั้งชื่อ ฯลฯ สิ่งง่ายๆ แต่มีมากมาย!

PMD จะช่วยคุณโดยการตรวจสอบกฎที่ซับซ้อนมากขึ้นเช่นในระหว่างการออกแบบคลาสของคุณหรือสำหรับปัญหาพิเศษอื่น ๆ เช่นการใช้ฟังก์ชันโคลนอย่างถูกต้อง PMD จะตรวจสอบรูปแบบการเขียนโปรแกรมของคุณ

อย่างไรก็ตามทั้งสองโปรแกรมต้องทนทุกข์ทรมานจากกฎที่คล้ายกันบางครั้งอธิบายไม่ดี ด้วยการกำหนดค่าที่ไม่ดีคุณสามารถตรวจสอบสิ่งที่ตรงกันข้ามได้สองครั้งหรือสองสิ่งเช่น "ลบตัวสร้างที่ไร้ประโยชน์" และ "ตัวสร้างเดียวเสมอ"

ถ้าเราจะเลือกเราควรใช้อันไหนและทำไม?

เครื่องมือเหล่านี้ไม่ได้แข่งขันกัน แต่เป็นอุปกรณ์เสริมและควรใช้พร้อมกัน

รูปแบบการประชุม (Checkstyle) เป็นกาวที่ช่วยให้ผู้คนสามารถทำงานร่วมกันและปลดปล่อยความคิดสร้างสรรค์แทนที่จะใช้เวลาและพลังงานในการทำความเข้าใจรหัสที่ไม่สอดคล้องกัน

ตัวอย่างการตรวจสอบสไตล์:

• มี javadoc ในวิธีสาธารณะหรือไม่?
• โครงการเป็นไปตามข้อกำหนดการตั้งชื่อของ Sun หรือไม่?
• รหัสถูกเขียนด้วยรูปแบบที่สอดคล้องกันหรือไม่?

ในขณะที่ PMD เตือนคุณถึงการปฏิบัติที่ไม่ดี:

• จับข้อยกเว้นโดยไม่ต้องทำอะไร
• มีรหัสตาย
• วิธีการที่ซับซ้อนมากเกินไป
• การใช้งานโดยตรงแทนอินเทอร์เฟซ
• การใช้วิธี hashcode () โดยไม่ใช้วิธี not equals (Object object)

ที่มา: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

เราใช้ทั้งสองอย่าง:

• ตรวจสอบสไตล์เพื่อให้แน่ใจว่าทุกคนในทีมเขียนโค้ดด้วยท่าทางที่คล้ายกัน
• PMD เพื่อค้นหาพื้นที่โค้ดที่มีปัญหาและเป้าหมายการปรับโครงสร้างถัดไป

หากสถานที่ใช้งานหลักของคุณอยู่ในขณะที่พัฒนาใน eclipse CodePro จาก Instantiation จะดีที่สุด ก่อนหน้านี้เป็นเครื่องมือทางการค้า แต่ตอนนี้ Google ซื้อการค้นหาทันใจเพื่อให้ CodePro analytix ใช้งานได้ฟรี

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

หากคุณตรวจสอบรายการกฎของ Checkstyle, PMD และ Findbugs คุณจะเห็นว่าทั้งสามรายการให้ผลลัพธ์ที่มีคุณค่าและทั้งสามมีความทับซ้อนกันในระดับหนึ่งและยังนำกฎที่เป็นเอกลักษณ์ของตนเองมาไว้ในตารางด้วย นี่คือเหตุผลที่เครื่องมืออย่าง Sonar ใช้ทั้งสามตัว

ที่กล่าวว่า Findbugs มีกฎที่เฉพาะเจาะจงหรือเฉพาะเจาะจงมากที่สุด (เช่น "การจับ IllegalMonitorStateException ที่น่าสงสัย" คุณมีแนวโน้มที่จะพบบ่อยเพียงใด) ดังนั้นจึงสามารถใช้งานได้โดยมีการกำหนดค่าเพียงเล็กน้อยหรือไม่มีเลยและคำเตือนควรได้รับการปฏิบัติอย่างจริงจัง ด้วย Checkstyle และ PMD กฎจะมีความทั่วไปและเกี่ยวข้องกับสไตล์มากขึ้นดังนั้นจึงควรใช้กับไฟล์การกำหนดค่าที่กำหนดเองเพื่อช่วยทีมจากการตอบรับที่ไม่เกี่ยวข้องอย่างถล่มทลาย ("Tab char on line 5", "Tab char on line 6", "แท็บถ่านบรรทัดที่ 7" ... คุณจะได้รับภาพ) นอกจากนี้ยังมีเครื่องมือที่มีประสิทธิภาพในการเขียนกฎขั้นสูงของคุณเองเช่นกฎCheckstyle DescendentToken

เมื่อใช้ทั้งสามอย่าง (โดยเฉพาะกับเครื่องมือเช่น Sonar) ควรกำหนดค่าทั้งหมดแยกกัน (ใช้เวลาอย่างน้อยสองสามวันเพื่อให้ครอบคลุมกฎทั้งหมด) ในขณะที่ให้ความสำคัญกับการป้องกันการทำซ้ำ (เครื่องมือทั้งสามตรวจพบว่า hashCode () ได้รับการ แทนที่และเท่ากับ () ไม่เช่น)

โดยสรุปหากคุณคิดว่าการวิเคราะห์โค้ดแบบคงที่มีคุณค่าการปฏิเสธค่าใด ๆ ในสามข้อนั้นไม่สมเหตุสมผล แต่ในการใช้ทั้งสามข้อคุณต้องเสียเวลาในการกำหนดค่าเพื่อให้ข้อเสนอแนะที่ใช้งานได้

Sonar (http://www.sonarsource.org/) เป็นแพลตฟอร์มแบบเปิดที่มีประโยชน์มากในการจัดการคุณภาพโค้ดรวมถึง Checkstyle, PMD, Findbugs และอื่น ๆ อีกมากมาย

นอกจากนี้ยังบ่งชี้ว่าเครื่องมือทั้ง 3 มีสิทธิ์ที่จะมีอยู่ ...

เครื่องมือทั้งสองสามารถกำหนดค่าได้และสามารถทำสิ่งเดียวกันได้ ที่กล่าวว่าหากเรากำลังพูดถึงของนอกกรอบจะมีการทับซ้อนกันมากมาย แต่ก็มีกฎ / การตรวจสอบที่แตกต่างกันเช่นกัน ตัวอย่างเช่น Checkstyle มีการสนับสนุนที่แข็งแกร่งกว่าสำหรับการตรวจสอบ Javadoc และการค้นหาหมายเลขเวทมนตร์เพื่อตั้งชื่อคู่ นอกจากนี้ Checkstyle ยังมีคุณลักษณะ "การควบคุมการนำเข้า" ที่ดูคล้ายกับการทำงานของ Macker (ฉันไม่ได้ใช้ Macker)

หากมีสิ่งที่สำคัญสำหรับคุณที่ Checkstyle ทำนอกกรอบที่ PMD ไม่ทำคุณอาจพิจารณาการกำหนดค่า Checkstyle ขั้นต่ำที่มีเฉพาะการตรวจสอบเหล่านั้น จากนั้นกำหนดนโยบายที่การกำหนดค่า Checkstyle ไม่สามารถขยายได้เพียงแค่ลบการตรวจสอบออกเมื่อคุณใช้ฟังก์ชันที่คล้ายกันกับกฎ PMD ที่กำหนดเอง

นอกจากนี้โปรดพิจารณาด้วยว่าหากคุณตัดสินใจว่าคุณลักษณะ "การควบคุมการนำเข้า" ของ Checkstyle ครอบคลุมสิ่งที่คุณต้องการจาก Macker คุณสามารถใช้ PMD / Checkstyle แทน PMD / Macker ได้ ไม่ว่าจะด้วยวิธีใดก็ตามมันเป็นเครื่องมือสองอย่าง แต่ด้วย 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 เนื่องจากการทำงานในระดับ bytecode จึงสามารถตรวจสอบสิ่งที่เป็นไปไม่ได้ในระดับต้นทาง แม้ว่ามันจะกระจายส่วนแบ่งที่ยุติธรรมของเรือสำเภา แต่ก็พบข้อบกพร่องที่เกิดขึ้นจริงและสำคัญมากมายในโค้ดของเรา

และ 10 ปีต่อมา ... ในปี 2018 ฉันใช้ Checkstyle, PMD และ FindBugs ทั้งหมด

เริ่มต้นด้วยFindBugs อาจเพิ่ม PMD และ Checkstyle ในภายหลัง

อย่าบังคับใช้กฎเริ่มต้นอย่างสุ่มสี่สุ่มห้า !

ขั้นตอน:

• เรียกใช้เครื่องมือหนึ่งด้วยกฎเริ่มต้นในโครงการที่มีรหัสจำนวนมาก
• ปรับกฎให้เข้ากับโครงการนี้แสดงความคิดเห็นเกี่ยวกับกฎที่ไร้ประโยชน์พร้อมบันทึกย่อบางส่วน
• มุ่งเน้นไปที่กฎผลไม้แขวนต่ำ (NPE, การตรวจสอบคนตัดไม้, การตรวจสอบทรัพยากรที่ไม่เปิดเผย, ... )
• แก้ไขกฎที่คุณคิดว่าคุ้มค่า (ทีละข้อ!)
• ทำเช่นนี้กับแต่ละเครื่องมือ แต่ไม่ใช่ทั้งหมดในคราวเดียว!
• ทำซ้ำขั้นตอนนี้

โดยหลักการแล้วแต่ละโครงการสามารถมีกฎแยกกันได้ ฉันชอบรันกฎผ่านบิลด์ (ผ่านปลั๊กอิน maven) และล้มเหลวในข้อผิดพลาดของกฎเมื่อฉันรู้ว่าโปรเจ็กต์ผ่านกฎทั้งหมดที่ฉันกำหนดไว้ นี้นักพัฒนากองกำลังที่จะดำเนินการเพราะการรายงานไม่เพียงพอ จากจุดนั้นในโครงการของคุณเป็นหลักฐานแสดงหัวข้อย่อยค่อนข้างมากและคุณสามารถเพิ่มกฎเพิ่มเติมได้ในภายหลังและ / หรือเขียนกฎที่กำหนดเอง

จุดหนึ่งที่ฉันไม่เคยเห็นมาก่อนคือมีปลั๊กอินสำหรับ IDE ที่จะบังคับใช้ชุดกฎ CheckStyle กับโค้ดของคุณในขณะที่ปลั๊กอิน PMD จะรายงานเฉพาะการละเมิดเท่านั้น ตัวอย่างเช่นในโครงการหลายไซต์ที่มีทีมเขียนโปรแกรมหลายทีมสิ่งสำคัญคือต้องบังคับใช้มาตรฐานอย่างจริงจังแทนที่จะรายงานเรื่องเหล่านี้

เครื่องมือทั้งสองมีปลั๊กอินสำหรับ IntelliJ, NetBeans และ Eclipse (ในมุมมองของฉันสิ่งนี้ครอบคลุมการใช้งานส่วนใหญ่) ฉันไม่คุ้นเคยกับ NetBeans ดังนั้นจึงสามารถแสดงความคิดเห็นได้เฉพาะ IntelliJ และ Eclipse เท่านั้น

อย่างไรก็ตามปลั๊กอิน PMD สำหรับ IntelliJ และ Eclipse จะสร้างรายงานตามความต้องการเกี่ยวกับการละเมิด PMD ภายใน codebase โครงการ

ในทางกลับกันปลั๊กอิน CheckStyle จะเน้นการละเมิดได้ทันทีและ (อย่างน้อยสำหรับ IntelliJ ฉันมีประสบการณ์น้อยกว่ากับ Eclipse) ได้รับการกำหนดค่าให้แปลงปัญหาบางอย่างโดยอัตโนมัติ (เช่นสำหรับ 'OneStatementPerLine' จะวาง CR-LF ระหว่างคำสั่งสำหรับ "NeedBraces" จะเพิ่มวงเล็บปีกกาในจุดที่ขาด ฯลฯ ) เห็นได้ชัดว่ามีเพียงการละเมิดที่ง่ายกว่าเท่านั้นที่สามารถแก้ไขได้โดยอัตโนมัติ แต่ยังคงเป็นความช่วยเหลือสำหรับโครงการเดิมหรือโครงการที่ตั้งอยู่ในหลายสถานที่

'ตามความต้องการ' สำหรับ PMD หมายความว่าผู้พัฒนาต้องตัดสินใจเรียกใช้รายงานอย่างมีสติ ในขณะที่การละเมิด Checkstyle จะรายงานโดยอัตโนมัติเมื่อเกิดขึ้น ในขณะที่ PMD ทำมีชุดกฎที่กว้างขวางกว่า แต่ในใจของฉันการคาดการณ์ / การรายงานการละเมิดโดยอัตโนมัติใน IDE นั้นคุ้มค่ากับความยุ่งยากในการรักษากฎ 2 ชุด

ดังนั้นสำหรับโครงการใด ๆ ที่ฉันทำงานอยู่เราจึงใช้ทั้งสองเครื่องมือ Checkstyle ที่บังคับใช้ใน IDE PMD ที่รายงานใน IDE และทั้งรายงานและวัดผลในบิลด์ (ผ่าน Jenkins)

ดู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 ในส่วนของ FindBugs กลุ่มพัฒนาเชิงพาณิชย์จำนวนมากใช้ Coverity

PMD คือสิ่งที่ฉันพบว่ามีคนอ้างถึงมากขึ้น Checkstyle คือสิ่งที่ผู้คนอ้างถึงเมื่อ 4 ปีก่อน แต่ฉันเชื่อว่า PMD ได้รับการดูแลอย่างต่อเนื่องมากขึ้นและ IDE / ปลั๊กอินอื่น ๆ เลือกที่จะทำงานร่วมกับอะไร

ฉันเพิ่งเริ่มใช้ Checkstyle และ PMD สำหรับฉันแล้ว PMD นั้นง่ายกว่าในการสร้างกฎที่กำหนดเองสำหรับสิ่งต่างๆเช่นว่ามี System.gc (), Runtime.gc () หรือไม่ตราบใดที่คุณสามารถเขียน XPath Query ซึ่งก็ไม่ใช่เรื่องยากเลย อย่างไรก็ตาม PMD ไม่ได้แสดงให้ฉันเห็นว่ามีคุณสมบัติในการแสดงหมายเลขคอลัมน์ ดังนั้นสำหรับสิ่งต่างๆเช่นขีด จำกัด ของคอลัมน์ตรวจสอบ คุณอาจต้องการใช้ Checkstyle

PMD เป็นเครื่องมือที่ดีที่สุดเมื่อเปรียบเทียบกับ checkstyles Checkstyles อาจไม่มีความสามารถในการวิเคราะห์โค้ดในขณะที่ PMD มีคุณสมบัติมากมายให้ทำเช่นนั้น! Offcourse PMD ไม่ได้ออกกฎสำหรับ javadoc ความคิดเห็นการเยื้องและอื่น ๆ และโดยวิธีการที่ฉันวางแผนที่จะใช้กฎเหล่านี้ ....... ขอบคุณ