जावा परियोजनाओं में अप्रयुक्त / मृत कोड कैसे खोजें [बंद]


306

बड़े जावा प्रोजेक्ट्स में अप्रयुक्त / मृत कोड को खोजने के लिए आप किन उपकरणों का उपयोग करते हैं? हमारा उत्पाद कुछ वर्षों से विकास में है, और कोड का मैन्युअल रूप से पता लगाना बहुत मुश्किल हो रहा है जो अब उपयोग में नहीं है। हालाँकि हम यथासंभव अप्रयुक्त कोड को हटाने का प्रयास करते हैं।

सामान्य रणनीतियों / तकनीकों (विशिष्ट उपकरणों के अलावा) के सुझावों की भी सराहना की जाती है।

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


16
एक अलग स्रोत के पेड़ में इकाई परीक्षण रखें (आपको वैसे भी होना चाहिए) और कवरेज उपकरण केवल जीवित पेड़ पर चलाएं।
agnul

5
मैं IDEA के "अप्रयुक्त घोषणा" निरीक्षण के साथ शुरू करूंगा और परीक्षण स्रोतों को शामिल नहीं करूंगा । क्या आप स्पष्ट कर सकते हैं कि जब आप आईडिया की "थोड़ी मदद" कहते हैं, तो आपका क्या मतलब है?
डेविड मोल्स

1
मृत कोड खोजने के तरीके: 1) बाहर की किसी चीज से नहीं जुड़ा। 2) रनटाइम में लिंक होने के बावजूद बाहर से उपयोग नहीं किया गया है। 3) लिंक किया गया और कॉल किया गया लेकिन कभी भी मृत चर की तरह उपयोग नहीं किया गया। 4) तार्किक रूप से अगम्य अवस्था। इसलिए लिंकिंग, समय के साथ एक्सेस करना, लॉजिक आधारित, एक्सेस करने के बाद उपयोग करना।
मुहम्मद उमर

यहाँ से IntelliJ Idea और मेरे उत्तर का उपयोग करें: stackoverflow.com/questions/22522013/… :)
BlondCode

डेविड मोल के उत्तर के अलावा: इस उत्तर को देखें stackoverflow.com/a/6587932/1579667
बेंज

जवाबों:


40

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

उदाहरण के लिए यदि आप अप्रयुक्त कक्षाओं में रुचि रखते हैं, तो उदाहरण बनते समय सभी कक्षाओं को लॉग इन करने के लिए इंस्ट्रूमेंट किया जा सकता है। और फिर एक छोटी स्क्रिप्ट इन लॉग की तुलना अप्रयुक्त कक्षाओं को खोजने के लिए कक्षाओं की पूरी सूची के खिलाफ कर सकती है।

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


5
मुझे यह उत्तर पसंद है, लेकिन क्या किसी को यह अंदाजा है कि जावा में ऐसा कैसे किया जाता है, बिना स्पष्ट रूप से हर कक्षा में लॉगिंग को जोड़े बिना? शायद कुछ 'प्रॉक्सी' जादू?
आउटलाव प्रोग्रामर

14
@Outlaw AOP इसके लिए एकदम सही उपयोग का मामला लगता है।
पास्कल थिवेंट

6
यदि आप एप्लिकेशन की क्लास लोडिंग संरचना को समझते हैं, तो आप क्लास लोड घटनाओं को ट्रैक करने के लिए क्लास लोडर पर एओपी का उपयोग कर सकते हैं। यह सभी निर्माणकर्ताओं से पहले सलाह की तुलना में उत्पादन प्रणाली पर कम आक्रामक होगा।
ShabbyDoo

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

4
@ बिलक अधिक चिंतन आपके विचार से होता है। उदाहरण के लिए, कवर सहित स्प्रिंग बहुत सा जादू करता है। आपके विश्लेषण उपकरण का अनुकरण करना चाहिए।
थोरबजोरन रावन एंडरसन

220

एक ग्रहण प्लगइन जो यथोचित रूप से अच्छी तरह से काम करता है, अप्रयुक्त कोड डिटेक्टर है

यह एक पूरी परियोजना, या एक विशिष्ट फ़ाइल को संसाधित करता है और विभिन्न अप्रयुक्त / मृत कोड विधियों को दिखाता है, साथ ही दृश्यता परिवर्तन (यानी एक सार्वजनिक विधि जिसे संरक्षित या निजी किया जा सकता है) का सुझाव देता है।


अच्छा लग रहा है, लेकिन मैं इसे काम करने में सक्षम नहीं था - "संयुक्त राष्ट्र का पता लगाएं ... कोड" कार्रवाई अक्षम है और मुझे इसे सक्षम करने का तरीका नहीं मिला।
ओन्ड्रा kaयूका ४

1
क्या वास्तव में अप्रयुक्त तरीके मिलते हैं, लेकिन यह भी पता चलता है कि मेरे EJB अप्रयुक्त हो रहे हैं (जबकि वे हैं) क्योंकि मैं एक व्यापार प्रतिनिधि पैटर्न डिजाइन का उपयोग कर रहा हूं
Eildosa

क्या यह अभी भी केपलर पर काम करता है? ग्रहण के बारे में कहना 3.8: ucdetector.org/releases.html
Mr_and_Mrs_D

केप्लर पर सही काम करने की स्थिति में लगता है।
एरिक कपलुन

4
क्या आप मार्केटप्लेस marketplace.eclipse.org/content/unn जरूरी- code- detector में एक लिंक जोड़ना चाहते हैं ? इससे प्रश्न को स्थापित करना और उत्तर देना आसान हो जाता है कि क्या यह ग्रहण के नए संस्करणों पर समर्थित है।
थॉमस वेलर

64

कोडप्रो को हाल ही में Google द्वारा ग्रहण परियोजना के साथ जारी किया गया था। यह मुफ़्त और अत्यधिक प्रभावी है। प्लगइन में एक / कई प्रवेश बिंदु के साथ एक ' डेड डेड कोड ' सुविधा है। बहुत अच्छा काम करता है।


1
अब ग्रहण केपलर के साथ काम नहीं करेंगे। अद्यतन साइट के माध्यम से इसे सफलतापूर्वक स्थापित करने के बाद, यह हर बार ग्रहण दुर्घटना बनाता है।
txulu

दुर्भाग्य से, ऐसा लगता है कि यह उपकरण वसंत के अस्तित्व का एहसास नहीं करता है, इसलिए, यह मेरे सभी @ कॉमपर्स को अप्रयुक्त, गलत तरीके से चिह्नित करेगा
क्लिंट ईस्टवुड

बहुत पुराने हो जाओ किसी भी अधिक Last updated this plugin March 27, 2012 डेवलपर्स
http://www.java-dev-tools/download-codepro

2
सभी लिंक पुराने हैं।
जिगिमंटस

3
दुर्भाग्य से ऐसा प्रतीत होता है कि Google ने ग्रहण परियोजना के कोड को डंप कर दिया और इसके बारे में सब भूल गया।
थोरबजोरन रावन एंडरसन

30

मैं आश्चर्यचकित हूँ ProGuard यहाँ उल्लेख नहीं किया गया है। यह सबसे परिपक्व उत्पादों में से एक है।

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

ProGuard के कुछ उपयोग हैं:

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

यहाँ मृत कोड सूची के लिए उदाहरण: https://www.guardsquare.com/en/products/proguard/manual/examples#dodcode


8
नमूना उपयोग प्रदान करने से बेहतर उत्तर मिलेगा।
आरडीएस

1
दस्तावेज़ीकरण को पढ़ते हुए, मैं देखता हूं कि यह अप्रयुक्त कोड को सिकोड़ता है, लेकिन मैं कहीं भी नहीं मिल सकता है जहां यह इसे सूचीबद्ध करता है - सहमत, एक उदाहरण, या प्रलेखन के प्रासंगिक अनुभाग से लिंक, काफी मददगार होगा!
ओर्बफिश

26

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

लेकिन यह बहुत मैनुअल है।


4
हो सकता है कि आदर्श उत्तर नहीं है, लेकिन यह वास्तव में चालाक है।
एरिक रेपेने

8
यह चतुर है ... जब तक कि आपके पास किसी अन्य वर्ग के अप्रयुक्त कोड से कॉल न हो।
दानोसेर

इस विधि पर फेरबदल करने से कोड के विशाल स्वैट्स को हटाया जा सकता है क्योंकि एक बार प्रयोग की जाने वाली विधि दूसरों को हटा देती है।
4myle

15

अपने कोडबेस को इंस्ट्रूमेंट करने के लिए टेस्ट कवरेज टूल का उपयोग करें, फिर एप्लिकेशन को ही चलाएं, टेस्ट को नहीं।

एम्मा और एखम्मा आपको अच्छी रिपोर्ट देंगे कि किसी भी कोड को चलाने के लिए कौन से वर्ग कितने प्रतिशत चलते हैं।


1
+1 यह एक अच्छा शुरुआती बिंदु है, लेकिन ध्यान रखें कि उदाहरण के लिए अप्रयुक्त (अभी तक घोषित) चर हरे रंग में भी आएंगे।
डेरामाइक

13

हमने अपने कोडबस के लक्ष्य-समृद्ध वातावरण में रिफ्लेक्टरिंग के लिए कुछ दुर्गंध को पहचानने में मदद करने के लिए फाइंड बग्स का उपयोग करना शुरू कर दिया है । मैं आपके कोडबेस के आर्किटेक्चर में स्पॉट 101 की पहचान करने के लिए संरचना 101 पर भी विचार करूंगा जो बहुत जटिल हैं, इसलिए आप जानते हैं कि असली दलदल कहां हैं।


4
FindBugs मृत और अप्रयुक्त कोड का पता नहीं लगा सकता, केवल अप्रयुक्त फ़ील्ड। इस जवाब को देखें ।
स्टीफन मूक

12

सिद्धांत रूप में, आप निर्दिष्‍ट रूप से अप्रयुक्त कोड नहीं खोज सकते। Theres इस का एक गणितीय सबूत (ठीक है, यह एक अधिक सामान्य प्रमेय का एक विशेष मामला है)। यदि आप उत्सुक हैं, तो समस्या को हल करें।

यह कई तरह से जावा कोड में खुद को प्रकट कर सकता है:

  • उपयोगकर्ता इनपुट, कॉन्फिग फाइलों, डेटाबेस प्रविष्टियों, आदि के आधार पर लोडिंग कक्षाएं;
  • बाहरी कोड लोड हो रहा है;
  • तीसरे पक्ष के पुस्तकालयों में ऑब्जेक्ट ट्री पास करना;
  • आदि।

यह कहा जा रहा है, मैं अपनी पसंद के IDE के रूप में IDEA IntelliJ का उपयोग करता हूं और इसमें मॉड्यूल, अप्रयुक्त विधियों, अप्रयुक्त सदस्यों, अप्रयुक्त वर्गों, आदि के बीच खोज निर्भरता के लिए व्यापक विश्लेषण उपकरण हैं। यह एक निजी पद्धति की तरह काफी बुद्धिमान है जिसे कहा नहीं जाता है। अप्रयुक्त टैग लेकिन एक सार्वजनिक विधि के लिए अधिक व्यापक विश्लेषण की आवश्यकता होती है।


1
आपके इनपुट के लिए धन्यवाद। हम IntelliJ का उपयोग कर रहे हैं, और वहां कुछ सहायता प्राप्त कर रहे हैं। हॉल्टिंग प्रॉब्लम और अनिर्णयता के रूप में, मैं सिद्धांत से परिचित हूं, लेकिन हम nouldarilly को एक दृढ़ संकल्प समाधान की आवश्यकता नहीं है।
knatten

12
उद्घाटन वाक्य बहुत मजबूत है। हॉल्टिंग समस्या (जैसा कि अक्सर गलत तरीके से / दुर्व्यवहार किया जाता है) के साथ, कोई पूर्ण सामान्य समाधान नहीं है, लेकिन ऐसे बहुत से विशेष मामले हैं जिनका पता लगाना संभव है।
योएल

9
हालांकि, वहाँ के रूप में eval और / या परावर्तन वाली भाषाओं के लिए एक सामान्य समाधान नहीं है, वहाँ बहुत सारे मामले हैं जहां कोड काफी अप्राप्य है।
pjc50

1
प्रतिबिंब के बिना और पूर्ण स्रोत कोड के साथ किसी भी सांख्यिकीय टाइप की गई भाषा को सभी अप्रयुक्त कोड को निर्धारित करने के लिए बहुत आसान बनाना चाहिए।
बिल के

आप प्रतिबिंब या बाहरी कॉलर्स द्वारा पहुंच योग्य साबित नहीं कर सकते हैं, लेकिन आप ऐसे कोड पा सकते हैं जो किसी दिए गए प्रवेश बिंदु या प्रवेश बिंदुओं के सेट से सांख्यिकीय रूप से उपलब्ध होने योग्य हैं
nafg

8

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

स्क्रीनशॉट ग्रहण कोड:

यहां छवि विवरण दर्ज करें


5

IntelliJ में कोड का पता लगाने के लिए कोड विश्लेषण उपकरण हैं जो अप्रयुक्त है। आपको यथासंभव अधिक से अधिक क्षेत्र / विधियाँ / कक्षाएं गैर-सार्वजनिक बनाने की कोशिश करनी चाहिए और यह अधिक अप्रयुक्त तरीकों / क्षेत्रों / वर्गों को दिखाएगी

मैं कोड मात्रा को कम करने के तरीके के रूप में डुप्लिकेट कोड का पता लगाने की कोशिश करूंगा।

मेरा अंतिम सुझाव ओपन सोर्स कोड खोजने की कोशिश है जो अगर इस्तेमाल किया गया तो आपके कोड को सरल बना देगा।


इन साधनों के क्या उदाहरण हैं?
ओर्फ़िश

@orbfish आप चला सकते हैं Analyse=> Run inspection by name=>unused
पीटर लॉरी

5

स्ट्रक्च्योर 101 स्लाइस परिप्रेक्ष्य उन वर्गों या पैकेजों के किसी भी "अनाथ" या "अनाथ समूह " की सूची (और निर्भरता ग्राफ) देगा, जिनके पास या "मुख्य" क्लस्टर से कोई निर्भरता नहीं है।


क्या यह वर्ग के भीतर उदाहरण चर / विधियों के लिए काम करता है?
जोएब्लैकदेव

मुझे कैसे पता चलेगा कि यह उदाहरण ४.२ के साथ काम करना है या नहीं?
एरिक कपलुन

3

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

PS जैसा कि नीचे एक टिप्पणी में उल्लेख किया गया है, परियोजना अब GitHub में रहती है


यह एक टिप्पणी के रूप में नीचे जाना चाहिए जवाब नहीं
गिनती

कृपया अपने विवरण को हटाने के लिए अपना उत्तर अपडेट करें कि DCD "अब मृत दिख रहा है"। संस्करण 2.1 को 12 दिन पहले जारी किया गया था । इसके अलावा, आपके उत्तर में लिंक काम नहीं करता है।
स्कोमीसा

2

ऐसे उपकरण हैं जो कोड प्रोफ़ाइल करते हैं और कोड कवरेज डेटा प्रदान करते हैं। यह आपको देखने देता है (जैसे कोड चलाया जाता है) इसे कितना कहा जा रहा है। आपको यह पता लगाने के लिए इनमें से कोई भी टूल मिल सकता है कि आपके पास कितना अनाथ कोड है।


2
  • FindBugs इस तरह की चीज़ के लिए उत्कृष्ट है।
  • पीएमडी (प्रोजेक्ट मेस डिटेक्टर) एक और उपकरण है जिसका उपयोग किया जा सकता है।

हालांकि, न तो सार्वजनिक स्थैतिक तरीकों को खोज सकते हैं जो किसी कार्यक्षेत्र में अप्रयुक्त हैं। अगर किसी को भी इस तरह के उपकरण का पता है तो कृपया मुझे बताएं।


1

उपयोगकर्ता कवरेज उपकरण, जैसे कि EMMA। लेकिन यह स्थैतिक उपकरण नहीं है (यानी इसे वास्तव में प्रतिगमन परीक्षण के माध्यम से, और सभी संभावित त्रुटि मामलों के माध्यम से आवेदन करना होगा, जो कि, अच्छी तरह से असंभव है :))

फिर भी, EMMA बहुत उपयोगी है।


1

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

हालांकि, यह वास्तविक मृत कोड की पहचान करने जैसा नहीं है। यह केवल परीक्षणों द्वारा कवर किए गए (या कवर नहीं किए गए) कोड की पहचान करता है। यह आपको झूठी सकारात्मकता दे सकता है (यदि आपके परीक्षण सभी परिदृश्यों को कवर नहीं करते हैं) और साथ ही गलत नकारात्मक (यदि आपके परीक्षण एक्सेस कोड जो वास्तव में वास्तविक दुनिया के परिदृश्य में कभी भी उपयोग नहीं किए जाते हैं)।

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

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

मैंने इसे व्यक्तिगत रूप से कभी नहीं देखा है, और यह नहीं जानता कि उपरोक्त उपकरण का उपयोग कैसे किया जा सकता है जो उपकरण और विश्लेषण कोड का उपयोग कर सकते हैं जो कि परीक्षण सूट के माध्यम से नहीं लगाए जा रहे हैं - लेकिन मुझे यकीन है कि वे हो सकते हैं।


1

जावा प्रोजेक्ट है - डेड कोड डिटेक्टर (डीसीडी)। स्रोत कोड के लिए यह अच्छी तरह से काम नहीं करता है, लेकिन .jar फ़ाइल के लिए - यह वास्तव में अच्छा है। इसके अलावा आप वर्ग और विधि से फ़िल्टर कर सकते हैं।


1

Netbeans यहाँ Netbeans मृत कोड डिटेक्टर के लिए एक प्लगइन है ।

यह बेहतर होगा अगर यह अप्रयुक्त कोड को लिंक और हाइलाइट कर सके। आप यहाँ वोट कर सकते हैं और टिप्पणी कर सकते हैं: बग 181458 - अप्रयुक्त सार्वजनिक वर्गों, विधियों, क्षेत्रों का पता लगाएं


0

ग्रहण उस कोड को दिखा / उजागर कर सकता है जिसे पहुँचा नहीं जा सकता। JUnit आपको कोड कवरेज दिखा सकता है, लेकिन आपको कुछ परीक्षणों की आवश्यकता होगी और यह तय करना होगा कि संबंधित परीक्षण गायब है या कोड वास्तव में अप्रयुक्त है।


3
ग्रहण तभी बताएगा कि विधि का दायरा स्थानीय है (अर्थात। निजी); और तब भी आप 100% निश्चित नहीं हो सकते ... प्रतिबिंब के साथ निजी पद्धति को बाहर से बुलाया जा सकता है।
p3t0r

0

मुझे क्लोवर कवरेज टूल मिला जो उपकरण कोड और उपयोग किए गए कोड को हाइलाइट करता है और जो अप्रयुक्त है। Google CodePro Analytics के विपरीत, यह WebApplications (मेरे अनुभव के अनुसार और मैं Google CodePro के बारे में गलत हो सकता है) के लिए भी काम करता है।

एकमात्र दोष जो मैंने देखा है कि यह जावा इंटरफेस को ध्यान में नहीं रखता है।


Afaict, यह एक गैर-मुक्त सर्वर साइड CI उपकरण है।
एरिक कपलून

0

मैं उन तरीकों का पता लगाने के लिए एक विधि कॉल मैप विकसित करने के लिए Doxygen का उपयोग करता हूं जिन्हें कभी नहीं कहा जाता है। ग्राफ़ पर आपको कॉलर्स के बिना विधि समूहों के द्वीप मिलेंगे। यह पुस्तकालयों के लिए काम नहीं करता है क्योंकि आपको हमेशा कुछ मुख्य प्रविष्टि बिंदु से शुरू करने की आवश्यकता होती है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.