मेरे कोड की 'साइक्लोमैटिक जटिलता' का क्या अर्थ है?

Question

मैं कोड के स्थैतिक विश्लेषण के लिए नया हूं। मेरे आवेदन में 17,754 की एक चक्रीय जटिलता है। आवेदन स्वयं कोड की केवल 37,672 लाइनें हैं। क्या यह कहना मान्य है कि कोड की तर्ज पर जटिलता अधिक है? वास्तव में साइक्लोमैटिक जटिलता मुझे क्या कह रही है?

Comments

यह पूरी तरह से इस बात पर निर्भर करता है कि आप क्या कर रहे हैं। यदि आप कुछ सरल करने की कोशिश कर रहे हैं, तो यह बहुत, बहुत अधिक है। उदाहरण के लिए, आपके पास "हैलो वर्ल्ड" में वह अनुपात नहीं होना चाहिए।

— cwallenpoole

Answer 1

वास्तव में साइक्लोमैटिक जटिलता मुझे क्या कह रही है?

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

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

मेरे आवेदन में कोड की 17,754 लाइनों का एक चक्रीय जटिलता है। आवेदन स्वयं कोड की केवल 37,672 लाइनें हैं। क्या यह कहना मान्य है कि कोड की लाइनों के आधार पर जटिलता अधिक है?

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

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

Answer 2

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

संख्या पद्धति के स्तर पर उपयोगी है। उच्च स्तर पर यह सिर्फ एक संख्या है।

17,754 की संख्या परियोजना स्तर की जटिलता (कुल कोड) को इंगित करती है, जिसका इतना अर्थ नहीं है।

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

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

सामान्य तौर पर, विधि स्तर की जटिलता के लिए:

• <10 बनाए रखना आसान
• 11-20 को बनाए रखना मुश्किल
• 21+ उम्मीदवारों के लिए रिफैक्टिंग / रिडिजाइन

यह भी विचार करें कि उच्च जटिलताएं कोड को इकाई परीक्षण के लिए कठिन बनाती हैं।

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

कोशिश करें और सभी तरीकों को 20 से कम रखें और महसूस करें कि किसी भी विधि को कम जटिल बनाने के लिए इसे फिर से तैयार करने की लागत है।

Comments

यह एक बेहतर जवाब है।

— पचेरियर

@Pacerier उस मामले में, बस जवाब को बढ़ा;)।

— Zero3

> "सामान्य तौर पर, विधि स्तर की जटिलता के लिए" प्रशस्ति पत्र?

— बेनी बोटेमा

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

— जॉन

"शाखाओं के तर्क से छुटकारा पाने के लिए एक फैक्ट्री पैटर्न का उपयोग करके CASE स्टेटमेंट को फिर से डिज़ाइन किया जा सकता है।" क्यों? यह तर्क की जटिलता को समाप्त नहीं करता है; यह सिर्फ इसे छुपाता है और इसे कम स्पष्ट करता है, और इस प्रकार इसे बनाए रखना अधिक कठिन होता है।

— मेसन व्हीलर

Answer 3

यह आपके आवेदन में अलग-अलग रास्तों की संख्या है। सीसी पर इस आईबीएम लेख की जाँच करें ।

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

मैंने व्यक्तिगत रूप से बहुत बार पढ़ा है कि 10 से अधिक सीसी वाले तरीकों में दोषों का अधिक जोखिम है।

मैं अपने अनुप्रयोगों की कोड गुणवत्ता का परीक्षण करने के लिए सोनार का उपयोग करता हूं और डिफ़ॉल्ट रूप से मुझे लगता है कि अगर आपके पास +10 CC वाले तरीके हैं तो यह चेतावनी देता है। फिर भी इसका मतलब कुछ भी नहीं हो सकता है। एक ठोस उदाहरण: यदि आप equalsअपने बीन के गुणों के आधार पर एक विधि उत्पन्न करने के लिए ग्रहण का उपयोग करते हैं, तो सीसी बहुत जल्दी छत पर जाएगी ...

Comments

पीएमडी की डिफ़ॉल्ट सेटिंग 10 के एक चक्रीय जटिलता के लिए सतर्क करना है। प्रति-विधि स्तर पर जटिलता को देखते हुए, आप उन तरीकों की अवहेलना कर सकते हैं जो उच्च सीसी के लिए अच्छे कारण हो सकते हैं, जैसे कि उत्पन्न equalsतरीके।

— थॉमस ओवेन्स

मुझे यकीन नहीं था कि मैंने जाँच की थी, लेकिन सोनार आंतरिक रूप से इस उपाय को प्राप्त करने के लिए पीएमडी का उपयोग करता है। तो यह सब समझ में आता है :-)

— Jalayn

Answer 4

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

मैं आपको छिपकली नामक उपकरण का उपयोग करने की सलाह देता हूं और आप संसाधन कोड पा सकते हैं और जीथ फाइल को जीथब पर डाउनलोड कर सकते हैं। यदि आपके कोड में बहुत अधिक गोपनीय जानकारी नहीं है तो इसका एक ऑनलाइन संस्करण भी है।

सार्थक CCN के बारे में आपको किसी अन्य के अलावा किसी फ़ंक्शन बेस पर ध्यान देना चाहिए। इसके अलावा, प्रत्येक फ़ंक्शन का CCN unber रखें 15 आदर्श श्रेणी होगी।