विरासत सी/सी ++ परियोजना

Question

में मृत कोड पहचान सी/सी ++ कोड में आप मृत कोड पहचान के बारे में कैसे जाएंगे? मेरे पास काम करने के लिए एक बहुत बड़ा कोड बेस है और कम से कम 10-15% मृत कोड है। क्या इस क्षेत्र की पहचान करने के लिए कोई यूनिक्स आधारित उपकरण है? कोड के कुछ टुकड़े अभी भी बहुत से प्रीप्रोसेसर का उपयोग करते हैं, स्वचालित प्रक्रिया संभाल सकते हैं?

Answer 1

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

जीसीसी टूलचैन के लिए एक लोकप्रिय उपकरण gcov है, साथ ही ग्राफिकल फ्रंटेंड lcov (http://ltp.sourceforge.net/coverage/lcov.php) के साथ।

यदि आप जीसीसी का उपयोग करते हैं, तो आप gcov समर्थन के साथ संकलित कर सकते हैं, जिसे '--coverage' ध्वज द्वारा सक्षम किया गया है। इसके बाद, अपने जीसीओवी सक्षम निर्माण के साथ अपना एप्लिकेशन चलाएं या अपना टेस्ट सूट चलाएं।

मूल रूप से जीसीसी संकलन के दौरान कुछ अतिरिक्त फाइलों को उत्सर्जित करेगा और एप्लिकेशन चलते समय कुछ कवरेज डेटा भी उत्सर्जित करेगा। आपको इन सभी (.gcdo और .gcda फ़ाइलों) को इकट्ठा करना होगा। मैं यहां पूरी तरह से विस्तार से नहीं जा रहा हूं, लेकिन आपको संभवतया एक सौहार्दपूर्ण तरीके से कवरेज डेटा एकत्र करने के लिए दो पर्यावरण चर सेट करने की आवश्यकता है: GCOV_PREFIX और GCOV_PREFIX_STRIP ...

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

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

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

Answer 2

Bullseye कवरेज टूल सहायता करेगा। हालांकि यह मुफ्त नहीं है।

Answer 3

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

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

मुझे static source code analysis पर एक पृष्ठ मिला जो कई अन्य उपकरणों को भी सूचीबद्ध करता है।

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

Answer 4

इसे जीसीसी के तहत संकलित करें - अविश्वसनीय -code।

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

This CERT advisory lists some other tools for static dead code detection

Answer 5

दोनों Mozilla और Open Office देसी समाधान है।

Answer 6

जी ++ 4.01 -उनरेच करने योग्य-कोड कोड के बारे में चेतावनी देता है जो किसी फ़ंक्शन के भीतर पहुंच योग्य नहीं है, लेकिन अप्रयुक्त कार्यों के बारे में चेतावनी नहीं देता है।

int foo() { 
    return 21; // point a 
} 

int bar() { 
    int a = 7; 
    return a; 
    a += 9; // point b 
    return a; 
} 

int main(int, char **) { 
    return bar(); 
} 

जी ++ 4.01 बिंदु ख के बारे में चेतावनी जारी करेगी, लेकिन foo() (बिंदु एक) के बारे में कुछ भी नहीं कहने भले ही यह इस फाइल में नहीं पहुंचा जा सकता है। यह व्यवहार सही है हालांकि निराशाजनक, क्योंकि एक कंपाइलर यह नहीं जानता कि फ़ंक्शन foo() को किसी अन्य संकलन इकाई में बाहरी घोषित नहीं किया गया है और वहां से आमंत्रित किया गया है; केवल एक लिंकर सुनिश्चित हो सकता है।

Answer 7

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

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

डीएमएस भी विभिन्न प्रकार की बोलीभाषाओं में सी ++ को पार करता है (फरवरी 2014: including MS and GCC versions of C++14 [EDIT Nov 2017: now C++17] संपादित करें) और सभी आवश्यक प्रतीक तालिकाओं का निर्माण करता है। मृत संदर्भों को ट्रैक करना उस बिंदु से सीधा होगा। डीएमएस को भी उन्हें बाहर निकालने के लिए इस्तेमाल किया जा सकता है। http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

Answer 8

देखें केवल सी कोड और यह सोचते हैं कि पूरी परियोजना के स्रोत कोड उपलब्ध है के लिए, मुक्त स्रोत उपकरण Frama-C साथ एक विश्लेषण का शुभारंभ। जीयूआई में लाल रंग प्रदर्शित करने वाले कार्यक्रम का कोई भी विवरण मृत कोड है।

यदि आपके पास "मृत कोड" समस्याएं हैं, तो आपको में भी "अतिरिक्त कोड" को हटाया जा सकता है, कोड निष्पादित किया गया है लेकिन अंतिम परिणाम में योगदान नहीं देता है। इसके लिए आपको I/O फ़ंक्शंस का एक सटीक मॉडलिंग प्रदान करना होगा (आप नहीं चाहते हैं जो कि "स्पेयर" होने पर गणना करने के लिए है जिसे printf पर तर्क के रूप में उपयोग किया जाता है)। Frama-C के पास अतिरिक्त कोड इंगित करने का विकल्प है।