स्थैतिक विश्लेषण उपकरणों के लिए मैं अक्सर सीपीडी, पीएमडी , फाइंडबग्स और चेकस्टाइल का उपयोग करता हूं ।
CPD PMD "कॉपी / पेस्ट डिटेक्टर" टूल है। पीएमडी वेब पेज पर "फाइंडिंग डुप्लिकेट कोड" लिंक पर ध्यान देने से पहले मैं थोड़ी देर के लिए पीएमडी का उपयोग कर रहा था ।
मैं यह बताना चाहता हूं कि इन उपकरणों को कभी-कभी उनके "आउट-ऑफ-द-बॉक्स" नियमों के सेट से आगे बढ़ाया जा सकता है। और सिर्फ इसलिए नहीं कि वे खुले स्रोत हैं ताकि आप उन्हें फिर से लिख सकें। इनमें से कुछ उपकरण अनुप्रयोगों या "हुक" के साथ आते हैं जो उन्हें विस्तारित करने की अनुमति देते हैं। उदाहरण के लिए, पीएमडी "डिजाइनर" टूल के साथ आता है जो आपको नए नियम बनाने की अनुमति देता है। इसके अलावा, चेकस्टाइल में DescendantToken चेक है जिसमें ऐसे गुण हैं जो पर्याप्त अनुकूलन के लिए अनुमति देते हैं।
मैं इन उपकरणों को एक चींटी-आधारित निर्माण के साथ एकीकृत करता हूं । आप मेरी टिप्पणी विन्यास देखने के लिए लिंक का अनुसरण कर सकते हैं।
बिल्ड में सरल एकीकरण के अलावा, मुझे कुछ अन्य तरीकों से कुछ "एकीकृत" होने के लिए उपकरणों को कॉन्फ़िगर करने में मदद मिलती है। अर्थात्, रिपोर्ट जनरेशन और चेतावनी दमन एकरूपता। मैं इस चर्चा में इन पहलुओं को जोड़ना चाहूंगा (जिसमें शायद "स्थैतिक-विश्लेषण" टैग भी होना चाहिए): कैसे लोग "एकीकृत" समाधान बनाने के लिए इन उपकरणों को कॉन्फ़िगर कर रहे हैं? (मैंने यह प्रश्न अलग से यहाँ पूछा है )
पहले, चेतावनी रिपोर्टों के लिए, मैं आउटपुट को परिवर्तित करता हूं ताकि प्रत्येक चेतावनी का सरल प्रारूप हो:
/absolute-path/filename:line-number:column-number: warning(tool-name): message
इसे अक्सर "Emacs प्रारूप" कहा जाता है, लेकिन भले ही आप Emacs का उपयोग नहीं कर रहे हों, यह रिपोर्ट को समरूप बनाने के लिए एक उचित प्रारूप है। उदाहरण के लिए:
/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.
मेरा चेतावनी प्रारूप रूपांतरण चींटी फ़िल्टरचैन के साथ मेरी चींटी स्क्रिप्ट द्वारा किया जाता है ।
दूसरा "एकीकरण" जो मैं करता हूं वह चेतावनी दमन के लिए है। डिफ़ॉल्ट रूप से, प्रत्येक उपकरण टिप्पणियों या एक एनोटेशन (या दोनों) का समर्थन करता है जिसे आप अपने कोड में एक चेतावनी को चुप कराने के लिए रख सकते हैं जिसे आप अनदेखा करना चाहते हैं। लेकिन इन विभिन्न चेतावनी दमन अनुरोधों में एक सुसंगत रूप नहीं है जो कुछ मूर्खतापूर्ण लगता है। जब आप एक चेतावनी को दबा रहे हैं, तो आप एक चेतावनी को दबा रहे हैं, इसलिए हमेशा "क्यों नहीं SuppressWarning?"
उदाहरण के लिए, पीएमडी का डिफ़ॉल्ट कॉन्फ़िगरेशन NOPMDएक टिप्पणी में स्ट्रिंग " " के साथ कोड की तर्ज पर चेतावनी उत्पादन को दबा देता है। इसके अलावा, पीएमडी जावा के @SuppressWarningsएनोटेशन का समर्थन करता है । मैं पीएमडी को कॉन्फ़िगर करता हूं ताकि टिप्पणियों का उपयोग SuppressWarning(PMD.किया जा सके, NOPMDताकि पीएमडी शमन एक जैसे दिखें। मैं उस विशेष नियम को भरता हूं जिसमें टिप्पणी शैली के दमन का उपयोग करते समय उल्लंघन किया जाता है:
// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained
केवल " SuppressWarnings(PMD." भाग एक टिप्पणी के लिए महत्वपूर्ण है, लेकिन यह @SuppressWarningएनोटेशन के लिए पीएमडी के समर्थन के अनुरूप है जो नाम से व्यक्तिगत नियम उल्लंघन को पहचानता है:
@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended
इसी तरह, चेकस्टाइल टिप्पणियों के जोड़े के बीच चेतावनी उत्पादन को दबा देता है (कोई एनोटेशन समर्थन प्रदान नहीं किया जाता है)। डिफ़ॉल्ट रूप से, चेकस्टाइल को बंद करने के लिए टिप्पणियां CHECKSTYLE:OFFऔर CHECKSTYLE:ONक्रमशः तार और होते हैं। इस कॉन्फ़िगरेशन को बदलना (चेकस्टाइल के "SuppressionCommentFilter") के साथ स्ट्रिंग्स का उपयोग करने के लिए " BEGIN SuppressWarnings(CheckStyle." और " END SuppressWarnings(CheckStyle." नियंत्रण को पीएमडी की तरह दिखता है:
// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)
Checkstyle टिप्पणियों के साथ, विशेष रूप से जांच उल्लंघन ( HiddenField) है महत्वपूर्ण है क्योंकि प्रत्येक चेक अपने स्वयं के "है BEGIN/END" टिप्पणी जोड़ी।
फाइंडबग्स एक @SuppressWarningsएनोटेशन के साथ चेतावनी पीढ़ी के दमन का भी समर्थन करता है , इसलिए अन्य उपकरणों के साथ एकरूपता के कुछ स्तर को प्राप्त करने के लिए और अधिक कॉन्फ़िगरेशन की आवश्यकता नहीं है। दुर्भाग्य से, फाइंडबग्स को एक कस्टम @SuppressWarningsएनोटेशन का समर्थन करना पड़ता है क्योंकि अंतर्निहित जावा @SuppressWarningsएनोटेशन में एक SOURCEअवधारण नीति होती है जो क्लास फाइल में एनोटेशन को बनाए रखने के लिए पर्याप्त मजबूत नहीं होती है जहां फाइंडबग्स को इसकी आवश्यकता होती है। मैं Java के @SuppressWarningsएनोटेशन के साथ टकराव से बचने के लिए FindBugs चेतावनियों को पूरी तरह से योग्य बनाता हूं :
@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")
ये तकनीक चीजों को औजारों के पार सुसंगत बनाती है। ध्यान दें कि प्रत्येक चेतावनी दमन में स्ट्रिंग होती है " SuppressWarnings" संपूर्ण कोड आधार पर सभी उपकरणों के सभी उदाहरणों को खोजने के लिए एक सरल खोज को चलाना आसान बनाता है।