कठिन परिस्थितियां बनाना

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

शायद मैं वहाँ नहीं देख रहा था, लेकिन मुझे कभी भी संदर्भ नहीं मिले कि कोड डिज़ाइन मानकों में कठिन परिस्थितियों से कैसे निपटा जाए। उनसे निपटना इस लेख का उद्देश्य है।

चूंकि मुझे उंगली चूसने में समस्या है, इसलिए जीसीसी 4.8.2 स्रोत कोड में से कुछ को उदाहरण के स्रोत के रूप में लिया जाता है, जिनमें से लेखक के लिए मानक एक खाली वाक्यांश नहीं हैं। उदाहरणों का उपयोग करते हुए, मैं फ़ाइल और स्टार्ट लाइन का हवाला दूंगा, ताकि हर कोई यह सुनिश्चित कर सके कि सब कुछ ईमानदार है। मैं ठीक से ध्यान देता हूं, क्योंकि उदाहरण वास्तविक हैं और एक सीमित स्रोत से लिए गए हैं, उनमें से कुछ सबसे सफल नहीं हो सकते हैं।

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

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

निम्नलिखित उदाहरण किनारे पर कहीं है।

libgcc / fp-bit.c - 205:

if (LARGEST_EXPONENT_IS_NORMAL (FRAC_NBITS) && (isnan (src) || isinf (src))) 

लेकिन कभी-कभी एक साधारण स्थिति भी आपको एक पल के लिए सोचने पर मजबूर कर देती है।

libgcc / fp-bit.c - 1579:

 if ((in.fraction.ll & (((USItype) 1 << F_D_BITOFF) - 1)) != 0) 

स्वाभाविक रूप से, अगर यह स्थिति का हिस्सा है, तो यह (परिणामस्वरूप स्थिति) शायद ही सरल कहा जा सकता है।

मैंने जानबूझकर परिस्थितियों के अंदर प्रीप्रोसेसर निर्देशों के साथ उदाहरण नहीं लिया, क्योंकि यह और भी जटिल परिस्थितियों के बारे में है जो इस लेख के दायरे से परे हैं।

पठनीयता में सुधार करने के लिए, आपको स्थिति को ब्लॉकों में तोड़ने की आवश्यकता होगी। यदि स्थिति के साथ स्ट्रिंग की लंबाई अनुमेय (अक्सर मानकों में निर्दिष्ट) से अधिक हो तो यह भी करना होगा। इस विभाजन के सिद्धांत हमारे लिए दो मुख्य कारणों से रुचि रखते हैं। सबसे पहले, यह किया जाना चाहिए ताकि स्थिति को बढ़ाना न हो। दूसरे, आपको एक मौन, लेकिन मानक पर आने की आवश्यकता है, क्योंकि एकरूपता का तथ्य पहले से ही पठनीयता के लिए एक प्लस है।

पहली बात जो मन में आती है वह है नेस्टेड सशर्त बयानों का उपयोग।

libgcc / fixed-bit.c - 84:

 if ((((x ^ y) >> I_F_BITS) & 1) == 0) { if (((z ^ x) >> I_F_BITS) & 1) { ... } } 

libgcc / fp-bit.c - 361:

 if (exp < EXPMAX) if (low > unity || (low == unity && (high & 1) == 1)) { ... } 

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

अधिक दिलचस्प विकल्प मल्टी-लाइन स्थितियां हैं। कुछ के लिए इस तरह का एक समाधान अप्रत्याशित लगता है, हालांकि यह कई स्थानों (एक ही सी, पीएचपी, पायथन) में समर्थित है।

बंटवारे का विचार यह है कि प्रत्येक पंक्ति पर केवल एक उप-विभाजन है।

libgcc / libgcc2.c - 1980

 if (!recalc && (isinf (ac) || isinf (bd) || isinf (ad) || isinf (bc))) 

यह स्थिति आसानी से पढ़ी और समझी जा सकती है। लेकिन यह पहले बताए गए नियम का पालन नहीं करता है। यहां एकरसता का लाभ मिलता है। यदि प्रति पंक्ति एक उप-स्थिति लिखने की आवश्यकता निर्दिष्ट नहीं है, तो इसे पढ़ते समय इस स्थिति का विश्लेषण जटिल है। अन्यथा, यहां तक ​​कि अगर आप एक उप -विभाजन के रूप में libgcc / fp-bit.c - 1579 जैसे कुछ का सामना करते हैं, तो यह पहले से ही ज्ञात है कि यह जटिल नहीं है।

विचाराधीन स्रोतों में अधिकांश बहु-पंक्ति स्थितियां इस विचार के अनुरूप हैं। लेकिन इसे केवल उसी तक सीमित न रखें। पिछले उदाहरण में संकेत देते हैं कि इस दृष्टिकोण के साथ स्थितियों के घोंसले के शिकार होने की कल्पना की जा सकती है। केवल एक चीज जिसने संदेह पैदा किया, वह यह था कि ऐसी सभी स्थितियाँ बहुत नीरस थीं, वे सिर्फ एक ऐसी "सीढ़ी" थीं, जिसने यह भी अनुमान लगाया कि यह सिर्फ एक संयोग था।

सौभाग्य से, एक संपूर्ण उदाहरण पाया गया कि, कोई संदेह नहीं, एक सुंदर और समझने योग्य कठिन स्थिति की मेरी परिभाषा फिट बैठता है।

libgcc / libgcov-driver.c - 688:

 if (!all_prg->checksum && (cs_all->num != cs_prg->num || cs_all->runs != cs_prg->runs || cs_all->sum_all != cs_prg->sum_all || cs_all->run_max != cs_prg->run_max || cs_all->sum_max != cs_prg->sum_max)) 

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

स्वाभाविक रूप से, इसे एक नेस्टेड सशर्त विवरण के साथ जोड़ना (जैसा कि libgcc / libgcc2.c - 1611 में किया गया है (लेख में कोई उदाहरण नहीं है) )।

इस दृष्टिकोण को लागू करने का एक और विकल्प मेरे दिमाग में आता है, लेकिन यह अधिक बोझिल है, और व्यवहार में मैंने इसे नहीं देखा है। कुछ इस प्रकार है:

 if ( condition1 && ( condition2 || condition3 ) ) 

यह सिर्फ एक विकल्प है। समापन कोष्ठकों को एक अलग रेखा पर रखने का विचार है। यह "जंपिंग" इंडेंटेशन को समाप्त करता है, उदाहरण के लिए, निम्नलिखित उदाहरण में।

libgcc / fixed-bit.c - 1013:

 if ((BIG_SINT_C_TYPE) high > (BIG_SINT_C_TYPE) max_high || ((BIG_SINT_C_TYPE) high == (BIG_SINT_C_TYPE) max_high && (BIG_UINT_C_TYPE) low > (BIG_UINT_C_TYPE) max_low)) low = max_low; /* Maximum. */ 

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

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

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

 bool mustRdraw = (frame.isChanged() || target.isChanged()) || experiment.isRunning(); bool isFullScreen = frame.getSize().equal(screen.getSize()); if (isFullScreen && mustRedraw) { // redraw } 

परिस्थितियों के समुचित समूहन और चरों के नामकरण के साथ, यह दृष्टिकोण एक दस्तावेजीकरण कार्य भी करता है।