CheckStyle مقابل PMD

Question

نقدم أدوات تحليل ثابتة في نظام البناء لمنتج Java الخاص بنا. نحن نستخدم maven2 لذلك CheckStyle و PMD التكامل يأتي مجانا. ومع ذلك ، يبدو أن هناك تداخلًا كبيرًا في الوظيفة بين هاتين الأداة ، من حيث فرض قواعد النمط الأساسية.

هل هناك فائدة من استخدام كل من هذين؟ لا أريد الحفاظ على أداة 2 إذا كان أحد سيعمل. إذا اخترنا واحدة ، أي واحد يجب أن نستخدمه ولماذا؟

نحن نخطط أيضًا لاستخدام FindBugs. هل هناك أدوات تحليل ثابتة أخرى يجب أن ننظر إليها؟

تحديث: يبدو أن الإجماع هو أن PMD مفضل على طراز CheckStyle. لا أرى سببًا قويًا لاستخدام كليهما ، ولا أريد الحفاظ على مجموعتين من ملفات القواعد ، لذلك ربما نهدف إلى PMD حصريًا. سنحضر أيضًا FindBugs ، وربما ، في النهاية ، Macker لفرض القواعد المعمارية.

Answer 1

يجب عليك بالتأكيد استخدام FindBugs. في تجربتي ، يكون المعدل الإيجابي الخاطئ منخفضًا جدًا ، وحتى التحذيرات الأقل صرامة التي تقاريرها تستحق معالجتها إلى حد ما.

أما بالنسبة لـ CheckStyle مقابل PMD ، فلن أستخدم CheckStyle لأنه لا يهتم إلا بالأناقة. في تجربتي ، ستقوم CheckStyle بالإبلاغ عن الكثير من الأشياء غير ذات الصلة تمامًا. من ناحية أخرى ، فإن PMD قادر أيضًا على الإشارة إلى ممارسات الترميز المشكوك فيها وإخراجها بشكل عام أكثر صلة ومفيدة.

Answer 2

كلا البرامج مفيدة. سوف تساعدك CheckStyle أثناء البرمجة عن طريق التحقق نمط الترميز أي الأقواس ، التسمية وما إلى ذلك. أشياء بسيطة ولكن كثيرة جدا!

سيساعدك PMD عن طريق التحقق من قواعد أكثر تعقيدًا كما أثناء تصميم الفصول الدراسية ، أو لمزيد من المشكلات الخاصة مثل تنفيذ وظيفة الاستنساخ بشكل صحيح. ببساطة ، سيتحقق PMD الخاص بك أسلوب البرمجة

ومع ذلك ، فإن كلا البراميات تعاني من قواعد مماثلة في بعض الأحيان أوضحت سيئة. مع تكوين سيئ ، يمكنك التحقق من الأشياء مرتين أو شيئين مقابل "إزالة المُنشئين عديمة الفائدة" و "دائمًا مُنشئ واحد".

Answer 3

إذا اخترنا واحدة ، أي واحد يجب أن نستخدمه ولماذا؟

هذه الأدوات ليست منافسة ولكنها مكملة ويجب استخدامها في وقت واحد.

نوع الاتفاقية (CheckStyle) هو الغراء الذي يمكّن الأشخاص من العمل معًا وتحرير إبداعهم بدلاً من قضاء الوقت والطاقة في فهم التعليمات البرمجية غير المتسقة.

أمثلة CheckStyle:

• هل هناك جافادوك على الأساليب العامة؟
• هل المشروع بعد اتفاقيات تسمية الشمس؟
• هل الكود مكتوب بتنسيق ثابت؟

بينما يذكرك PMD الممارسات السيئة:

• التقاط استثناء دون القيام بأي شيء
• وجود رمز ميت
• الكثير من الطرق المعقدة
• الاستخدام المباشر للتطبيقات بدلاً من الواجهات
• تنفيذ طريقة hashcode () بدون طريقة عدم المساواة (كائن الكائن)

مصدر:http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

Answer 4

نستخدم كلاهما:

• CheckStyle للتأكد من أن كل شخص في الفريق يكتب الرمز في مانر مماثل
• PMD لإيجاد مناطق الكود إشكالية وأهداف إعادة النية التالية

Answer 5

إذا كان مكان الاستخدام الأساسي الخاص بك هو أثناء التطور في Eclipse ، فسيكون CodePro من الاستئصال الأفضل. في وقت سابق ، كانت أداة تجارية ، ولكن الآن اشترت Google إنشاءات ، لذا أصبح CodePro Analytix مجانيًا الآن.

الدفع http://code.google.com/javadevtools/download-codepro.html

Answer 6

إذا قمت بمراجعة قوائم قواعد CheckStyle و PMD و FindBugs ، فقد رأيت أن الثلاثة يوفرون ناتجًا قيماً وتداخل جميع الثلاثة إلى حد ما وأيضًا إحضار قواعدهم الفريدة إلى الطاولة. هذا هو السبب في استخدام أدوات مثل السونار الثلاثة.

ومع ذلك ، فإن FindBugs لديه القواعد الأكثر تحديداً أو المتخصصة (على سبيل المثال ، "التقاط المشكوك فيه لـ INCLAWLALMONITORTATEXCEPTION" - كم مرة من المحتمل أن تصادف ذلك؟) لذلك يمكن استخدامها مع تكوين ضئيل أو معدوم ويجب أن تؤخذ تحذيراته على محمل الجد. مع CheckStyle و PMD ، تكون القواعد أكثر عمومية وذات صلة بالأناقة بحيث يجب استخدامها فقط مع ملفات التكوين المخصصة لتجنيب الفريق من انهيار من ردود الفعل غير ذات الصلة ("Tab char on Line 5" ، "Tab char on Line 6" "Tab char on Line 7" ... تحصل على الصورة). كما أنها توفر أدوات قوية لكتابة قواعدك المتقدمة ، على سبيل المثال SEDCENDYTOKEN قاعدة.

عند استخدام الثلاثة (خاصة مع أداة مثل Sonar) ، يجب تكوين جميعهم بشكل منفصل (يستغرق الأمر بضعة أيام على الأقل لتغطية جميع القواعد) أثناء الانتباه لمنع الازدواج تجاوزت و equals () لا ، على سبيل المثال).

باختصار ، إذا كنت تفكر في تحليل الكود الثابت قيمة ، فسترفض القيمة الثلاثة أيًا لا معنى له ، ولكن لاستخدام الثلاثة ، يجب عليك استثمار الوقت لتكوينها لمنحك تعليقات قابلة للاستخدام.

Answer 7

Sonar (http://www.sonarsource.org/) هو منصة مفتوحة مفيدة للغاية لإدارة جودة التعليمات البرمجية ، وتتضمن checkstyle و PMD و FindBugs وغير ذلك الكثير.

هذا يشير أيضًا إلى أن جميع الأدوات الثلاثة لها حقها في الوجود ...

Answer 8

يعد كل من CheckStyle و PMD جيدًا في التحقق من معايير الترميز ويسهل تمديده. لكن لدى PMD قواعد إضافية للتحقق من التعقيد السيكلومي ، وتعقيد القناة ، وما إلى ذلك ، مما يتيح لك كتابة رمز صحي.

ميزة أخرى لاستخدام PMD هي CPD (كاشف نسخ/لصق). يجد تكرار الرمز عبر المشاريع وليس مقيدًا بـ Java.it يعمل لدى JSP أيضًا. نيل فورد لديه عرض جيد على تقود المقاييس تنمية رشيقة, ، التي تتحدث عن العديد من الأدوات المفيدة لتطوير Java/Java EE

Answer 9

أجد أن CheckStyle و PMD هي الأفضل لتطبيق مشكلات النمط والأخطاء الواضحة البسيطة. على الرغم من أنني وجدت أنني أحب استخدام Eclipse وجميع التحذيرات التي توفرها أفضل لهذا الغرض. نحن نفرض الأشياء باستخدام التفضيلات المشتركة ووضع علامة عليها كخطايا فعلية. وبهذه الطريقة ، لم يتم فحصهم أبدًا في المقام الأول.

ما أود أن أوصي به بقوة وحماس هو استخدام FindBugs. لأنه يعمل على مستوى Bytecode ، يمكنه التحقق من الأشياء المستحيلة على مستوى المصدر. في حين أنه يبصق حصته العادلة من السكرات ، فقد وجد العديد من الأخطاء الفعلية والهامة في الكود لدينا.

Answer 10

كلتا الأداة قابلة للتكوين ويمكن أن تفعل نفس الأشياء تقريبًا. ومع ذلك ، إذا كنا نتحدث عن الأشياء خارج الصندوق ، فهناك قدر كبير من التداخل ، ولكن هناك قواعد/شيكات متميزة أيضًا. على سبيل المثال ، يتمتع CheckStyle بدعم أقوى للتحقق من Javadoc وإيجاد أرقام سحرية ، على سبيل المثال لا الحصر. بالإضافة إلى ذلك ، يحتوي CheckStyle على ميزة "التحكم في الاستيراد" تشبه وظائف Macker (لم أستخدم Macker).

إذا كانت هناك أشياء مهمة بالنسبة لك أن CheckStyle لا تتجاوز الصندوق الذي لا يقوم به PMD ، فقد تفكر في تكوين الحد الأدنى من الفحص مع تلك الشيكات فقط. ثم ضع سياسة لا يمكن أن ينمو تكوين CheckStyle ، ما عليك سوى إزالة الشيكات أثناء تنفيذ وظائف مماثلة مع قواعد PMD المخصصة.

ضع في اعتبارك أيضًا أنه إذا قررت أن ميزة CheckStyle "تحكم الاستيراد" تغطي ما تريده من Macker ، فيمكنك تنفيذ PMD/CheckStyle بدلاً من PMD/Macker. في كلتا الحالتين ، هناك أداتان ، ولكن مع CheckStyle ، ستحصل على الأشياء التي لا تقوم بها PMD خارج الصندوق "مجانًا".

Answer 11

نقطة واحدة لم أرها حتى الآن هي أن هناك مكونات إضافية لـ IDEs من شأنها أن تنفذ قواعد الفحص على الكود الخاص بك ، في حين أن PMD Plugins ستقوم فقط بالإبلاغ عن الانتهاكات. على سبيل المثال ، في مشروع متعدد المواقع على العديد من فرق البرمجة ، من المهم إنفاذ المعايير بنشاط ، بدلاً من مجرد الإبلاغ عنها.

تحتوي كلتا الأدوات على ملحقات مكون من intellij و NetBeans و Eclipse (في رأيي ، يغطي هذا الاستخدام). أنا لست على دراية بـ NetBeans ، لذلك لا يمكنني التعليق إلا على Intellij و Eclipse.

على أي حال ، فإن الإضافات PMD لـ Intellij و Eclipse ، ستنشئ تقارير على الطلب على انتهاكات PMD داخل قاعدة كود المشروع.

من ناحية أخرى ، ستسلط المكونات الإضافية لـ CheckStyle الضوء على الانتهاكات أثناء الطيران ، ويمكن (على الأقل بالنسبة إلى Intellij ، أن يتم تكوين خبرة أقل في Eclipse) لتحويل بعض المشكلات تلقائيًا (على سبيل المثال لـ "OneStatemperline". بين العبارات ، بالنسبة لـ "Nearbraces" ، ستضيف الأقواس التي تكون فيها مفقودة ، وما إلى ذلك). من الواضح أنه لا يمكن إصلاح الانتهاكات الأكثر بساطة تلقائيًا ، لكنها لا تزال مساعدة في المشاريع القديمة ، أو المشاريع الموجودة في عدة مواقع.

"بناء على الطلب" على PMD يعني أنه يجب على المطور أن يقرر بوعي تشغيل التقرير. في حين يتم الإبلاغ عن انتهاكات الفحص تلقائيًا أثناء تطورها. بينما PMD يفعل تحتوي على مجموعة قواعد أكثر شمولاً ، في رأيي ، إن التنفيذ التلقائي/الإبلاغ عن الانتهاكات في IDES يستحق متاعب الحفاظ على مجموعتين من القواعد.

لذلك بالنسبة لأي مشاريع أعمل عليها ، نستخدم كلا الأدوات ، وفرض الفحص في IDE ، وذكرت PMD في IDE ، و على حد سواء تم الإبلاغ عنها وقياسها في التصميم (من خلال جنكينز).

Answer 12

وبعد 10 سنوات ... في عام 2018 ، أستخدم جميعهم CheckStyle و PMD و FindBugs.

أبدا ب FindBugs. ربما أضف PMD و CheckStyle لاحقًا.

لا تنفذ بشكل أعمى القواعد الافتراضية !

خطوات:

• قم بتشغيل أداة واحدة ذات قواعد افتراضية في مشروع يحتوي على الكثير من التعليمات البرمجية
• تكييف القواعد مع هذا المشروع ، والتعليق على قواعد عديمة الفائدة مع بعض الملاحظات
• ركز على قواعد الفواكه المنخفضة المعلقة (NPE ، فحص المسجل ، شيكات الموارد غير المغلفة ، ...)
• قم بإجراء بعض الإصلاحات للقواعد التي تجدها جديرة بالاهتمام (واحد في وقت واحد!)
• افعل هذا لكل أداة ولكن ليس كل مرة!
• كرر هذه العملية

من الناحية المثالية ، يمكن أن يكون لكل مشروع قواعد منفصلة. أحب تشغيل القواعد عبر البناء (عبر مكونات Maven) وفشل في أخطاء القاعدة بمجرد أن أعرف أن المشروع يمرر جميع القواعد التي حددتها. هذا يجبر المطورين على اتخاذ إجراءات ، لأن الإبلاغ لا يكفي. من هذه النقطة على مشروعك ، يعد دليل الرصاص إلى حد كبير ويمكنك حتى إضافة المزيد من القواعد لاحقًا و/أو كتابة قواعد مخصصة.

Answer 13

ألق نظرة على 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>

Answer 14

أود أن أردد التعليق على أن PMD هو المنتج الأكثر حداثة لفحص نمط Java/الاتفاقية. فيما يتعلق بـ FindBugs ، تستخدم العديد من مجموعات التطوير التجارية التغطية.

Answer 15

لقد بدأت للتو في استخدام CheckStyle و PMD. بالنسبة لي ، يكون PMD أسهل في إنشاء قواعد مخصصة لأشياء ، سواء أكان ما إذا كان هناك System.gc () و Runtime.gc () ، طالما يمكنك كتابة استعلام Xpath الذي ليس صعبًا على الإطلاق. ومع ذلك ، لم يظهر لي PMD أن لديها الميزة لإظهار رقم العمود. لذلك لأشياء مثل حدود عمود الفحص. قد ترغب في استخدام CheckStyle.

Answer 16

PMD هو ما أجد المزيد من الناس يشيرون إليه. كان CheckStyle ما كان يشير إليه الناس قبل 4 سنوات ، لكنني أعتقد أن PMD يتم الحفاظ عليها بشكل مستمر وما هي الإضافات/الإضافات الأخرى التي تختار العمل معها.

Answer 17

PMD هي أرقى أداة عند مقارنة مع اختلال الفحص. قد لا يكون لدى CheckStyles القدرة على تحليل الرمز بينما يقدم PMD العديد من الميزات للقيام بذلك! لم يصدر Offcourse PMD قواعد لـ Javadoc ، والتعليقات ، والمسافات البادئة ، وما إلى ذلك ، وبالمناسبة أخطط لتنفيذ هذه القواعد ....... Thanx