संरचित प्रोग्रामिंग

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

यह 1950 के दशक के अंत में ALGOL 58 और ALGOL 60 प्रोग्रामिंग भाषाओं के आगमन के साथ उभरा,^[1] ब्लॉक संरचनाओं के लिए समर्थन सहित उत्तरार्द्ध के साथ। इसकी लोकप्रियता और व्यापक स्वीकृति में योगदान करने वाले कारकों में, पहले शिक्षा जगत में और बाद में चिकित्सकों के बीच, 1966 में संरचित कार्यक्रम प्रमेय के रूप में जानी जाने वाली खोज शामिल है,^[2] और 1968 में डच कंप्यूटर वैज्ञानिक एडजर डब्ल्यू. डिजस्ट्रा द्वारा प्रभावशाली नुकसानदायक माने जाने वाले स्टेटमेंट पर जाएं ओपन लेटर का प्रकाशन, जिसने संरचित प्रोग्रामिंग शब्द गढ़ा था।^[3] संरचित प्रोग्रामिंग का उपयोग अक्सर विचलन के साथ किया जाता है जो कुछ विशेष मामलों में स्पष्ट कार्यक्रमों की अनुमति देता है, जैसे कि जब अपवाद संचालन करना होता है।

तत्व

नियंत्रण संरचना

संरचित कार्यक्रम प्रमेय के बाद, सभी कार्यक्रमों को तीन नियंत्रण संरचनाओं से बना देखा जाता है:

अनुक्रम ; आदेशित बयान या सबरूटीन्स क्रम में निष्पादित।
चयन; कार्यक्रम की स्थिति के आधार पर एक या कई बयानों को निष्पादित किया जाता है। यह आमतौर पर कीवर्ड (कंप्यूटर प्रोग्रामिंग) जैसे सशर्त (प्रोग्रामिंग) | के साथ व्यक्त किया जाता हैif..then..else..endif. सशर्त बयान में कम से कम एक सही स्थिति होनी चाहिए और प्रत्येक स्थिति में अधिकतम एक निकास बिंदु होना चाहिए।
पुनरावृत्ति; एक स्टेटमेंट या ब्लॉक को तब तक निष्पादित किया जाता है जब तक कि प्रोग्राम एक निश्चित स्थिति तक नहीं पहुंच जाता है, या किसी संग्रह के प्रत्येक तत्व पर संचालन लागू नहीं किया जाता है। यह आमतौर पर वाइलू लूप | जैसे कीवर्ड के साथ व्यक्त किया जाता हैwhile, करो जबकि पाश |repeat, पाश के लिए |forया करो जबकि पाश |do..until. अक्सर यह अनुशंसा की जाती है कि प्रत्येक लूप में केवल एक प्रवेश बिंदु होना चाहिए (और मूल संरचनात्मक प्रोग्रामिंग में, केवल एक निकास बिंदु और कुछ भाषाएं इसे लागू करती हैं)।

संरचित कार्यक्रम प्रमेय का चित्रमय प्रतिनिधित्व - अनुक्रम, चयन और पुनरावृत्ति - नासी-श्नीडरमैन आरेख (नीला) और प्रवाह चार्ट (हरा) का उपयोग करना।

सबरूटीन्स

सबरूटीन्स; कॉल करने योग्य इकाइयाँ जैसे कि प्रक्रियाएँ, कार्य, विधियाँ, या उपप्रोग्राम का उपयोग किसी एकल कथन द्वारा अनुक्रम को संदर्भित करने की अनुमति देने के लिए किया जाता है।

ब्लॉक

ब्लॉक (प्रोग्रामिंग) का उपयोग बयानों के समूहों को व्यवहार करने के लिए सक्षम करने के लिए किया जाता है जैसे कि वे एक बयान थे। ब्लॉक-संरचित भाषाओं में कुछ औपचारिक तरीके से संरचनाओं को घेरने के लिए एक सिंटैक्स होता है, जैसे कि एक if-statement द्वारा ब्रैकेट किया गया if..fi जैसा कि ALGOL 68 में है, या एक कोड सेक्शन जिसके द्वारा ब्रैकेट किया गया है BEGIN..END, जैसे PL/I और पास्कल (प्रोग्रामिंग भाषा), व्हाइटस्पेस चरित्र इंडेंटेशन जैसे कि पायथन (प्रोग्रामिंग लैंग्वेज), या कर्ली ब्रेसेस {...} C (प्रोग्रामिंग लैंग्वेज) और कर्ली ब्रेस फैमिली# कर्ली-ब्रैकेट लैंग्वेज।

संरचित प्रोग्रामिंग भाषाएँ

किसी भी प्रोग्रामिंग भाषा में संरचित प्रोग्रामिंग करना संभव है, हालांकि प्रक्रियात्मक प्रोग्रामिंग भाषा जैसी किसी चीज़ का उपयोग करना बेहतर होता है।^{[citation needed]}^{[clarification needed]} संरचित प्रोग्रामिंग के लिए शुरू में उपयोग की जाने वाली कुछ भाषाओं में शामिल हैं: ALGOL, पास्कल (प्रोग्रामिंग लैंग्वेज), PL/I, Ada (प्रोग्रामिंग लैंग्वेज) और RPL (प्रोग्रामिंग लैंग्वेज) लेकिन उस समय से अधिकांश नई प्रक्रियात्मक आरपीएल (प्रोग्रामिंग भाषा) संरचित प्रोग्रामिंग को प्रोत्साहित करने के लिए सुविधाएँ शामिल हैं। , और कभी-कभी असंरचित प्रोग्रामिंग को और अधिक कठिन बनाने के प्रयास में जानबूझकर सुविधाओं को छोड़ दिया जाता है - विशेष रूप से गोटो। संरचित प्रोग्रामिंग (कभी-कभी मॉड्यूलर प्रोग्रामिंग के रूप में जाना जाता है^{[citation needed]}) लिखे जा रहे प्रोग्राम पर एक तार्किक संरचना लागू करता है ताकि इसे अधिक कुशल और समझने और संशोधित करने में आसान बनाया जा सके।

इतिहास

सैद्धांतिक नींव

संरचित कार्यक्रम प्रमेय संरचित प्रोग्रामिंग का सैद्धांतिक आधार प्रदान करता है। यह बताता है कि कार्यक्रमों के संयोजन के तीन तरीके-अनुक्रमण, चयन और पुनरावृत्ति-किसी भी संगणनीय कार्य को व्यक्त करने के लिए पर्याप्त हैं। यह अवलोकन संरचित प्रोग्रामिंग आंदोलन से उत्पन्न नहीं हुआ; ये संरचनाएं केंद्रीय प्रसंस्करण इकाई के निर्देश चक्र के साथ-साथ ट्यूरिंग मशीन के संचालन का वर्णन करने के लिए पर्याप्त हैं। इसलिए, एक प्रोसेसर हमेशा इस अर्थ में एक संरचित प्रोग्राम को क्रियान्वित कर रहा है, भले ही यह मेमोरी से पढ़े गए निर्देश एक संरचित प्रोग्राम का हिस्सा न हों। हालांकि, लेखक आमतौर पर परिणाम का श्रेय बॉम और जैकोपिनी के 1966 के पेपर को देते हैं, संभवतः इसलिए कि एड्जर डब्ल्यू. डिज्कस्ट्रा ने खुद इस पेपर का हवाला दिया था।^[4] संरचित कार्यक्रम प्रमेय यह नहीं बताता है कि उपयोगी रूप से संरचित कार्यक्रम को कैसे लिखा और विश्लेषित किया जाए। इन मुद्दों को 1960 के दशक के अंत और 1970 के दशक के प्रारंभ में संबोधित किया गया था, जिसमें एड्जर डब्ल्यू. डिजस्ट्रा, रॉबर्ट डब्ल्यू. फ्लॉयड, टोनी होरे, ओले-जोहान डाहल और डेविड ग्रिस का प्रमुख योगदान था।

बहस

स्ट्रक्चर्ड प्रोग्रामिंग को अपनाने वाले पी.जे. प्लॉगर ने स्ट्रक्चर्ड प्रोग्राम प्रमेय पर अपनी प्रतिक्रिया का वर्णन किया:

Us converts waved this interesting bit of news under the noses of the unreconstructed assembly-language programmers who kept trotting forth twisty bits of logic and saying, 'I betcha can't structure this.' Neither the proof by Böhm and Jacopini nor our repeated successes at writing structured code brought them around one day sooner than they were ready to convince themselves.^[5]

डोनाल्ड नुथ ने इस सिद्धांत को स्वीकार किया कि कार्यक्रमों को साबित करने की क्षमता को ध्यान में रखकर लिखा जाना चाहिए, लेकिन वह GOTO कथन को समाप्त करने से असहमत थे, और 2018 तक अपने कार्यक्रमों में इसका उपयोग करना जारी रखा है।^[6] उनके 1974 के पेपर में, गोटो स्टेटमेंट्स के साथ स्ट्रक्चर्ड प्रोग्रामिंग,^[7] उन्होंने ऐसे उदाहरण दिए जहां उनका मानना था कि एक सीधी छलांग से प्रासंगिकता का त्याग किए बिना स्पष्ट और अधिक कुशल कोड प्राप्त होता है। नूथ ने एक ढीली संरचनात्मक बाधा का प्रस्ताव दिया: बाईं ओर सभी आगे की शाखाओं के साथ, दाईं ओर सभी पिछड़ी शाखाओं और एक दूसरे को पार करने वाली कोई भी शाखा के साथ एक कार्यक्रम के प्रवाह चार्ट को आकर्षित करना संभव होना चाहिए। संकलक और ग्राफ सिद्धांत के जानकारों में से कई ने केवल कम करने योग्य प्रवाह ग्राफ की अनुमति देने की वकालत की है^{[when defined as?]}.^[who?] संरचित प्रोग्रामिंग सिद्धांतकारों ने 1970 के दशक में आईबीएम के शोधकर्ता हरलन मिल्स द्वारा न्यूयॉर्क टाइम्स शोध फ़ाइल के लिए एक अनुक्रमण प्रणाली के विकास के लिए संरचित प्रोग्रामिंग सिद्धांत की अपनी व्याख्या लागू करने के बाद एक प्रमुख सहयोगी प्राप्त किया। परियोजना एक महान इंजीनियरिंग सफलता थी, और अन्य कंपनियों के प्रबंधकों ने संरचित प्रोग्रामिंग को अपनाने के समर्थन में इसका हवाला दिया, हालांकि दिज्क्स्ट्रा ने उन तरीकों की आलोचना की, जिनमें मिल्स की व्याख्या प्रकाशित कार्य से भिन्न थी।^[8] 1987 तक एक कंप्यूटर विज्ञान पत्रिका में संरचित प्रोग्रामिंग का प्रश्न उठाना अभी भी संभव था। फ्रैंक रुबिन ने उस वर्ष 'गोटो कंसिडर्ड हार्मफुल' कंसीडर्ड हार्मफुल शीर्षक वाले एक खुले पत्र के साथ ऐसा किया।^[9] कई आपत्तियों का पालन किया गया, जिसमें दिज्क्स्त्र की प्रतिक्रिया भी शामिल है, जिसने रुबिन और अन्य लेखकों द्वारा प्रतिक्रिया देते समय की गई रियायतों की तीखी आलोचना की।

परिणाम

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

सामान्य विचलन

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

जल्दी बाहर निकलें

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

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

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

अधिकांश आधुनिक भाषाएँ ऐसे लीक को रोकने के लिए भाषा-स्तर का समर्थन प्रदान करती हैं;^[10] संसाधन प्रबंधन (कंप्यूटिंग) पर विस्तृत चर्चा देखें। आमतौर पर यह अनवाइंड प्रोटेक्शन के माध्यम से किया जाता है, जो यह सुनिश्चित करता है कि निष्पादन ब्लॉक से बाहर निकलने पर कुछ कोड को चलाने की गारंटी दी जाती है; यह क्लीनअप ब्लॉक होने का एक संरचित विकल्प है और a goto. इसे अक्सर के रूप में जाना जाता है try...finally, और अपवाद हैंडलिंग का एक हिस्सा माना जाता है। एकाधिक के मामले में return बयानों का परिचय try...finally, बिना किसी अपवाद के अजीब लग सकता है। संसाधन प्रबंधन को समाहित करने के लिए विभिन्न तकनीकें मौजूद हैं। मुख्य रूप से C++ में पाया जाने वाला एक वैकल्पिक दृष्टिकोण, संसाधन अधिग्रहण प्रारंभ है है, जो संसाधनों को हटाने के लिए स्थानीय चर पर डिस्ट्रक्टर्स को कॉल करने के लिए फंक्शन एग्जिट पर सामान्य स्टैक अनइंडिंग (वैरिएबल डीललोकेशन) का उपयोग करता है।

केंट बेक, मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर) और सह-लेखकों ने अपनी पुनर्रचना पुस्तकों में तर्क दिया है कि नेस्टेड कंडीशन को गार्ड क्लॉज द्वारा समर्पित कई निकासों का उपयोग करके एक निश्चित प्रकार की चापलूसी संरचना की तुलना में समझना कठिन हो सकता है। उनकी 2009 की पुस्तक स्पष्ट रूप से बताती है कि एक निकास बिंदु वास्तव में एक उपयोगी नियम नहीं है। स्पष्टता प्रमुख सिद्धांत है: यदि विधि एक निकास बिंदु के साथ स्पष्ट है, तो एक निकास बिंदु का उपयोग करें; अन्यथा नहीं। वे एक फ़ंक्शन को बदलने के लिए एक कुकबुक समाधान प्रदान करते हैं, जिसमें केवल नेस्टेड कंडीशनल होते हैं, जो गार्डेड रिटर्न (या थ्रो) स्टेटमेंट के अनुक्रम में होते हैं, उसके बाद एक सिंगल अनगार्डेड ब्लॉक होता है, जिसका उद्देश्य सामान्य मामले के लिए कोड होता है, जबकि गार्डेड स्टेटमेंट होते हैं। कम आम वाले (या त्रुटियों के साथ) से निपटने के लिए माना जाता है।^[11] हर्ब सटर और आंद्रेई अलेक्जेंड्रेस्कु भी अपनी 2004 सी ++ टिप्स बुक में तर्क देते हैं कि सिंगल-एग्जिट पॉइंट एक अप्रचलित आवश्यकता है।^[12] अपनी 2004 की पाठ्यपुस्तक में, डेविड वाट (कंप्यूटर वैज्ञानिक) लिखते हैं कि एकल-प्रविष्टि बहु-निकास नियंत्रण प्रवाह अक्सर वांछनीय होते हैं। S-algol की Tennent की रूपरेखा धारणा का उपयोग करते हुए, वाट समान रूप से समकालीन प्रोग्रामिंग भाषाओं में पाए जाने वाले नियंत्रण प्रवाह निर्माणों का वर्णन करता है और यह समझाने का प्रयास करता है कि बहु-निकास नियंत्रण प्रवाह के संदर्भ में कुछ प्रकार के सीक्वेंसर दूसरों के लिए बेहतर क्यों हैं। वाट लिखते हैं कि अप्रतिबंधित गोटो (जंप सीक्वेंसर) खराब हैं क्योंकि जंप का गंतव्य किसी प्रोग्राम के पाठक के लिए स्व-व्याख्यात्मक नहीं है जब तक कि पाठक वास्तविक लेबल या पते को नहीं खोजता और जांचता है जो कि जंप का लक्ष्य है। इसके विपरीत, वाट का तर्क है कि रिटर्न सीक्वेंसर का वैचारिक इरादा अपने गंतव्य की जांच किए बिना अपने स्वयं के संदर्भ से स्पष्ट है। वाट लिखते हैं कि एस्केप सीक्वेंसर के रूप में जाना जाने वाला सीक्वेंसर का एक वर्ग, जिसे एक सीक्वेंसर के रूप में परिभाषित किया गया है, जो पाठ्य रूप से संलग्न कमांड या प्रक्रिया के निष्पादन को समाप्त करता है, लूप्स (मल्टी-लेवल ब्रेक सहित) और रिटर्न स्टेटमेंट दोनों को शामिल करता है। वाट यह भी नोट करते हैं कि जम्प सीक्वेंसर (गोटोस) को सी जैसी भाषाओं में कुछ हद तक प्रतिबंधित किया गया है, जहां लक्ष्य स्थानीय ब्लॉक के अंदर होना चाहिए या बाहरी ब्लॉक को घेरना चाहिए, यह प्रतिबंध अकेले सी में गोटो के इरादे को बनाने के लिए पर्याप्त नहीं है। -विवरण और इसलिए वे अभी भी स्पेगेटी कोड का उत्पादन कर सकते हैं। वाट यह भी जाँच करता है कि कैसे अपवाद अनुक्रमक एस्केप और जंप अनुक्रमक से भिन्न होते हैं; यह इस लेख के अगले भाग में समझाया गया है।^[13] उपरोक्त के विपरीत, बर्ट्रेंड मेयर ने अपनी 2009 की पाठ्यपुस्तक में लिखा है कि निर्देश पसंद करते हैं break और continue पुराने ही हैं goto भेड़ के कपड़ों में और उनके उपयोग के खिलाफ दृढ़ता से सलाह दी।^[14]

अपवाद हैंडलिंग

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

<वाक्यविन्यास लैंग = सीपीपी> बूल MyCheck1 () फेंक () {

 बूल सफलता = असत्य;
 कोशिश {
   // कुछ ऐसा करें जो अपवादों को फेंक दे।
   अगर (! MyCheck2 ()) {
     कुछ आंतरिक अपवाद फेंकें ();
   }
   // उपरोक्त के समान अन्य कोड।
   सफलता = सत्य;
 } पकड़ना (...) {
   // सभी अपवाद पकड़े गए और लॉग इन किए गए।
 }
 वापसी सफलता;

} </वाक्यविन्यास हाइलाइट>

पीटर रिची यह भी नोट करता है कि, सिद्धांत रूप में, एक भी throw ठीक पहले return एक समारोह में एकल-निकास सिद्धांत का उल्लंघन होता है, लेकिन तर्क देता है कि प्रोग्रामिंग भाषाओं में अपवाद प्रबंधन के प्रतिमान बनने से पहले दिज्क्स्ट्रा के नियम एक समय में लिखे गए थे, इसलिए वह एकल वापसी बिंदु के अलावा किसी भी संख्या में फेंक बिंदुओं की अनुमति देने का प्रस्ताव करता है। . उन्होंने नोट किया कि समाधान जो एकल-निकास बनाने के लिए अपवादों को लपेटते हैं, उनमें घोंसले की गहराई अधिक होती है और इस प्रकार उन्हें समझना अधिक कठिन होता है, और यहां तक कि उन लोगों पर भी आरोप लगाते हैं जो प्रोग्रामिंग भाषाओं के लिए ऐसे समाधान लागू करने का प्रस्ताव करते हैं जो कार्गो पंथ प्रोग्रामिंग में शामिल होने के अपवादों का समर्थन करते हैं। विचार।^[15] डेविड वाट सीक्वेंसर के ढांचे में अपवाद हैंडलिंग का भी विश्लेषण करते हैं (शुरुआती निकास पर पिछले अनुभाग में इस लेख में पेश किया गया।) वाट नोट करता है कि एक असामान्य स्थिति (आमतौर पर अंकगणितीय अतिप्रवाह या इनपुट/आउटपुट विफलताओं जैसे फ़ाइल नहीं मिली) एक तरह की है कुछ निम्न-स्तरीय प्रोग्राम यूनिट में पाई गई त्रुटि, लेकिन [जिसके लिए] एक उच्च-स्तरीय प्रोग्राम यूनिट में एक हैंडलर अधिक स्वाभाविक रूप से स्थित होता है। उदाहरण के लिए, एक प्रोग्राम में फ़ाइलों को पढ़ने के लिए कई कॉल हो सकते हैं, लेकिन जब कोई फ़ाइल नहीं मिलती है तो कार्रवाई करने के लिए प्रोग्राम के प्रश्न में फ़ाइल के अर्थ (उद्देश्य) पर निर्भर करता है और इस प्रकार इस असामान्य स्थिति के लिए एक हैंडलिंग रूटीन नहीं हो सकता निम्न-स्तरीय सिस्टम कोड में स्थित है। वॉट्स आगे नोट करता है कि कॉलर में स्टेटस फ्लैग परीक्षण शुरू करना, सिंगल-एग्जिट स्ट्रक्चर्ड प्रोग्रामिंग या यहां तक कि (मल्टी-एग्जिट) रिटर्न सीक्वेंसर के रूप में, ऐसी स्थिति में परिणाम होगा जहां एप्लिकेशन कोड स्टेटस फ्लैग के परीक्षणों से अव्यवस्थित हो जाता है और यह कि प्रोग्रामर स्थिति ध्वज का परीक्षण करने के लिए भूल गए या आलसी हो सकते हैं। वास्तव में, स्टेटस फ़्लैग द्वारा दर्शाई गई असामान्य स्थितियों को डिफ़ॉल्ट रूप से नज़रअंदाज़ कर दिया जाता है! वह नोट करता है कि स्टेटस फ्लैग परीक्षण के विपरीत, अपवादों में विपरीत डिफ़ॉल्ट (कंप्यूटर विज्ञान) होता है, जिससे प्रोग्राम समाप्त हो जाता है जब तक कि प्रोग्रामर स्पष्ट रूप से किसी तरह से अपवाद से निपटता है, संभवत: जानबूझकर इसे अनदेखा करने के लिए कोड जोड़कर। इन तर्कों के आधार पर, वाट ने निष्कर्ष निकाला कि जंप सीक्वेंसर या एस्केप सीक्वेंसर (पिछले अनुभाग में चर्चा की गई) ऊपर चर्चा किए गए शब्दार्थ के साथ एक समर्पित अपवाद सीक्वेंसर के रूप में उपयुक्त नहीं हैं।^[16] लाउडेन और लैम्बर्ट की पाठ्यपुस्तक इस बात पर जोर देती है कि अपवाद हैंडलिंग संरचित प्रोग्रामिंग निर्माणों से अलग है while लूप्स क्योंकि नियंत्रण का हस्तांतरण कार्यक्रम में एक अलग बिंदु पर सेट किया गया है, जहां वास्तविक स्थानांतरण होता है। उस बिंदु पर जहां वास्तव में स्थानांतरण होता है, वहां कोई वाक्यात्मक संकेत नहीं हो सकता है कि नियंत्रण वास्तव में स्थानांतरित किया जाएगा।^[17] कंप्यूटर विज्ञान के प्रोफेसर अरविंद कुमार बंसल ने यह भी नोट किया कि उन भाषाओं में जो अपवाद संचालन को लागू करते हैं, यहां तक कि संरचनाओं को भी नियंत्रित करते हैं for, जिनके पास अपवादों की अनुपस्थिति में एकल-निकास संपत्ति है, अब अपवादों की उपस्थिति में नहीं है, क्योंकि एक अपवाद समय से पहले नियंत्रण संरचना के किसी भी हिस्से में प्रारंभिक निकास का कारण बन सकता है; उदाहरण के लिए अगर init() में एक अपवाद फेंकता है for (init(); check(); increm()), तो चेक () के बाद सामान्य निकास बिंदु नहीं पहुंचा है।^[18] दूसरों (1999-2004) के कई पूर्व अध्ययनों और अपने स्वयं के परिणामों का हवाला देते हुए, वेस्टली वीमर और जॉर्ज नेकुला ने लिखा है कि अपवादों के साथ एक महत्वपूर्ण समस्या यह है कि वे छिपे हुए नियंत्रण-प्रवाह पथ बनाते हैं जो प्रोग्रामर के लिए तर्क करना मुश्किल होता है।^[19] कोड को सिंगल-एग्जिट पॉइंट्स तक सीमित करने की आवश्यकता समानांतर कंप्यूटिंग पर केंद्रित कुछ समकालीन प्रोग्रामिंग वातावरणों में दिखाई देती है, जैसे ओपनएमपी। ओपनएमपी से विभिन्न समांतर निर्माण, जैसे parallel do, समानांतर निर्माण के अंदर से बाहर जल्दी निकलने की अनुमति न दें; इस प्रतिबंध में से, से सभी तरह के निकास शामिल हैं break सी ++ अपवादों के लिए, लेकिन इन सभी को समांतर निर्माण के अंदर अनुमति दी जाती है यदि कूद लक्ष्य भी इसके अंदर है।^[20]

एकाधिक प्रविष्टि

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

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

राज्य मशीनें

कुछ कार्यक्रम, विशेष रूप से पारसर्स और संचार प्रोटोकॉल, में कई राज्य (कंप्यूटर विज्ञान) होते हैं जो एक दूसरे का अनुसरण इस तरह से करते हैं जो आसानी से बुनियादी संरचनाओं तक कम नहीं होते हैं, और कुछ प्रोग्रामर राज्य-परिवर्तन को नए राज्य में छलांग के साथ लागू करते हैं। . इस प्रकार के राज्य-स्विचिंग का उपयोग अक्सर लिनक्स कर्नेल में किया जाता है।^{[citation needed]} हालांकि, प्रत्येक राज्य-परिवर्तन को एक अलग उपप्रोग्राम बनाकर और सक्रिय स्थिति को इंगित करने के लिए एक चर का उपयोग करके इन प्रणालियों की संरचना करना संभव है (ट्रम्पोलिन (कंप्यूटिंग) देखें)। वैकल्पिक रूप से, इन्हें कोरटाइन के माध्यम से लागू किया जा सकता है, जो ट्रैम्पोलिन से अलग होता है।

यह भी देखें

ड्रैकन
न्यूनतम मूल्यांकन
नस्सी-शनीडरमैन आरेख
संरचना चार्ट
संरचित संगामिति
स्विच स्टेटमेंट

संदर्भ

उद्धरण

↑ Clark, Leslie B. Wilson, Robert G.; Robert, Clark (2000). Comparative programming languages (3rd ed.). Harlow, England: Addison-Wesley. p. 20. ISBN 9780201710120. Archived from the original on 26 November 2015. Retrieved 25 November 2015.
↑ Böhm & Jacopini 1966.
↑ Dijkstra 1968, p. 147, "The unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. ... The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one's program."
↑ Dijkstra 1968.
↑ Plauger, P. J. (February 12, 1993). Programming on Purpose, Essays on Software Design (1st ed.). Prentice-Hall. p. 25. ISBN 978-0-13-721374-0.
↑ DLS • Donald Knuth • All Questions Answered. YouTube. University of Waterloo. 15 Nov 2018. 48 minutes in. Retrieved 24 July 2022.
↑ Donald E. Knuth (December 1974). "Structured programming with go to statements" (PDF). Computing Surveys. 6 (4): 261–301. doi:10.1145/356635.356640. S2CID 207630080. Archived from the original (PDF) on 2013-10-23.
↑ In EWD1308, "What led to "Notes on Structured Programming""., dated 10 June 2001, Dijkstra writes, "Apparently, IBM did not like the popularity of my text; it stole the term "Structured Programming" and under its auspices Harlan D. Mills trivialized the original concept to the abolishment of the goto statement."
↑ Frank Rubin (March 1987). ""GOTO Considered Harmful" Considered Harmful" (PDF). Communications of the ACM. 30 (3): 195–196. doi:10.1145/214748.315722. S2CID 6853038. Archived from the original (PDF) on 2009-03-20.
↑ Elder, Matt; Jackson, Steve; Liblit, Ben (October 2008). Code Sandwiches (PDF) (Technical report). University of Wisconsin–Madison. 1647.
↑ Jay Fields; Shane Harvie; Martin Fowler; Kent Beck (2009). Refactoring: Ruby Edition. Pearson Education. pp. 274–279. ISBN 978-0-321-60350-0.
↑ Herb Sutter; Andrei Alexandrescu (2004). C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Pearson Education. ISBN 978-0-13-265442-5. Example 4: Single entry, single exit ("SESE"). Historically, some coding standards have required that each function have exactly one exit, meaning one return statement. Such a requirement is obsolete in languages that support exceptions and destructors, where functions typically have numerous implicit exits.
↑ Watt & Findlay 2004, pp. 215–221.
↑ Bertrand Meyer (2009). Touch of Class: Learning to Program Well with Objects and Contracts. Springer Science & Business Media. p. 189. ISBN 978-3-540-92144-8.
↑ "Single-Entry, Single-Exit, Should It Still be Applicable in Object-oriented Languages?". Peter Ritchie's MVP Blog. Archived from the original on 2012-11-14. Retrieved 2014-07-15.
↑ Watt & Findlay 2004, pp. 221–222.
↑ Kenneth C. Louden; Kenneth A. Lambert (2011). Programming Languages: Principles and Practices (3rd ed.). Cengage Learning. p. 423. ISBN 978-1-111-52941-3.
↑ Arvind Kumar Bansal (2013). Introduction to Programming Languages. CRC Press. p. 135. ISBN 978-1-4665-6514-2.
↑ Weimer, W. & Necula, G.C. (2008). "Exceptional Situations and Program Reliability" (PDF). ACM Transactions on Programming Languages and Systems. 30 (2). 8:27. doi:10.1145/1330017.1330019. S2CID 3136431. Archived from the original (PDF) on 2015-09-23.
↑ Rohit Chandra (2001). Parallel Programming in OpenMP. Morgan Kaufmann. p. 45. ISBN 978-1-55860-671-5.

स्रोत

एडवर्ड डिजस्ट्रा, नोट्स ऑन स्ट्रक्चर्ड प्रोग्रामिंग, पी। 6.
Böhm, Corrado; Jacopini, Giuseppe (May 1966). "प्रवाह आरेख, ट्यूरिंग मशीन और केवल दो गठन नियमों वाली भाषाएं" (PDF). Communications of the ACM. 9 (5): 366–371. CiteSeerX 10.1.1.119.9119. doi:10.1145/355592.365646. S2CID 10236439. Archived (PDF) from the original on 2015-09-23.
Dijkstra, Edsger W. (March 1968). "संपादक को पत्र: हानिकारक माने जाने वाले बयान पर जाएं" (PDF). Communications of the ACM. 11 (3): 147–148. doi:10.1145/362929.362947. ISSN 0001-0782. S2CID 17469809.
माइकल ए जैक्सन (कंप्यूटर वैज्ञानिक) | माइकल ए जैक्सन, प्रोग्राम डिजाइन के सिद्धांत, अकादमिक प्रेस, लंदन, 1975।
ओले-जोहान डाहल|ओ.-जे. डहल, ई. डब्ल्यू. डिजस्ट्रा, सी. ए. आर. होरे स्ट्रक्चर्ड प्रोग्रामिंग, अकादमिक प्रेस, लंदन, 1972। ISBN 0-12-200550-3.
- इस खंड में आठ रानियों की पहेली को हल करने के लिए बैकट्रैकिंग एल्गोरिदम विकसित करने के लिए संरचित दृष्टिकोण का उपयोग करने के विस्तारित उदाहरण सहित, ऊपर संरचित प्रोग्रामिंग पर नोट्स का एक विस्तारित संस्करण शामिल है।
- एक पीडीएफ संस्करण एसीएम क्लासिक बुक्स सीरीज में है
- ध्यान दें कि डाहल द्वारा इस पुस्तक का तीसरा अध्याय एक ऐसे दृष्टिकोण का वर्णन करता है जिसे ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के रूप में आसानी से पहचाना जाता है। इसे सही दिखाने में सहायता के लिए एक कार्यक्रम को उपयोगी रूप से तैयार करने के एक अन्य तरीके के रूप में देखा जा सकता है।
Watt, David Anthony; Findlay, William (2004). प्रोग्रामिंग भाषा डिजाइन अवधारणाओं. John Wiley & Sons. ISBN 978-0-470-85320-7.

बाहरी संबंध

BPStruct - A tool to structure concurrent systems (programs, process models)
J. Darlinton; M. Ghanem; H. W. To (1993), "Structured Parallel Programming", In Programming Models for Massively Parallel Computers. IEEE Computer Society Press. 1993: 160–169, CiteSeerX 10.1.1.37.4610

[1] Clark, Leslie B. Wilson, Robert G.; Robert, Clark (2000). Comparative programming languages (3rd ed.). Harlow, England: Addison-Wesley. p. 20. ISBN 9780201710120. Archived from the original on 26 November 2015. Retrieved 25 November 2015.

[FOOTNOTEB.C3.B6hmJacopini1966-2] Böhm & Jacopini 1966.

[FOOTNOTEDijkstra1968147-3] Dijkstra 1968, p. 147, "The unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. ... The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one's program."

[FOOTNOTEDijkstra1968-4] Dijkstra 1968.

[5] Plauger, P. J. (February 12, 1993). Programming on Purpose, Essays on Software Design (1st ed.). Prentice-Hall. p. 25. ISBN 978-0-13-721374-0.

[6] DLS • Donald Knuth • All Questions Answered. YouTube. University of Waterloo. 15 Nov 2018. 48 minutes in. Retrieved 24 July 2022.

[7] Donald E. Knuth (December 1974). "Structured programming with go to statements" (PDF). Computing Surveys. 6 (4): 261–301. doi:10.1145/356635.356640. S2CID 207630080. Archived from the original (PDF) on 2013-10-23.

[8] In EWD1308, "What led to "Notes on Structured Programming""., dated 10 June 2001, Dijkstra writes, "Apparently, IBM did not like the popularity of my text; it stole the term "Structured Programming" and under its auspices Harlan D. Mills trivialized the original concept to the abolishment of the goto statement."

[9] Frank Rubin (March 1987). ""GOTO Considered Harmful" Considered Harmful" (PDF). Communications of the ACM. 30 (3): 195–196. doi:10.1145/214748.315722. S2CID 6853038. Archived from the original (PDF) on 2009-03-20.

[10] Elder, Matt; Jackson, Steve; Liblit, Ben (October 2008). Code Sandwiches (PDF) (Technical report). University of Wisconsin–Madison. 1647.

[11] Jay Fields; Shane Harvie; Martin Fowler; Kent Beck (2009). Refactoring: Ruby Edition. Pearson Education. pp. 274–279. ISBN 978-0-321-60350-0.

[12] Herb Sutter; Andrei Alexandrescu (2004). C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Pearson Education. ISBN 978-0-13-265442-5. Example 4: Single entry, single exit ("SESE"). Historically, some coding standards have required that each function have exactly one exit, meaning one return statement. Such a requirement is obsolete in languages that support exceptions and destructors, where functions typically have numerous implicit exits.

[FOOTNOTEWattFindlay2004215.E2.80.93221-13] Watt & Findlay 2004, pp. 215–221.

[Meyer2009-14] Bertrand Meyer (2009). Touch of Class: Learning to Program Well with Objects and Contracts. Springer Science & Business Media. p. 189. ISBN 978-3-540-92144-8.

[15] "Single-Entry, Single-Exit, Should It Still be Applicable in Object-oriented Languages?". Peter Ritchie's MVP Blog. Archived from the original on 2012-11-14. Retrieved 2014-07-15.

[FOOTNOTEWattFindlay2004221.E2.80.93222-16] Watt & Findlay 2004, pp. 221–222.

[17] Kenneth C. Louden; Kenneth A. Lambert (2011). Programming Languages: Principles and Practices (3rd ed.). Cengage Learning. p. 423. ISBN 978-1-111-52941-3.

[18] Arvind Kumar Bansal (2013). Introduction to Programming Languages. CRC Press. p. 135. ISBN 978-1-4665-6514-2.

[19] Weimer, W. & Necula, G.C. (2008). "Exceptional Situations and Program Reliability" (PDF). ACM Transactions on Programming Languages and Systems. 30 (2). 8:27. doi:10.1145/1330017.1330019. S2CID 3136431. Archived from the original (PDF) on 2015-09-23.

[Chandra2001-20] Rohit Chandra (2001). Parallel Programming in OpenMP. Morgan Kaufmann. p. 45. ISBN 978-1-55860-671-5.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]