आप अपनी जावा परियोजनाओं के लिए किस कोड विश्लेषण उपकरण का उपयोग करते हैं?

आप अपनी जावा परियोजनाओं पर किस कोड विश्लेषण उपकरण का उपयोग करते हैं?

मुझे सभी प्रकार की दिलचस्पी है

  • स्थैतिक कोड विश्लेषण उपकरण (FindBugs, पीएमडी, और कोई अन्य)
  • कोड कवरेज टूल (कोबर्टुरा, एम्मा, और कोई अन्य)
  • कोई अन्य उपकरण-आधारित टूल
  • कुछ और, अगर मुझे कुछ याद आ रहा है

यदि लागू हो, तो यह भी बताएं कि आप किस टूल का उपयोग करते हैं और यह टूल आपके आईडीई और बिल्ड टूल्स दोनों के साथ कितनी अच्छी तरह एकीकृत होते हैं।

यदि कोई टूल केवल एक विशिष्ट तरीका उपलब्ध है (आईडीई प्लगइन के रूप में, या कहें, एक बिल्ड टूल प्लगइन) कि जानकारी भी ध्यान देने योग्य है।

0
ro fr bn
यूसीडीएक्टर पर भी एक नज़र डालें: ucdetector.org
जोड़ा लेखक Christophe Roussy, स्रोत
उत्परिवर्तन परीक्षण कवरेज के लिए चेकआउट Pitest पर जा रहे हैं।
जोड़ा लेखक mucaho, स्रोत

12 उत्तर

Checkstyle is another one I've used at a previous company... it's mainly for style checking, but it can do some static analysis too. Also, Clover for code coverage, though be aware it is not a free tool.

0
जोड़ा

हम एंट के साथ एकीकृत FindBugs और JDepend का उपयोग करते हैं। हम जुनीट का उपयोग करते हैं लेकिन हम किसी कवरेज टूल का उपयोग नहीं कर रहे हैं।

मैं इसका उपयोग तर्कसंगत अनुप्रयोग डेवलपर (आईडीईई जो मैं जे 2 ईई अनुप्रयोगों को विकसित करने के लिए उपयोग कर रहा हूं) में एकीकृत नहीं कर रहा हूं क्योंकि मुझे लगता है कि जब आप विंडोज कंसोल में javac चलाते हैं तो यह कितना साफ दिखता है। : पी

0
जोड़ा

मैं नए उपकरणों के बारे में जानने के लिए कई उत्तरों की तलाश कर रहा हूं और इस ज्ञान को एक प्रश्न / धागे में समेकित कर रहा हूं, इसलिए मुझे संदेह है कि इस प्रश्न का 1 सच्चा उत्तर होगा।

मेरे अपने प्रश्न का मेरा जवाब यह है कि हम इसका उपयोग करते हैं:

  • सामान्य त्रुटियों को देखने के लिए Findbugs खराब / कोडिंग - मैवेन से चलाएं, और ग्रहण में आसानी से एकीकृत भी
  • हमारे कवरेज रिपोर्ट के लिए कोबर्टुरा - मैवेन से चलाएं

हडसन में एक कार्य-स्कैनर प्लगइन भी है जो आपके TODO और FIXMEs की गिनती प्रदर्शित करेगा, साथ ही यह दिखाएगा कि वे स्रोत फ़ाइलों में कहां हैं।

सभी हमारे मामले में मेवेन 1.x के साथ एकीकृत हैं और हडसन में बंधे हैं, जो चेक-इन के साथ-साथ अतिरिक्त चीजें रात और साप्ताहिक पर भी बनाता है। हडसन प्रवृत्ति हमारे जुनीट परीक्षण, कवरेज, findbugs, साथ ही साथ खुले कार्यों ग्राफ। एक हडसन प्लगइन भी है जो हमारी संकलन चेतावनियों की रिपोर्ट और ग्राफ करता है। हमारे पास हडसन प्लॉट प्लगइन का उपयोग करके समय के साथ प्रदर्शन और स्मृति उपयोग के अपने ग्राफ के साथ कई प्रदर्शन परीक्षण भी हैं।

0
जोड़ा

मैं IntelliJ IDEA में निर्मित स्थिर विश्लेषण का उपयोग करता हूं। सही एकीकरण।

मैं इंटेलिज आईडीईए (ईएमएमए के आधार पर) में निर्मित कोड कवरेज का उपयोग करता हूं। फिर, सही एकीकरण।

यह एकीकृत समाधान विश्वसनीय, शक्तिशाली और उपयोग में आसान है विभिन्न विक्रेताओं के उपकरणों को एकसाथ करने के लिए।

0
जोड़ा

हम FindBugs और चेकस्टाइल के साथ ही कोड कवरेज के लिए क्लॉवर का उपयोग कर रहे हैं।

मुझे लगता है कि आपके विकास का समर्थन करने, किसी प्रकार का स्थिर विश्लेषण होना महत्वपूर्ण है। दुर्भाग्य से यह अभी भी व्यापक रूप से फैलता नहीं है कि ये उपकरण महत्वपूर्ण हैं।

0
जोड़ा

हमारी टीम पीएमडी और कोबर्टुरा का उपयोग करती है, वास्तव में हमारी परियोजनाएं मैवेन प्रोजेक्ट्स हैं और कोड विश्लेषण के लिए प्लग इन शामिल करना बहुत आसान है। असली सवाल विशिष्ट परियोजना के लिए होगा, जिसका विश्लेषण आपको उपयोग करने की ज़रूरत है, मेरी राय यह है कि आप प्रत्येक प्रोजेक्ट के लिए एक ही प्लगइन का उपयोग नहीं कर सकते हैं।

0
जोड़ा

स्थैतिक विश्लेषण उपकरण के लिए मैं अक्सर सीपीडी का उपयोग करता हूं, पीएमडी , FindBugs , और चेकस्टाइल

सीपीडी पीएमडी "प्रतिलिपि / पेस्ट डिटेक्टर" उपकरण है। मैं कुछ समय के लिए पीएमडी का उपयोग कर रहा था इससे पहले कि मैंने "डुप्लिकेट कोड ढूँढना" लिंक पर ध्यान दिया पीएमडी वेब पेज

मैं यह इंगित करना चाहता हूं कि इन उपकरणों को कभी-कभी नियमों के सेट के "आउट ऑफ़ द बॉक्स" से आगे बढ़ाया जा सकता है। और न सिर्फ इसलिए कि वे खुले स्रोत हैं ताकि आप उन्हें फिर से लिख सकें। इनमें से कुछ उपकरण एप्लिकेशन या "हुक" के साथ आते हैं जो उन्हें विस्तारित करने की अनुमति देते हैं। उदाहरण के लिए, पीएमडी "डिजाइनर" टूल के साथ आता है जो आपको नए नियम बनाने की अनुमति देता है। साथ ही, चेकस्टाइल में DescendantToken जांच है जिसमें गुण हैं जो पर्याप्त अनुकूलन की अनुमति देते हैं।

मैं इन उपकरणों को एक एंटी-आधारित बिल्ड के साथ एकीकृत करता हूं । आप मेरी टिप्पणी कॉन्फ़िगरेशन देखने के लिए लिंक का अनुसरण कर सकते हैं।

निर्माण में सरल एकीकरण के अलावा, मुझे कुछ अन्य तरीकों से कुछ हद तक "एकीकृत" होने के लिए टूल को कॉन्फ़िगर करना उपयोगी लगता है। अर्थात्, रिपोर्ट पीढ़ी और चेतावनी दमन एकरूपता। मैं इन पहलुओं को इस चर्चा में जोड़ना चाहता हूं (जिसमें शायद "स्थैतिक-विश्लेषण" टैग भी होना चाहिए): "एकीकृत" समाधान बनाने के लिए इन उपकरणों को कॉन्फ़िगर करने वाले लोग कैसे हैं? (मैंने इस सवाल को अलग से यहां पूछा है)

सबसे पहले, चेतावनी रिपोर्ट के लिए, मैं आउटपुट को बदलता हूं ताकि प्रत्येक चेतावनी में सरल प्रारूप हो:

/absolute-path/filename:line-number:column-number: warning(tool-name): message

इसे अक्सर "Emacs प्रारूप" कहा जाता है, लेकिन यदि आप Emacs का उपयोग नहीं कर रहे हैं, तो यह homogenizing रिपोर्ट के लिए एक उचित प्रारूप है। उदाहरण के लिए:

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

मेरी चेतावनी प्रारूप परिवर्तन मेरी एंटी स्क्रिप्ट द्वारा एंटी फ़िल्टरचेन्स के साथ किया जाता है।

दूसरा "एकीकरण" जो मैं करता हूं चेतावनी दमन के लिए है। डिफ़ॉल्ट रूप से, प्रत्येक उपकरण टिप्पणियों या एनोटेशन (या दोनों) का समर्थन करता है जिसे आप अपने कोड में रख सकते हैं ताकि आप जिस चेतावनी को अनदेखा करना चाहते हैं उसे चुप कर सकें। लेकिन इन विभिन्न चेतावनी दमन अनुरोधों में लगातार दिखने वाला नहीं है जो कुछ मूर्खतापूर्ण लगता है। जब आप किसी चेतावनी को दबा रहे हों, तो आप एक चेतावनी दबा रहे हैं, तो हमेशा " SuppressWarning क्यों नहीं लिखते?"

उदाहरण के लिए, पीएमडी की डिफ़ॉल्ट कॉन्फ़िगरेशन एक टिप्पणी में " NOPMD " स्ट्रिंग के साथ कोड की पंक्तियों पर चेतावनी पीढ़ी को दबाती है। इसके अलावा, पीएमडी जावा के <�कोड> @SuppressWarnings एनोटेशन का समर्थन करता है। मैं पीएमडी को NOPMD के बजाय " SuppressWarning (PMD। " युक्त टिप्पणियों का उपयोग करने के लिए कॉन्फ़िगर करता हूं ताकि पीएमडी दमन समान दिखें। मैं उस विशेष नियम को भरता हूं जिसका उपयोग टिप्पणी करते समय उल्लंघन किया जाता है शैली दमन:

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

केवल एक टिप्पणी के लिए " SuppressWarnings (PMD। " भाग महत्वपूर्ण है, लेकिन यह @SuppressWarning एनोटेशन के लिए पीएमडी के समर्थन के अनुरूप है जो नाम से व्यक्तिगत नियम उल्लंघन को पहचानता है:

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

Similarly, Checkstyle suppresses warning generation between pairs of comments (no annotation support is provided). By default, comments to turn Checkstyle off and on contain the strings CHECKSTYLE:OFF and CHECKSTYLE:ON, respectively. Changing this configuration (with Checkstyle's "SuppressionCommentFilter") to use the strings "BEGIN SuppressWarnings(CheckStyle." and "END SuppressWarnings(CheckStyle." makes the controls look more like PMD:

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)

चेकस्टाइल टिप्पणियों के साथ, विशेष चेक उल्लंघन ( HiddenField ) महत्वपूर्ण है क्योंकि प्रत्येक चेक का अपना " BEGIN / END " टिप्पणी जोड़ी है।

FindBugs एक @SuppressWarnings एनोटेशन के साथ चेतावनी पीढ़ी दमन का भी समर्थन करता है, इसलिए अन्य टूल्स के साथ कुछ स्तर की समानता प्राप्त करने के लिए कोई और कॉन्फ़िगरेशन आवश्यक नहीं है। दुर्भाग्यवश, Findbugs को कस्टम @SuppressWarnings एनोटेशन का समर्थन करना है क्योंकि अंतर्निहित जावा @SuppressWarnings एनोटेशन में SOURCE प्रतिधारण नीति है जो मजबूत नहीं है कक्षा फ़ाइल में एनोटेशन को बनाए रखने के लिए पर्याप्त है जहां FindBugs को इसकी आवश्यकता है। जावा के @SuppressWarnings एनोटेशन के साथ संघर्ष से बचने के लिए मैं FindBugs चेतावनियों के दमन को पूरी तरह अर्हता प्राप्त करता हूं:

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

ये तकनीकें चीजों को औजारों में उचित रूप से सुसंगत बनाती हैं। ध्यान दें कि प्रत्येक चेतावनी दमन में स्ट्रिंग " SuppressWarnings " होती है, जो पूरे कोड बेस पर सभी उपकरणों के सभी उदाहरण खोजने के लिए एक सरल खोज को चलाने में आसान बनाता है।

0
जोड़ा
वाह, साझा करने के लिए बहुत विस्तृत उत्तर। धन्यवाद। मैं अपने प्रोडक्शन प्रथाओं में अपने प्रथाओं का अनुकरण करने जा रहा हूं।
जोड़ा लेखक Vatsala, स्रोत

मैं कोबर्टुरा, चेकस्टाइल, (ईसीएल) एम्मा और फाइंडबग के संयोजन का उपयोग करता हूं।

EclEmma is an awesome Eclipse plugin that shows the code coverage by coloring the java source in the editor (screenshot) - the coverage is generated by running a JUnit test. This is really useful when you are trying to figure out which lines are covered in a particular class, or if you want to see just which lines are covered by a single test. This is much more user friendly and useful than generating a report and then looking through the report to see which classes have low coverage.

चेकस्टाइल और फाइंडबग ग्रहण प्लगइन भी उपयोगी हैं, वे आपके द्वारा टाइप किए जाने पर संपादक में चेतावनियां उत्पन्न करते हैं।

मेवेन 2 में रिपोर्ट प्लगइन्स हैं जो बिल्ड समय पर रिपोर्ट जेनरेट करने के लिए उपर्युक्त टूल के साथ काम करते हैं। हम समग्र परियोजना रिपोर्ट प्राप्त करने के लिए इसका उपयोग करते हैं, जो अधिक संख्या में जब आप अधिक उपयोगी होते हैं। ये हमारे सीआई बिल्ड द्वारा उत्पन्न होते हैं, जो Continuum का उपयोग करके चलाए जाते हैं।

0
जोड़ा
वाह @ EclEmma! मैं एम्मा के बारे में जानता था, लेकिन ग्रहण में एकीकृत एकीकृत? वह नियम
जोड़ा लेखक Joshua McKinnon, स्रोत
कंटिन्यूम बेकार है, हडसन नियम।
जोड़ा लेखक Ken Liu, स्रोत

निम्नलिखित में से हम अपने मैवेन 2.x बिल्ड और ग्रहण / आरएडी 7 दोनों में ईज़ी का उपयोग और एकीकृत करते हैं:

  • परीक्षण - जुनीट / टेस्टएनजी
  • कोड विश्लेषण - FindBugs, पीएमडी
  • कोड कवरेज - क्लॉवर

इसके अलावा, हमारे मेवेन में हमारे पास है:

  • JDepend
  • टैग चेकर (TODO, FIXME, आदि)

इसके अलावा, यदि आप मेवेन 2.x का उपयोग कर रहे हैं, तो कोडहॉस में उनके Mojo प्रोजेक्ट <�में आसान मैवेन प्लगइन का संग्रह है। / a>।

नोट: बांस सीआई सर्वर के साथ क्लॉवर के बाहर बॉक्स ऑफिस एकीकरण है (क्योंकि वे दोनों एटलसियन उत्पाद हैं)। FindBugs, पीएमडी, और चेक स्टाइल के लिए बांस प्लगइन्स भी हैं, लेकिन जैसा कि ध्यान दिया गया है, मुफ्त हडसन सीआई सर्वर में भी वे हैं।

0
जोड़ा

मुझे कोबर्टुरा के साथ शुभकामनाएं मिली हैं। यह एक कोड कवरेज टूल है जिसे आपके सामान्य निर्माण के हिस्से के रूप में आपकी चींटी स्क्रिप्ट के माध्यम से निष्पादित किया जा सकता है और इसे हडसन में एकीकृत किया जा सकता है।

0
जोड़ा

हमारी परियोजना में हम सोनार का उपयोग चेकस्टाइल के सामने करते हैं, पीएमडी .... सीआई (बांस, हडसन) के साथ हम अपने स्रोत की गुणवत्ता का एक अच्छा इतिहास भी प्राप्त करते हैं और हम क्या निर्देश देते हैं। मैं सोनार की तरह करता हूं, क्योंकि आप सीआई स्टैक में एक केंद्रीय उपकरण है जो आपके लिए करता है, और आप प्रत्येक प्रोजेक्ट के नियमों को आसानी से अनुकूलित कर सकते हैं।

0
जोड़ा

Structure 101 is good at code analysis and finding the cyclic package dependencies.

0
जोड़ा