साइक्लोमैटिक जटिलता एक विधि के लिए महत्वपूर्ण क्यों है?


10

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

सोनारलिंट को 10 के सीसी के रूप में स्वीकार्य माना जाता है, और कुछ मामले हैं जहां मैं इसके परे हूं, लगभग 5 या 6 इकाइयां। वे भाग मैपर से संबंधित हैं जहाँ मान भिन्न चर पर निर्भर करते हैं, उदाहरण के लिए:

  • फ़ील्ड A स्ट्रिंग sA पर निर्भर करता है;
  • फ़ील्ड बी स्ट्रिंग एसबी पर निर्भर करता है;
  • फ़ील्ड सी स्ट्रिंग स्ट्रिंग पर निर्भर करता है;
  • आदि ...

मेरे पास कोई दूसरा विकल्प नहीं है कि मैं ifहर क्षेत्र के लिए कुछ करूं । यह मेरी पसंद नहीं है (सौभाग्य से) लेकिन पहले से ही विद्यमान और जटिल प्रणाली जिसे मैं स्वयं नहीं बदल सकता।


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

(छोटी गलतियों के लिए क्षमा करें, यदि कोई हो)।


संपादित करें

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

हालाँकि दूसरा लिंक ( एंटी-पैटर्न के बारे में ) बहुत मदद करता है।




^ ^ ^ ^ "एरो हेड" सवाल शायद इस अर्थ में एक बेहतर डुप्लिकेट है कि यह बताता है कि आपके कोड को कैसे सुधारना है लेकिन मैंने विस्तृत विवरण के कारण पहले एक को चुना है जो आपके प्रश्न के भाग के बारे में सायक्लोमैटिक जटिलता के बारे में उत्तर दे रहा है
gnat

एक विधि को छोटे भागों में विभाजित करने से निष्पादित कोड की कुल मात्रा कम नहीं होती है, लेकिन जो व्यक्तिगत कार्य हो रहे हैं, उन्हें सरल बनाता है; जब वे एक बड़े पूरे में उलझ रहे हैं तो वे व्यक्तिगत रूप से बहुत आसानी से समझा जा सकता है। बहुत कम से कम यह कई एक-बार-उपयोग, मध्यवर्ती चर को बड़े दायरे से हटा देता है।
डोभाल

1
आपके विशेष वर्णित मामले के लिए, मैं आपकी प्राथमिक विधि में कुछ करूँगा जैसे "A = extractAFrom (sA);" प्रत्येक क्षेत्र के लिए। आप शायद बेहतर नामों के साथ आ सकते हैं क्योंकि आप वास्तविक क्षेत्रों और उनके उपयोगों को जानते हैं।
टिन मैन

जवाबों:


32

यहाँ मुख्य बात: "मस्तिष्क की क्षमता"।

आप देखते हैं, कोड का एक मुख्य कार्य है ... पढ़ा जाना । और कोड को पढ़ना और समझना आसान हो सकता है; या कठिन है।

और एक उच्च सीसी होने का तात्पर्य एक विधि के भीतर बहुत सारे "स्तर" से है। और इसका मतलब है: आप, एक मानव पाठक के रूप में उस पद्धति को समझने में कठिन समय होगा ।

जब आप स्रोत कोड पढ़ते हैं, तो आपका मस्तिष्क स्वचालित रूप से चीजों को परिप्रेक्ष्य में रखने की कोशिश करता है: दूसरे शब्दों में - यह "संदर्भ" का कुछ रूप बनाने की कोशिश करता है।

और जब आपके पास एक छोटी विधि (एक अच्छे नाम के साथ) होती है जिसमें केवल कुछ लाइनें होती हैं, और बहुत कम सीसी; तब आपका मस्तिष्क आसानी से इस "ब्लॉक" को स्वीकार कर सकता है। आप इसे पढ़ते हैं, आप इसे समझते हैं; किया हुआ।

दूसरी ओर, यदि आपके कोड में उच्च सीसी है, तो आपका मस्तिष्क कई "चक्र" अधिक खर्च करेगा जो कि चल रहा है।

यह कहने का एक और तरीका है: आपको हमेशा जटिल चीजों के सरल नेटवर्क पर सरल चीजों के एक जटिल नेटवर्क को प्राथमिकता देने की ओर झुकना चाहिए । क्योंकि आपका दिमाग छोटी चीजों को समझने में बेहतर है।


9
तो मूल रूप से यह तकनीकी मुद्दों के बारे में नहीं है , बल्कि मानव के बारे में है ? यह लगता है, वास्तव में, चतुर की तरह, मुझे नहीं पता कि मैंने इसके बारे में पहले कैसे नहीं सोचा था। धन्यवाद !
यासीन बडाचे

4
यदि हां, तो मैं आपको रॉबर्ट मार्टिन द्वारा "क्लीन कोड" हासिल करने के लिए तहे दिल से सलाह देता हूं (आप नेट पर मुफ्त में पीडीएफ पा सकते हैं)। आप देखते हैं, पठनीय कोड बनाना सबसे महत्वपूर्ण है, लेकिन एक अच्छे प्रोग्रामर के गुण को बहुत बार अनदेखा कर दिया जाता है
घोस्टकाट ने मोनिका सी।

@YassineBadache CC भी हर नुक्कड़ और क्रैनी (पूर्ण कवरेज) का परीक्षण करना कठिन बनाता है।
ट्यूलेंस कोर्डोवा


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

6

सीसी, कोड गंध के लिए अंगूठे के अन्य सभी नियमों की तरह, एक अनुमानी है । यह एक असफल-सुरक्षित मानदंड नहीं है जो आपको एक पूर्ण सत्य बताता है। यदि ऐसा होता, तो वाजिब बात यह है कि इस तरह के तरीके भाषा में गैरकानूनी हो सकते हैं और लोगों को दूसरे तरीके से अपने सिरों को हासिल करने के लिए मजबूर करते हैं।

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


2
यदि "फील्डा स्ट्रिंग एसए पर निर्भर करता है" तो ओपी कहता है कि मुझे विश्वास नहीं है कि इसे एक कैलकुलेटफिल्डा (स्ट्रिंग एसए) में स्थानांतरित करना अधिक जटिल कोड बनाता है।
तैमूर

2

संक्षेप में: यह पठनीयता के बारे में है और इसलिए आपके कोड की स्थिरता है।

यदि आपके पास बहुत अधिक (नेस्टेड) ​​के साथ एक लंबी, जटिल विधि है if, तो यह बताना मुश्किल है कि यह वास्तव में क्या करता है। यदि आप कुछ निजी तरीके निकालते हैं और उन्हें सार्थक तरीके से नाम देते हैं, तो यह बहुत आसान है।


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

2

एक विधि का साइक्लोमैटिक जटिलता एक विधि के लिए आवश्यक परीक्षण मामलों की संख्या से संबंधित है। विशेष रूप से, 10 की एक साइक्लोमैटिक जटिलता का मतलब है कि 10 आपके मामलों के लिए कुल शाखा कवरेज के लिए परीक्षण मामलों के लिए ऊपरी सीमा है। यह उन पथों की संख्या से भी संबंधित है जिनका परीक्षण किया जाना चाहिए, किसी भी असंभव पथ को घटाते हैं।

इसके अलावा, मैं अन्य विचारों के लिए अन्य उत्तरों से सहमत हूं - एक डेवलपर की मानसिक क्षमता या संभावित समस्याओं का एक संकेतक या रीफैक्टरिंग या कोड की पठनीयता और रखरखाव की माप


0

CC सिर्फ एक हेयुरिस्टिक है, और एक विशेष स्कोर कितना 'खराब' है यह कई बातों पर निर्भर करता है।

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


0

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

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

हालांकि, यह कोड का संकेत हो सकता है जिसे बनाए रखना मुश्किल होगा। विधि पढ़ते समय, यह देखना आसान है कि आप प्रत्येक मामले के लिए किस कोड पथ पर जाएंगे? यदि आप कोड आधार को अच्छी तरह से नहीं जानते हैं तो क्या आप इस विधि को छोड़ सकते हैं और कोड में संबंधित और आगे की खोज कर रहे हैं? मुझे पता है कि कुछ लोग वर्णनात्मक नामों के साथ बहुत से 1/2 लाइन विधियों में बंटवारे के तरीकों की वकालत करते हैं, लेकिन कभी-कभी मुझे लगता है कि कोड को पढ़ने की तुलना में इसे पढ़ना और भी कठिन है।

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


0

यह नीचे आता है कि कोड में कितना समय लग रहा है (मस्तिष्क चक्र) और यह समझने में कि कोड क्या कर रहा है।

  • 10 लाइन विधि पर विचार करें - संभवतः यह समझने में कुछ मिनट लगें कि यह क्या कर रहा है।
  • 100 लाइन विधि पर विचार करें - संभवतः यह समझने के लिए कि क्या कर रहा है, एक घंटे या उससे अधिक समय लें।
  • 1000 लाइन विधि पर विचार करें - संभवतः एक दिन या उससे अधिक समय लें ताकि समझ सकें कि क्या कर रहा है।

इसके अलावा बड़े तरीकों का परीक्षण करना कठिन है और यह अनुमान लगाना कठिन है कि किस तरह का व्यवहार हो सकता है।

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

एक और बात पर विचार करना जटिल कोड को अद्यतन कर रहा है। विश्लेषण करते समय, एक डेवलपर यह रिपोर्ट कर सकता है कि यह जटिलता को देखते हुए कोड को बदलना कम या ज्यादा जोखिम भरा है।

इसलिए, जटिलता को मापने के लिए बहुत सारे मूल्य हैं जो निर्णय लेने के उद्देश्यों के लिए उपयोग किए जा सकते हैं और उपयोग किए जा सकते हैं।


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