क्या कोई कस्टम FxCop नियम है जो अप्रयुक्त सार्वजनिक विधियों का पता लगाएगा?

Question

मैंने अभी FxCop की कोशिश की। यह अप्रयुक्त निजी तरीकों का पता लगाता है, लेकिन अप्रयुक्त सार्वजनिक नहीं है। क्या कोई कस्टम नियम है जिसे मैं डाउनलोड कर सकता हूं, प्लग-इन जो सार्वजनिक विधियों का पता लगाएगा जिन्हें एक ही असेंबली के भीतर से नहीं कहा जाता है?

Answer 1

NDepend यह कैसे पता होगा कि सार्वजनिक तरीकों अप्रयुक्त हैं बात

Answer 2

इस तरह के लिए अपने दोस्त है?

किसी विधि को सार्वजनिक रूप से चिह्नित करके इसे किसी भी एप्लिकेशन द्वारा एक्सेस किया जा सकता है जो आपकी लाइब्रेरी का संदर्भ देता है।

Answer 3

यदि कोई विधि अप्रयुक्त है और सार्वजनिक FxCop मानता है कि आपने इसे बाहरी चीज़ों तक पहुंचने के लिए सार्वजनिक किया है।

यदि अप्रयुक्त सार्वजनिक विधियां FxCop चेतावनियों को लिखने वाली एपीआई का कारण बनती हैं और जैसे दर्द होता है - तो आप उन तरीकों के लिए FxCop चेतावनियों का भार प्राप्त करेंगे जिन्हें आप दूसरों का उपयोग करना चाहते हैं।

यदि आपको अपनी असेंबली/एक्सई तक पहुंचने के लिए बाहरी कुछ भी नहीं चाहिए तो के साथ public को ढूंढने पर विचार करें। आपका आवेदन वही चलाएगा और FxCop अनियंत्रित आंतरिक तरीकों को ढूंढ पाएगा।

यदि आपको बाहरी पहुंच की आवश्यकता है तो पता लगाएं कि बाहरी होने के लिए वास्तव में कौन सी विधियों की आवश्यकता है, और बाकी सभी आंतरिक बनाते हैं।

आपके द्वारा बाहरी रूप से दिखाई देने वाली किसी भी विधि में यूनिट परीक्षण भी हो सकते हैं।

Answer 4

कोरी, FxCop का उपयोग करने का मेरा जवाब माना गया था कि आप अप्रयुक्त निजी सदस्यों को हटाने में रुचि रखते थे, हालांकि अन्य मामलों के साथ समस्या को हल करने के लिए आप NDepend का उपयोग कर सकते हैं। यहाँ कुछ CQL अप्रयुक्त सार्वजनिक सदस्यों का पता लगाने के (नीचे सूचीबद्ध एक लेख से अनुकूलित) है:

// <Name>Potentially unused methods</Name> 
WARN IF Count > 0 IN SELECT METHODS WHERE 
MethodCa == 0 AND   // Ca=0 -> No Afferent Coupling -> The method 
           // is not used in the context of this 
           // application. 

IsPublic AND     // Check for unused public methods 

!IsEntryPoint AND   // Main() method is not used by-design. 

!IsExplicitInterfaceImpl AND // The IL code never explicitely calls 
           // explicit interface methods implementation. 

!IsClassConstructor AND  // The IL code never explicitely calls class 
           // constructors. 

!IsFinalizer     // The IL code never explicitely calls 
           // finalizers. 

स्रोत: Patrick Smacchia's "Code metrics on Coupling, Dead Code, Design flaws and Re-engineering। लेख मृत क्षेत्रों और प्रकारों का पता लगाने पर भी चला जाता है।

(संपादित करें: अधिक समझ में आता है का जवाब दिया)

---

संपादित 11 वीं जून 2012: अप्रयुक्त कोड के विषय में नई NDepend सुविधाओं के बारे में बताएं। अस्वीकरण: मैं इस उपकरण के डेवलपर में से एक हूं।

चूंकि मई 2012 में एनडीपेन्स वी 4 जारी किया गया था, तो टूल Code Rule over LINQ Query (CQLinq) लिखने का प्रस्ताव रखता है। लगभग 200 default code rules प्रस्ताव है, उनमें से 3 अप्रयुक्त/मृत कोड के लिए समर्पित किया जा रहा का पता लगाने:

• Potentially dead Types (इसलिए का पता लगाने के अप्रयुक्त वर्ग, struct, इंटरफ़ेस, प्रतिनिधि ...)
• Potentially dead Methods (इसलिए का पता लगाने के अप्रयुक्त विधि, ctor, संपत्ति गेटर/सेटर ...)
• Potentially dead Fields

ये CQLinq कोड नियमों को और अधिक पॉव हैं पिछले सीक्यूएल वाले लोगों की तुलना में खराब।यदि आप इन नियमों के स्रोत कोड की ओर उपरोक्त इन 3 लिंक पर क्लिक करते हैं, तो आप देखेंगे कि प्रकार और विधियों से संबंधित कुछ जटिल हैं। ऐसा इसलिए है क्योंकि वे न केवल उपयोग किए गए प्रकारों और विधियों का पता लगाते हैं, बल्कि अप्रयुक्त मृत प्रकारों और विधियों (रिकर्सिव) द्वारा केवल का उपयोग किए जाने वाले प्रकार और विधियों का भी पता लगाते हैं।

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

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