क्या कोडिंग शैली के सिद्धांतों का कोई वैज्ञानिक रूप से कठोर अध्ययन है? [बन्द है]

Question

क्या एक कोडिंग शैली सिद्धांत है - जैसे एकल-निकास सिद्धांत - वास्तव में एक अच्छी बात है? हमेशा, या कभी-कभी? वास्तव में इससे कितना फर्क पड़ता है?

आपकी राय जो भी हो, ये स्पष्ट रूप से व्यक्तिपरक प्रश्न हैं। या क्या वे?

क्या किसी ने कोडिंग शैली के सिद्धांतों का वैज्ञानिक रूप से कठोर अध्ययन करने का प्रयास किया है?

मैं कल्पना नहीं कर सकता कि कोई भी पठनीयता का दोहरा-अंधा अध्ययन कैसे करेगा, लेकिन शायद डबल-अज्ञानी संभव हो सकता है - उन छात्रों का उपयोग करें जो विषय के रूप में अध्ययन किए जा रहे सिद्धांत के बारे में नहीं जानते हैं, और अध्ययन को संचालित करने के लिए गैर-प्रोग्रामर।

Comments

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

— deadalnix

यह भी भाषा पर अत्यधिक निर्भर करता है कुछ सिद्धांत विशिष्ट भाषाओं पर लागू होते हैं, अन्य नहीं। उदाहरण के लिए single-exit principleवास्तव में RAII के कारण C ++ पर लागू नहीं होता है

— मार्टिन

haskell.cs.yale.edu/?post_type=publication&p=366

— SK-logic

@ लोकी - मुझे इस बारे में सोचना था, और मुझे यकीन नहीं है कि मैं सहमत हूं। यह सच है कि RAII को अपवादों से निपटने के लिए बड़े हिस्से में डिज़ाइन किया गया है, जो वैकल्पिक निकास बिंदु हैं, लेकिन (कम से कम कुछ लोगों के लिए) वे वैकल्पिक वैकल्पिक निकास बिंदुओं के रूप में गिना करते हैं - वास्तव में उस तरह से एकल निकास सिद्धांत के खिलाफ गिनती नहीं break, gotoया returnकरना। IOW एकल निकास C ++ में एक पूर्ण नहीं है, लेकिन यह बहुत सी और ज्यादातर अन्य भाषाओं में इसके बारे में मेरा दृष्टिकोण है। लेकिन यह अभी भी गैर-सख्त अर्थों में प्रासंगिक है।

— स्टीव 314

@ स्टीव 314, लेख कम से कम दूर से प्रासंगिक है - यह इस तरह के एक प्रयोग की पद्धति के लिए एक डिजाइन को रेखांकित करता है, जो इस क्षेत्र में ठीक से दर्ज किए गए प्रयोगात्मक सबूतों की स्पष्ट कमी के कारण काफी महत्वपूर्ण है।

— तर्क

Answer 1

मैं डेडलिंक की टिप्पणी गूँज रहा हूँ: कोड पूरा 2 पढ़ें । लेखक (स्टीव मैककोनेल) कोडिंग शैली की गहराई से और अक्सर कागजात और डेटा के संदर्भों पर चर्चा करता है।

Comments

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

— gnat

मैंने इस पुस्तक को नहीं पढ़ा है, और शायद मुझे चाहिए, लेकिन - gnats जवाब में टिप्पणियों के आधार पर - क्या संदर्भित कागजात वास्तव में वैज्ञानिक रूप से कठोर और उद्देश्य हैं? यदि उत्तर "जितना हो सकता है" है, तो क्या समझौता आवश्यक था? जैसा कि मैंने सवाल में सुझाव दिया, क्या डबल-ब्लाइंड को कुछ कमजोर मानक के साथ बदलना आवश्यक था?

— स्टीव 314

@ Steve314: मुझे नहीं पता, मैंने स्रोतों की जाँच नहीं की है! लेकिन आपको सर्वोत्तम अभ्यास स्थापित करने के लिए हमेशा वैज्ञानिक कठोरता की आवश्यकता नहीं होती है। पेशेवरों और विपक्षों की चर्चा कभी-कभी पर्याप्त होती है।

— एम। डुडले

@emddudley - बिल्कुल सच है, लेकिन वास्तव में यह सवाल क्या था।

— स्टीव ३४

@ स्टीव ३१४: कोड कम्पलीट आपके लिए एक बेहतरीन शुरुआती बिंदु होगा, और मुझे विश्वास है कि इसके कुछ संदर्भ कोडिंग शैली के वैज्ञानिक विश्लेषण के मुद्दे को संबोधित करते हैं।

— एम। डुडले

Answer 2

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

प्रोग्रामर, जिन्होंने कुछ कोडिंग शैली का अनुसरण करने वाले कोड को पढ़ने और लिखने में वर्षों का समय बिताया है, वे स्पष्ट रूप से कुछ परिपूर्ण कोडिंग शैली की तुलना में अधिक पठनीय पाएंगे जो वे अपने जीवन में पहली बार देखेंगे।

यह सबसे सामान्य QWERTY टाइपिंग लेआउट के साथ ठीक वैसा ही है - यह साबित करना आसान है कि यह एर्गोनॉमी के संदर्भ में काफी उप-प्रकार है (क्या आपको लगता है कि TYPEWRITER शब्द के सभी वर्णों को दैनिक सुविधा के साथ शीर्ष पंक्ति में रखा गया था?) ।

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

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

Comments

कूल, मैंने

— कॉलेमेक

@ यह भी कम ही पता है कि कार्पल एक्स है, जिसे मैंने कुछ समय के लिए टॉय किया था। मुझे यह कोलमैक की तुलना में अच्छा लगा (मैं कार्पलक्स के साथ 90-100 wpm तक पहुंच गया)। यहां तक ​​कि अगर आप किसी भी विदेशी लेआउट पर स्विच करने का इरादा नहीं रखते हैं, तो कार्पलक्स वेबसाइट कीबोर्ड लेआउट का मूल्यांकन और अनुकूलन करने और समस्याओं की इस श्रेणी के लिए आनुवंशिक एल्गोरिदम का उपयोग करने पर एक बहुत ही रोचक पढ़ती है। Mkweb.bcgsc.ca/carpalx

— कोनराड मोरावस्की

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

— जेरेमी

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

— कोनराड मोरव्स्की

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

— कोनराड मोरावस्की

Answer 3

जवाब एक निश्चित नहीं है! क्या `ब्रेक` और` जारी` खराब प्रोग्रामिंग प्रथाएं हैं? इस सवाल का एक सबसेट है, इसलिए मैं उस पर बमुश्किल संशोधित जवाब के साथ शुरू करने जा रहा हूं ...

आप ब्रेक स्टेटमेंट (या लूप्स के बीच से रिटर्न, जो एक ही काम करते हैं) के बिना [पुनः] प्रोग्राम लिख सकते हैं। लेकिन ऐसा करने पर आपको अतिरिक्त चर और / या कोड दोहराव का परिचय देना पड़ सकता है, जो आमतौर पर कार्यक्रम को समझने में कठिन बनाते हैं। पास्कल (1960 के अंत की प्रोग्रामिंग भाषा) विशेष रूप से शुरुआती प्रोग्रामरों के लिए बहुत खराब थी।

एक कंप्यूटर विज्ञान का परिणाम है, जिसे कोसाराजू के नियंत्रण संरचनाओं का पदानुक्रम कहा जाता है, जो 1973 तक वापस आता है और जिसका उल्लेख नथ के (अधिक) प्रसिद्ध पेपर स्ट्रक्चर्ड प्रोग्रामिंग में 1974 से बयानों के लिए किया गया है। 1973 में राव एस। कोसराजू ने जो साबित किया, वह यह नहीं है कि उन सभी प्रोग्रामों को फिर से लिखना संभव है जिनमें अतिरिक्त स्तर की शुरुआत किए बिना एन की तुलना में कम गहराई वाले कार्यक्रमों में गहराई एन के बहु-स्तरीय ब्रेक हैं । लेकिन मान लीजिए कि यह केवल एक विशुद्ध सैद्धांतिक परिणाम है। (बस कुछ अतिरिक्त चर जोड़ सकते हैं? निश्चित रूप से आप ऐसा कर सकते हैं कि 3K + उपयोगकर्ताओं के साथ स्टैग्रेक्सचेंज पर इनग्रुप महसूस करने के लिए ...)

सॉफ्टवेयर इंजीनियरिंग के नजरिए से बहुत महत्वपूर्ण है हाल ही में एरिक एस। रॉबर्ट्स द्वारा लूप एग्जिट्स एंड स्ट्रक्चर्ड प्रोग्रामिंग: द रिओपनिंग द डिबेट (doi: 10.1145 / 199688.199815) शीर्षक से हाल ही में एक और पेपर । रॉबर्ट्स उससे पहले दूसरों द्वारा किए गए कई अनुभवजन्य अध्ययनों का सारांश देते हैं। उदाहरण के लिए, जब CS101 प्रकार के छात्रों के एक समूह को एक सरणी में अनुक्रमिक खोज को लागू करने वाले फ़ंक्शन के लिए कोड लिखने के लिए कहा गया था, तो अध्ययन के लेखक ने कहा कि निम्नलिखित उन छात्रों के बारे में हैं जिन्होंने अनुक्रमिक से बाहर निकलने के लिए ब्रेक / रिटर्न का उपयोग किया था तत्व मिलने पर सही लूप खोजें:

मुझे अभी तक एक भी ऐसा व्यक्ति नहीं मिला है जिसने [इस शैली] का उपयोग करके एक कार्यक्रम का प्रयास किया, जिसने एक गलत समाधान तैयार किया।

रॉबर्ट्स भी कहते हैं कि:

जिन छात्रों ने लूप के लिए स्पष्ट रिटर्न का उपयोग किए बिना समस्या को हल करने का प्रयास किया, उन्होंने बहुत कम सफलता प्राप्त की: इस रणनीति का प्रयास करने वाले 42 छात्रों में से केवल सात ही सही समाधान उत्पन्न करने में कामयाब रहे। यह आंकड़ा 20% से कम की सफलता दर का प्रतिनिधित्व करता है।

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

और रिटर्न / ब्रेक-प्रकार के बयानों के अलावा यहां एक बड़ा मुद्दा है, इसलिए यह सवाल ब्रेक के बारे में एक की तुलना में थोड़ा व्यापक है। अपवाद हैंडलिंग तंत्र कुछ के अनुसार एकल-निकास बिंदु प्रतिमान का भी उल्लंघन कर रहे हैं

• http://msmvps.com/blogs/peterritchie/archive/2008/03/07/single-entry-single-exit-should-it-still-be-applicable-in-object-oriented-languages.aspx
• http://pragprog.com/magazines/2012-04/the-pragmatic-defense

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

मैं देखता हूं कि "केवल एक वापसी" की धारणा कहां से आई है?इस साइट पर प्रचलित राय इस बात के विपरीत है कि मैंने यहां क्या पोस्ट किया है, इसलिए मैं पूरी तरह से समझता हूं कि मैं पहले से ही डाउन-वोटिंग क्यों कर रहा हूं, भले ही मैं यहां पहला जवाब हूं कि वास्तव में कुछ ऐसा प्रदान करें जो प्रश्न पूछे: सिंगल-एग्जिट मुद्दे पर केंद्रित वास्तविक प्रयोज्य परीक्षणों की कुछ जानकारी। मुझे लगता है कि मुझे ज्ञान को पूर्वधारणाओं के रास्ते में नहीं आने देना चाहिए, खासकर एक गेम साइट पर। मैं अब से विकिपीडिया के संपादन के लिए छड़ी जा रहा हूँ। कम से कम अच्छे स्रोतों से जानकारी की सराहना की जाती है और स्रोतों द्वारा समर्थित होने का दिखावा करने वाले अस्पष्ट या गलत दावे अंततः प्रतिबंध लगाते हैं। इस साइट पर, काफी विपरीत होता है: तथ्यों पर असंबद्ध राय हावी है। मैं इस अंतिम भाग को हटाने के लिए एक मॉड की उम्मीद करता हूं, लेकिन कम से कम उस दोस्त को पता चल जाएगा कि आपने मुझे यहां योगदानकर्ता के रूप में हमेशा के लिए क्यों खोया है।

Comments

मैंने इसे अस्वीकार नहीं किया, लेकिन आपके "लेकिन ऐसा करने में आपको अतिरिक्त चर और / या कोड दोहराव पेश करना पड़ सकता है, जो आमतौर पर कार्यक्रम को समझने में कठिन बनाते हैं।" बिंदु, यह एक व्यक्तिपरक दावा है। मैं मानता हूं कि एक चर या कोड दोहराव को जोड़ना कठिन होता है, लेकिन यकीनन एक गोटो को जोड़ना भी मुश्किल होता है, साथ ही यकीनन नकल द्वारा किए गए नुकसान को एक फ़ंक्शन में डुप्लिकेट किए गए कोड को फैक्टर करके कम किया जा सकता है (हालांकि IMO चल रहा है कॉल ग्राफ में जटिलता स्वचालित रूप से इसे समाप्त नहीं करती है)।

— स्टीव 314

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

— स्टीव

वैसे भी, मुझे लगता है कि बहुत से लोग अपवादों को वैकल्पिक वैकल्पिक निकास बिंदुओं के रूप में सोचते हैं - क्योंकि वे त्रुटि के मामलों के लिए हैं (जैसे) वे वास्तव में गिनती नहीं करते हैं। मैं समझता हूं कि यह थोड़ी भाषा-संस्कृति संवेदनशील है, हालांकि। कुछ भाषाओं में "अपवाद" नाम से अधिक है - एक असाधारण सफलता का मामला वैध है (और IIRC स्ट्रॉस्ट्रुप ने C ++ के बारे में कुछ ऐसा कहा है, एक दार्शनिक बिंदु उठाते हुए कि क्या एक त्रुटि एक त्रुटि है अगर यह संभाला है)। कुछ लोग यह भी कहते हैं कि जब भी आपको नियंत्रण प्रवाह की आवश्यकता होती है तो अपवाद केवल एक और नियंत्रण प्रवाह होता है।

— स्टीव 314

@ Steve314 "इसके अलावा, डुप्लिकेट द्वारा किए गए नुकसान को डुप्लिकेट किए गए कोड को एक फ़ंक्शन में बाहर फैक्टर द्वारा कम किया जा सकता है " लाइन के बाहर और फ़ंक्शन के एक तर्क के तत्काल दृश्य भाग से बाहर, एक ऐसा हिस्सा जो बिना किसी अर्थ को अलग करता है। फ़ंक्शन के तर्क को समझना और भी कठिन बना देता है।

— जिज्ञासु

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

— 314

Answer 4

http://dl.acm.org/citation.cfm?id=1241526

http://www.springerlink.com/content/n82qpt83n8735l7t/

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=661092

[आपके सवालों का जवाब एक ही शब्द "हां" से लगता है। हालाँकि, मुझे बताया गया है कि लघु उत्तर प्रदान करना प्रश्न का "खारिज" करना है। यदि आपको लगता है कि मैं बर्खास्त कर दिया गया हूं, तो कृपया जवाब को चिह्नित करें ताकि एक मध्यस्थ इसे हटा सके।]

Comments

@ luis.espinal: क्या अंत की ओर? पाठ में क्या जानकारी होगी? सवाल थोड़ा घूमता है। प्रश्न के किस भाग को कुछ पाठ के साथ संबोधित किया जाना चाहिए?

— लोट

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

— luis.espinal

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

— luis.espinal

ओपी के मुंह से Is a coding style principle - e.g. the single-exit principle - really a good thing?- यह उस प्रश्न का संदर्भ देता है जो वह प्रस्तुत कर रहा है, कोडिंग शैलियों के बारे में। इसके अलावा, कोडिंग शैली प्रोग्रामिंग पद्धति के रूप में समान नहीं है, विशेष रूप से उच्च-स्तरीय डिजाइन विधियों में जो IEEE लेख का ध्यान केंद्रित करते हैं (लेखकों द्वारा स्पष्ट रूप से कहा गया है।) यही कारण है कि मैं "नहीं" कहता हूं - स्कोप पूरी तरह से अलग हैं।

— luis.espinal

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

— luis.espinal

Answer 5

एक कोडिंग शैली सिद्धांत है - जैसे एकल-निकास सिद्धांत

जो लोग अभी भी सिंगल-एग्जिट या मल्टीपल एग्जिट में हर्क करते हैं, वे अभी भी 1960 के दशक के अंत में अटक गए हैं। इसके बाद, जब हम संरचित प्रोग्रामर की शैशवावस्था में थे, तब इस तरह की चर्चा महत्वपूर्ण थी, और यह घोषणा करते हुए एक बहुत से शिविर थे कि Bohm-Jacopini संरचित प्रोग्राम Theorem के पीछे निष्कर्ष सभी प्रोग्रामिंग कंस्ट्रक्ट्स पर सार्वभौमिक रूप से लागू नहीं थे।

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

मेरे जवाब के बाकी हिस्सों के लिए, यह सब सापेक्ष है (सॉफ्टवेयर में क्या नहीं है?):

• वास्तव में एक अच्छी बात है?

हाँ। सामान्य मामलों के अधिकांश समय, किनारे के मामलों और भाषा-विशिष्ट प्रोग्रामिंग निर्माणों के लिए विशिष्ट केवेट के साथ।

हमेशा, या कभी-कभी?

सर्वाधिक समय।

वास्तव में इससे कितना फर्क पड़ता है?

निर्भर करता है।

पढ़ने योग्य कोड बनाम अपठनीय कोड। बढ़ी हुई जटिलता (जिसे हमें अब तक त्रुटियों को पेश करने की संभावना बढ़ जाती है) बनाम सरल जटिलता (और इरगो, त्रुटियों की छोटी संभावना) बढ़ जाती है। ऐसी भाषाएं जिनके कंपाइलर एक निहित रिटर्न नहीं कहते हैं (जैसे, पास्कल, जावा या सी #) और उन int (C और C ++) के लिए डिफ़ॉल्ट।

अंत में, यह एक कीबोर्ड के पीछे आदमी / घंटों के साथ सम्मानित किया जाने वाला कौशल है। कभी-कभी, कई रिटर्न स्टेटमेंट रखना ठीक होता है, जैसे यहाँ (कुछ पास्कलसीक स्यूडोकोड में):

function foo() : someType
  begin
  if( test1 == true )
  then
    return x;
  end
  doSomethignElseThatShouldnHappenIfTest1IsTrue();
  return somethingElse();
end;

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

कभी-कभी यह नहीं होता है (यहां सी-लाइक स्यूडोकोड का उपयोग करके):

switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
   doSomething(); // no return statement yet
}

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

शायद एल्गोरिथ्म सही है, लेकिन खराब लिखा गया है।

या हो सकता है, प्रोग्रामर की क्षमता से परे बाहरी ताकतों द्वारा, यह वैध रूप से आवश्यक एल्गोरिथ्म का वास्तविक (और सही) प्रतिनिधित्व हो।

शायद यह गलत है।

इनमें से किसी की सच्चाई को उजागर करने के लिए पिछले उदाहरण की तुलना में कहीं अधिक प्रयास की आवश्यकता है । और यहाँ कुछ ऐसा है जिस पर मैं दृढ़ता से विश्वास करता हूँ (आप को लगता है कि मुझे इसे वापस करने के लिए कोई औपचारिक अध्ययन नहीं है):

एक कोड स्निपेट माना जाता है जिसे सही माना जाता है:

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

2. एक सिंगल रिटर्न स्टेटमेंट ऐसे कोड के टुकड़े की पठनीयता और सरलता को बढ़ाता है यदि रिटर्न वैल्यू या तो एल्गोरिथ्म के निष्पादन के दौरान गणना की जाती है या यदि गणना के लिए जिम्मेदार एल्गोरिथ्म में चरणों को एल्गोरिथम की संरचना में एक स्थान पर एक साथ समूहीकृत किया जा सकता है। ।

3. एक एकल रिटर्न स्टेटमेंट में इस तरह के कोड की पठनीयता और सरलता कम हो जाती है, अगर इसे एक या एक से अधिक फ्लैग वैरिएबल के लिए असाइनमेंट की आवश्यकता होती है, इस तरह के असाइनमेंट के स्थानों को पूरे एल्गोरिथ्म में समान रूप से स्थित नहीं किया जाता है।

4. एकाधिक रिटर्न स्टेटमेंट कोड के ऐसे टुकड़े की पठनीयता और सरलता को कम कर देते हैं यदि रिटर्न स्टेटमेंट को एल्गोरिथम में समान रूप से वितरित नहीं किया जाता है, और यदि वे कोड के पारस्परिक रूप से अनन्य ब्लॉकों का सीमांकन करते हैं जो आपस में आकार या संरचना में समान नहीं हैं।

यह प्रश्न में कोड स्निपेट की जटिलता से निकटता से संबंधित है। और यह बदले में साइक्लोमैटिक और हॉलस्टीड जटिलता उपायों से संबंधित है। इससे व्यक्ति निम्नलिखित का पालन कर सकता है:

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

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

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

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

Comments

C ++ रिटर्न प्रकार int के लिए डिफ़ॉल्ट नहीं है: कोई डिफ़ॉल्ट रिटर्न प्रकार नहीं है इसलिए इसे सभी मामलों में निर्दिष्ट किया जाना चाहिए।

— सोजेरड

इससे पहले कि मैं यह प्रश्न लिखूँ - प्रोग्रामर.स्टैकएक्सचेंज . com/questions/ 58237/… । मूल रूप से, मैं सिद्धांत के बारे में जागरूकता की वकालत कर रहा हूं, लेकिन इसका सख्ती से पालन नहीं कर रहा हूं - यदि सभी निकास बिंदु स्पष्ट हैं, तो मैं खुश हूं। यहाँ मेरी बात - सिर्फ इसलिए कि मैं एक सिद्धांत का उल्लेख करता हूं उदाहरण के रूप में इसका मतलब यह नहीं है कि मैं उस सिद्धांत की वकालत कर रहा हूं, और निश्चित रूप से यह सख्त रूप में नहीं है। मेरा व्यक्तिपरक विचार सिर्फ इतना है, हालांकि - शायद मेरे विचार के लिए एक मजबूत तर्क है, या शायद एक मजबूत तर्क है कि मैं गलत हूं।

— स्टीव 314

"डिफ़ॉल्ट टू इंट" के बारे में क्या है?

— जिज्ञासु

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

— luis.espinal