क्या LINQ और Lambda अभिव्यक्ति चक्रवात-जटिलता को कम करती है? बस उत्सुक है क्योंकि वीएस विश्लेषक इसे बढ़ाते समय कोडरश वास्तव में सीसी में कमी दिखाता है।क्या LINQ और Lambda अभिव्यक्ति साइक्लोमैटिक-जटिलता को कम करती है?
मुझे संदेह है कि विसंगति निष्पादित निष्पादन के कारण हो सकती है। जब आप लैम्ब्डा अभिव्यक्तियों के साथ LINQ का उपयोग करते हैं, तो आप कोड निर्दिष्ट कर रहे हैं जो चलाएगा यदि आप संग्रह पर फिर से प्रयास करते हैं।
व्यक्तिगत रूप से मैं चक्रवात जटिलता के बारे में इतना चिंतित नहीं हूं, लेकिन मुझे पूरा यकीन है कि (जब उचित तरीके से उपयोग किया जाता है) LINQ पठनीयता में सुधार करता है। यही है कि मैं वास्तव में के बारे में परवाह करता हूं :)
मैं अभी भी एक ही प्रश्न के साथ आया था और वास्तव में, लैम्ब्डा चक्रवात जटिलता को बढ़ा सकता है। मैंने परीक्षण किया और कहां() खंड इसे समझदारी से बढ़ा सकते हैं।
पठनीयता वास्तव में आपकी शीर्ष प्राथमिकताओं में से एक है।
लेकिन मुझे कुछ LinQ प्रश्नों को गेट() विधियों से प्रतिस्थापित करने में लंबा समय नहीं लगा, जो मुझे एक ही डेटा और अतिरिक्त लाभ प्रदान करता था।
मैं अपने निर्माण में पर मेरी FxCop रखने/स्क्रिप्ट प्रकाशित तो मैं cyclomatic जटिलता के लिए 25 के लक्ष्य तक पहुँचने के बिना कुछ तैनात कभी नहीं।
यह कठिन है, लेकिन मुझे लगता है कि यह प्रयास के लायक है।
यह मुझे कुछ बिंदुओं पर चर्चा करता है जब मेरे साथी बहुत बुरे कोड के साथ आते हैं: यह काम करता है, यही मायने रखता है।
मेरी टिप है: नीचे 25 यह आपके cyclomatic जटिलता रखना आप हर विधि अच्छा रखरखाव के लिए काफी सरल रखने में मदद कर सकते हैं।
जॉन स्कीट ने काफी सवाल का जवाब दिया। मैं यह जोड़ना चाहता हूं कि सी # जैसे उच्च स्तरीय भाषाओं के साथ अपने अनुभव में, चक्रवात जटिलता को मापने का मूल्य कम हो गया है क्योंकि सिंटैक्टिक चीनी पैकेज जैसे LINQ विकास में जोड़ता है।
पिछले दस वर्षों में, जैसे भाषाओं ने विकसित किया है, नेट पर कई ने चक्रवात जटिलता और कोड की रेखाओं के बीच एक मजबूत सहसंबंध दिखाया है, जिससे उनमें से कई सवाल करते हैं कि वास्तव में इस तरह के उपाय कितने मूल्य लाते हैं। इसे देखने का एक और तरीका यह होगा कि कोड की गुणवत्ता के उपाय के रूप में सीसी का अवमूल्यन वास्तव में पठनीयता के महत्व का दावा है, क्योंकि एक अक्सर दूसरे के विपरीत होता है।
उदाहरण के लिए, यदि मैं फ़ोरैच लूप के अंदर सशर्त डालता हूं, तो सशर्त का मूल्यांकन मेरे कोड के रूप में किया जाता है, और कोड पथ की उचित संख्या गिना जाता है। दूसरी तरफ, यदि मैं संग्रह में फ़ंक्शन पेड़ लागू करता हूं, तो मैं इसे फिर से चालू कर रहा हूं (उदाहरण के लिए कहां (evalStr => evalStr == origStr) मैं लूप के बाहर और संकलक-जेनरेट कोड में सशर्त स्थानांतरित कर रहा हूं। अभी भी शाखाओं की एक ही संख्या है, हालांकि सशर्त लूप का हिस्सा नहीं हैं, फिर भी सीसी वास्तविक शाखा गिनती के शीर्ष पर अनाम विधियों (लैम्ब्डा और प्रतिनिधियों) का उपयोग करने के लिए "दंड" के साथ फोरैच लूप के आगे बढ़ जाती है। जहां फ़ंक्शन मुझे पुनरावृत्त संग्रह को पूर्व शर्त देता है ताकि लूप केवल तभी पुनरावृत्त हो सके जब उसे आवश्यकता हो।
हालांकि, कोड दूर और दूर पढ़ने योग्य है।
अंत में, यदि कोई निर्णय लेता है कि LINQ IQueryable फ़ंक्शन के अंदर उपयोग की जाने वाली एक बूलियन अभिव्यक्ति को यूनिट परीक्षण करने की आवश्यकता नहीं है, तो जाहिर है क्योंकि यदि कोई अपवाद है, तो यह एक उच्च-आदेश (उर्फ व्यवसाय-स्तर) अपवाद (गलत है) मूल्य का परीक्षण किया जा रहा है, गलत ऑपरेटर, गलत ऑपरेंड इत्यादि) भाषा के कम से कम आदर्श उपयोग के विरोध में (यदि टर्नरी के बजाए स्विच के बजाय स्विच का उपयोग कर) तो चक्रवात जटिलता को मापने से इसे ध्यान में रखना चाहिए : ए कहां() फ़ंक्शन को मेरे सीसी में वृद्धि नहीं करनी चाहिए। चक्रवात जटिलता मापने से बेहतर कोड बनाने में मदद नहीं मिलेगी; यदि कुछ भी हो, तो यह कृत्रिम रूप से एक डेवलपर की प्रवृत्ति को सरल बनाने के लिए बढ़ाएगा जहां कोई सरलीकरण आवश्यक या वांछित नहीं हो सकता है।