क्या मैं गार्ड क्लॉज का उपयोग करूंगा, और अन्य खंड से बचने की कोशिश करूंगा?

Question

मैंने पढ़ा है (उदाहरण के लिए मार्टिन फाउलर से) कि हमें ओओपी में एक (लघु) विधि में एकल रिटर्न की बजाय गार्ड क्लॉज का उपयोग करना चाहिए। मैंने यह भी पढ़ा है (कहीं से मुझे याद नहीं है) कि जब संभव हो तो खंड से बचा जाना चाहिए।

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

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

क्या मैं गलत हूं या मुझे इसके साथ क्या करना चाहिए?

Answer 1

यह तर्कसंगत और शुद्ध सौंदर्य प्रश्न है।

सी और इसी तरह की भाषाओं में प्रारंभिक वापसी ऐतिहासिक रूप से टाल दी गई है क्योंकि संसाधन की सफाई को याद करना संभव था जो आमतौर पर प्रारंभिक वापसी के मामले में कार्य के अंत में रखा जाता है।

यह देखते हुए कि जावा के अपवाद हैं और प्रयास करें, अंत में, प्रारंभिक रिटर्न से डरने की कोई आवश्यकता नहीं है।

व्यक्तिगत, मैं आपसे सहमत हूं, क्योंकि मैं अक्सर जल्दी वापसी करता हूं - आमतौर पर इसका मतलब है कि कम कोड और सरल कोड प्रवाह कम/और घोंसले के साथ कम होता है।

Answer 2

क्या उन्हें http://www.cis.temple.edu/~ingargio/cis71/software/roberts/documents/loopexit.txt पढ़ा है और देखें कि यह उनके दिमाग को बदल देगा या नहीं। (उनके विचार का इतिहास है, लेकिन मैं आपके साथ हूं।)

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

Answer 3

मैं एकाधिक रिटर्न/रिटर्न-प्रारंभिक शिविर में हूं और मैं इसके अन्य इंजीनियरों को मनाने के लिए लॉबी करूंगा। आपके पास महान तर्क हो सकते हैं और महान स्रोत उद्धृत कर सकते हैं, लेकिन अंत में, आप जो भी कर सकते हैं वह आपकी पिच बनाते हैं, समझौते का सुझाव देते हैं, निर्णय लेते हैं, और फिर एक टीम के रूप में काम करते हैं, जिस तरह से यह काम करता है। (हालांकि समय-समय पर विषय की समीक्षा करना प्रश्न से बाहर नहीं है।)

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

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

Answer 4

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

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

अपवादों को फेंकने वाले गार्ड क्लॉज के बारे में बात करते समय, यहां विस्तार के तरीकों का उपयोग करके सी # में उन्हें सरल बनाने के तरीके के बारे में एक लेख दिया गया है: How to Reduce Cyclomatic Complexity: Guard Clause। हालांकि जावा में यह विधि उपलब्ध नहीं है, यह सी # में उपयोगी है।