स्पेगेटी कोड: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 1: Line 1:
{{short description|Software source code with poor structure}}
{{short description|Software source code with poor structure}}
स्पेगेटी कोड असंरचित और कठिन-से-सॉफ़्टवेयर रखरखाव स्रोत कोड के लिए एक [[अपमानजनक]] वाक्यांश है। स्पेगेटी कोड कई कारकों के कारण हो सकता है, जैसे अस्थिर परियोजना आवश्यकताओं, [[प्रोग्रामिंग शैली]] के नियमों की कमी, और अपर्याप्त क्षमता या अनुभव वाले सॉफ्टवेयर इंजीनियर ।<ref name="Markus4">{{cite journal|last1=Markus|first1=Pizka|title=Straightening spaghetti-code with refactoring?|journal=Software Engineering Research and Practice|date=2004|pages=846–852|url=http://itestra.com/wp-content/uploads/2017/08/04_itestra_straightening_spaghetti_code_with_refactoring.pdf|access-date=5 March 2018|archive-date=5 March 2018|archive-url=https://web.archive.org/web/20180305202716/http://itestra.com/wp-content/uploads/2017/08/04_itestra_straightening_spaghetti_code_with_refactoring.pdf|url-status=dead}}</ref>
स्पेगेटी कोड असंरचित और जिन कोड का संरक्षित करफना कठिन है उनके लिए यह एक अपकर्षसूचक वाक्यांश है। स्पेगेटी कोड कई कारकों के कारण हो सकता है, जैसे अस्थिर परियोजना आवश्यकताएं, प्रोग्रामिंग शैली नियमों की कमी, और अपर्याप्त क्षमता या अनुभव वाले सॉफ़्टवेयर इंजीनियर है।<ref name="Markus4">{{cite journal|last1=Markus|first1=Pizka|title=Straightening spaghetti-code with refactoring?|journal=Software Engineering Research and Practice|date=2004|pages=846–852|url=http://itestra.com/wp-content/uploads/2017/08/04_itestra_straightening_spaghetti_code_with_refactoring.pdf|access-date=5 March 2018|archive-date=5 March 2018|archive-url=https://web.archive.org/web/20180305202716/http://itestra.com/wp-content/uploads/2017/08/04_itestra_straightening_spaghetti_code_with_refactoring.pdf|url-status=dead}}</ref>




== अर्थ ==
== अर्थ ==
कोड जो [[संरचित प्रोग्रामिंग]] निर्माणों के बजाय [[ के लिए जाओ ]] स्टेटमेंट्स का अत्यधिक उपयोग करता है, जिसके परिणामस्वरूप जटिल और अनुपयोगी कार्यक्रम होते हैं, अक्सर स्पेगेटी कोड कहा जाता है।<ref name="Cram5">{{cite journal|last1=Cram|first1=David|last2=Hedley|first2=Paul|title=Pronouns and procedural meaning: The relevance of spaghetti code and paranoid delusion|journal=Oxford University Working Papers in Linguistics, Philology and Phonetics|date=2005|volume=10|pages=187–210|url=http://mostlyharmless.org.uk/wp-content/uploads/2010/12/cramhedley-web.pdf|access-date=5 March 2018}}</ref>
वह कोड जो संरचित प्रोग्रामिंग संरचनाओं के बजाय GOTO कथनों का अत्यधिक उपयोग करता है, जिसके परिणामस्वरूप जटिल और अप्राप्य प्रोग्राम बनते हैं, अक्सर स्पेगेटी कोड कहा जाता है।<ref name="Cram5">{{cite journal|last1=Cram|first1=David|last2=Hedley|first2=Paul|title=Pronouns and procedural meaning: The relevance of spaghetti code and paranoid delusion|journal=Oxford University Working Papers in Linguistics, Philology and Phonetics|date=2005|volume=10|pages=187–210|url=http://mostlyharmless.org.uk/wp-content/uploads/2010/12/cramhedley-web.pdf|access-date=5 March 2018}}</ref> इस तरह के कोड में एक जटिल और पेचीदा नियंत्रण संरचना होती है, जिसके परिणामस्वरूप एक प्रोग्राम प्रवाह होता है जो वैचारिक रूप से स्पेगेटी के कटोरे की तरह मुड़ा हुआ और उलझा हुआ होता है।<ref>{{cite book|last1=Horstmann|first1=Cay|title=एपी कंप्यूटर साइंस के लिए जावा कॉन्सेप्ट्स|date=2008|publisher=J. Wiley & Sons|location=Hoboken, NJ|isbn=978-0-470-18160-7|pages=235–236|edition=5th ed. [i.e. 2nd ed.].|chapter-url=http://horstmann.com/bigjava3.html|access-date=2 January 2017|language=en|chapter=Chapter 6 - Iteration}}</ref>
इस तरह के कोड में एक जटिल और पेचीदा [[नियंत्रण संरचना]] होती है, जिसके परिणामस्वरूप एक प्रोग्राम प्रवाह होता है जो वैचारिक रूप से स्पेगेटी # सर्विंग, ट्विस्टेड और पेचीदा होता है<!-- pages 235–236 -->.<ref>{{cite book|last1=Horstmann|first1=Cay|title=एपी कंप्यूटर साइंस के लिए जावा कॉन्सेप्ट्स|date=2008|publisher=J. Wiley & Sons|location=Hoboken, NJ|isbn=978-0-470-18160-7|pages=235–236|edition=5th ed. [i.e. 2nd ed.].|chapter-url=http://horstmann.com/bigjava3.html|access-date=2 January 2017|language=en|chapter=Chapter 6 - Iteration}}</ref>
राष्ट्रीय मानक और प्रौद्योगिकी संस्थान द्वारा 1980 के प्रकाशन में, वाक्यांश स्पेगेटी प्रोग्राम का उपयोग खंडित और बिखरी हुई फाइलों वाले पुराने कार्यक्रमों का वर्णन करने के लिए किया गया था।<ref>{{cite book|title=एएसटीएम विशेष तकनीकी प्रकाशन|issue=500–565|author=United States National Bureau of Standards|publisher=United States Government Printing Office|year=1980}}</ref><!-- page 15 -->
स्पेगेटी कोड एक एंटी-पैटर्न का भी वर्णन कर सकता है जिसमें [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] | ऑब्जेक्ट-ओरिएंटेड कोड एक प्रक्रियात्मक शैली में लिखा जाता है, जैसे कि ऐसी कक्षाएं बनाकर जिनके तरीके अत्यधिक लंबे और गड़बड़ हैं, या बहुरूपता (कंप्यूटर) जैसी ऑब्जेक्ट-ओरिएंटेड अवधारणाओं को छोड़ देते हैं। विज्ञान)।<ref name="Moha10">{{cite journal|last1=Moha|first1=N.|last2=Gueheneuc|first2=Y. G.|last3=Duchien|first3=L.|last4=Meur|first4=A. F. Le|title=DECOR: A Method for the Specification and Detection of Code and Design Smells|journal=IEEE Transactions on Software Engineering|date=January 2010|volume=36|issue=1|pages=20–36|doi=10.1109/TSE.2009.50|issn=0098-5589|citeseerx=10.1.1.156.1524|s2cid=14767901}}</ref> स्पेगेटी कोड के इस रूप की उपस्थिति एक प्रणाली की बोधगम्यता को महत्वपूर्ण रूप से कम कर सकती है।<ref name="Abbes11">{{cite book|last1=Abbes|first1=M.|last2=Khomh|first2=F.|last3=Gueheneuc|first3=Y. G.|last4=Antoniol|first4=G.|title=प्रोग्राम कॉम्प्रिहेंशन पर दो एंटीपैटर्न, ब्लॉब और स्पेगेटी कोड के प्रभाव का एक अनुभवजन्य अध्ययन|journal=2011 15th European Conference on Software Maintenance and Reengineering|date=2011|pages=181–190|doi=10.1109/CSMR.2011.24|isbn=978-1-61284-259-2|citeseerx=10.1.1.294.1685|s2cid=14152638}}</ref>


राष्ट्रीय मानक और प्रौद्योगिकी संस्थान द्वारा 1980 के प्रकाशन में, वाक्यांश स्पेगेटी प्रोग्राम का उपयोग खंडित और बिखरी हुई फाइलों वाले पुराने कार्यक्रमों का वर्णन करने के लिए किया गया था।<ref>{{cite book|title=एएसटीएम विशेष तकनीकी प्रकाशन|issue=500–565|author=United States National Bureau of Standards|publisher=United States Government Printing Office|year=1980}}</ref>
स्पेगेटी कोड एक एंटी-पैटर्न का भी वर्णन कर सकता है जिसमें ऑब्जेक्ट-ओरिएंटेड कोड एक प्रक्रियात्मक शैली में लिखा जाता है, जैसे कि ऐसी कक्षाएं बनाना जिनकी विधियां अत्यधिक लंबी और गड़बड़ हैं, या बहुरूपता जैसी ऑब्जेक्ट-ओरिएंटेड अवधारणाओं को त्यागना है।<ref name="Moha10">{{cite journal|last1=Moha|first1=N.|last2=Gueheneuc|first2=Y. G.|last3=Duchien|first3=L.|last4=Meur|first4=A. F. Le|title=DECOR: A Method for the Specification and Detection of Code and Design Smells|journal=IEEE Transactions on Software Engineering|date=January 2010|volume=36|issue=1|pages=20–36|doi=10.1109/TSE.2009.50|issn=0098-5589|citeseerx=10.1.1.156.1524|s2cid=14767901}}</ref> स्पेगेटी कोड के इस रूप की उपस्थिति एक प्रणाली की बोधगम्यता को महत्वपूर्ण रूप से कम कर सकती है।<ref name="Abbes11">{{cite book|last1=Abbes|first1=M.|last2=Khomh|first2=F.|last3=Gueheneuc|first3=Y. G.|last4=Antoniol|first4=G.|title=प्रोग्राम कॉम्प्रिहेंशन पर दो एंटीपैटर्न, ब्लॉब और स्पेगेटी कोड के प्रभाव का एक अनुभवजन्य अध्ययन|journal=2011 15th European Conference on Software Maintenance and Reengineering|date=2011|pages=181–190|doi=10.1109/CSMR.2011.24|isbn=978-1-61284-259-2|citeseerx=10.1.1.294.1685|s2cid=14152638}}</ref>


== इतिहास ==
== इतिहास ==
यह स्पष्ट नहीं है कि वाक्यांश स्पेगेटी कोड कब आम उपयोग में आया; हालांकि, 1977 में गाइ एल. स्टील जूनियर द्वारा मैकरोनी इज़ बेटर दैन स्पेगेटी सहित कई संदर्भ सामने आए।<ref>Guy Lewis Steele. 1977. Macaroni is better than spaghetti. In Proceedings of the 1977 symposium on Artificial intelligence and programming languages. Association for Computing Machinery, New York, NY, USA, 60–66. DOI:https://doi.org/10.1145/800228.806933</ref> 1978 की पुस्तक ए प्राइमर ऑन डिसिप्लिन प्रोग्रामिंग यूजिंग पीएल/आई, पीएल/सीएस, और पीएल/सीटी में, रिचर्ड डब्ल्यू. कॉनवे ने उन प्रोग्रामों का वर्णन किया है जिनकी स्पेगेटी की प्लेट के समान स्वच्छ तार्किक संरचना है,<ref>{{cite book|title=A primer on disciplined programming using PL/I, PL/CS, and PL/CT|last=Conway|first=Richard|publisher=Winthrop Publishers|year=1978|isbn=978-0-87626-712-7}}</ref><!-- page 186 --> 1979 की पुस्तक एन इंट्रोडक्शन टू प्रोग्रामिंग में दोहराया गया एक वाक्यांश जिसे उन्होंने [[डेविड ग्रिस]] के साथ सह-लेखक बनाया था।<ref>{{cite book|title=प्रोग्रामिंग का एक परिचय|last1=Conway|first1=Richard|last2=Gries|first2=David|edition=3rd|publisher=Little, Brown|year=1979|isbn=978-0-316-15414-7}}</ref><!-- page 158 --> 1988 के पेपर ए स्पाइरल मॉडल ऑफ सॉफ्टवेयर डेवलपमेंट एंड एन्हांसमेंट में, शब्द का उपयोग कोड और फिक्स मॉडल के पुराने अभ्यास का वर्णन करने के लिए किया जाता है, जिसमें योजना की कमी थी और अंततः जलप्रपात मॉडल के विकास का नेतृत्व किया।<ref>{{cite journal|journal=IEEE Computer|title=सॉफ्टवेयर विकास और वृद्धि का एक सर्पिल मॉडल|last=Boehm|first=Barry W.|volume=21|issue=2|date=May 1988|pages=61–72|doi=10.1109/2.59|s2cid=1781829}}</ref><!-- page 63 --> कोबोल प्रोग्रामर के लिए 1979 की पुस्तक स्ट्रक्चर्ड प्रोग्रामिंग में, लेखक पॉल नोल खराब संरचित स्रोत कोड का वर्णन करने के लिए समानार्थक शब्द स्पेगेटी कोड और चूहे के घोंसले का उपयोग करते हैं।<ref>{{cite book|title=Structured programming for the COBOL programmer: design, documentation, coding, testing|last=Noll|first=Paul|publisher=M. Murach & Associates|year=1977}}</ref><!-- page 15 -->
यह स्पष्ट नहीं है कि स्पेगेटी कोड वाक्यांश आम उपयोग में कब आया; हालाँकि, 1977 में गाइ स्टील की मैकरोनी इज़ बेटर दैन स्पेगेटी सहित कई संदर्भ सामने आए।<ref>Guy Lewis Steele. 1977. Macaroni is better than spaghetti. In Proceedings of the 1977 symposium on Artificial intelligence and programming languages. Association for Computing Machinery, New York, NY, USA, 60–66. DOI:https://doi.org/10.1145/800228.806933</ref> 1978 की पुस्तक ए प्राइमर ऑन डिसिप्लिन्ड प्रोग्रामिंग यूजिंग पीएल/आई, पीएल/सीएस, एंड पीएल/सीटी में, रिचर्ड कॉनवे ने उन प्रोग्रामों का वर्णन किया है जिनकी "स्पेगेटी की प्लेट के समान स्वच्छ तार्किक संरचना होती है",<ref>{{cite book|title=A primer on disciplined programming using PL/I, PL/CS, and PL/CT|last=Conway|first=Richard|publisher=Winthrop Publishers|year=1978|isbn=978-0-87626-712-7}}</ref><!-- page 186 --> एक वाक्यांश दोहराया गया है 1979 की पुस्तक एन इंट्रोडक्शन टू प्रोग्रामिंग उन्होंने डेविड ग्रिज़ के साथ मिलकर लिखी थी।<ref>{{cite book|title=प्रोग्रामिंग का एक परिचय|last1=Conway|first1=Richard|last2=Gries|first2=David|edition=3rd|publisher=Little, Brown|year=1979|isbn=978-0-316-15414-7}}</ref><!-- page 158 --> 1988 के पेपर ए स्पाइरल मॉडल ऑफ सॉफ्टवेयर डेवलपमेंट एंड एन्हांसमेंट में, इस शब्द का उपयोग कोड और फिक्स मॉडल के पुराने अभ्यास का वर्णन करने के लिए किया गया है, जिसमें योजना की कमी थी और अंततः वॉटरफॉल मॉडल का विकास हुआ।<ref>{{cite journal|journal=IEEE Computer|title=सॉफ्टवेयर विकास और वृद्धि का एक सर्पिल मॉडल|last=Boehm|first=Barry W.|volume=21|issue=2|date=May 1988|pages=61–72|doi=10.1109/2.59|s2cid=1781829}}</ref><!-- page 63 --> 1979 की पुस्तक स्ट्रक्चर्ड प्रोग्रामिंग फॉर द COBOL प्रोग्रामर में, लेखक पॉल नोल ने खराब संरचित स्रोत कोड का वर्णन करने के लिए स्पेगेटी कोड और चूहे के घोंसले वाक्यांशों को पर्यायवाची के रूप में उपयोग किया है।<ref>{{cite book|title=Structured programming for the COBOL programmer: design, documentation, coding, testing|last=Noll|first=Paul|publisher=M. Murach & Associates|year=1977}}</ref><!-- page 15 -->
 
Ada - यूरोप '93 सम्मेलन में, Ada (प्रोग्रामिंग भाषा) को अपने प्रतिबंधात्मक अपवाद प्रचार तंत्र के कारण स्पेगेटी कोड के बजाय समझने योग्य बनाने के लिए प्रोग्रामर को मजबूर करने के रूप में वर्णित किया गया था।<ref>{{cite conference|conference=Ada – Europe '93 (Proceedings)|book-title=Lecture Notes in Computer Science|title=Use and abuse of exceptions — 12 guidelines for proper exception handling|last=Schwille|first=Jürgen |series=Lecture Notes in Computer Science |volume=688|year=1993|publisher=Springer Berlin Heidelberg|pages=142–152|doi=10.1007/3-540-56802-6_12|isbn=978-3-540-56802-5 }}</ref>
Ada - यूरोप '93 सम्मेलन में, Ada (प्रोग्रामिंग भाषा) को अपने प्रतिबंधात्मक अपवाद प्रचार तंत्र के कारण स्पेगेटी कोड के बजाय समझने योग्य बनाने के लिए प्रोग्रामर को मजबूर करने के रूप में वर्णित किया गया था।<ref>{{cite conference|conference=Ada – Europe '93 (Proceedings)|book-title=Lecture Notes in Computer Science|title=Use and abuse of exceptions — 12 guidelines for proper exception handling|last=Schwille|first=Jürgen |series=Lecture Notes in Computer Science |volume=688|year=1993|publisher=Springer Berlin Heidelberg|pages=142–152|doi=10.1007/3-540-56802-6_12|isbn=978-3-540-56802-5 }}</ref>
1981 में द मिशिगन टेक्निक में बेसिकली स्पीकिंग...[[फोरट्रान]] बाइट्स शीर्षक वाले कंप्यूटर लैंग्वेज स्पूफ!! , लेखक ने फोरट्रान का वर्णन करते हुए कहा कि इसमें पूरी तरह से स्पेगेटी कोड शामिल है।<ref>{{cite journal|journal=The Michigan Technic|title=मूल रूप से बोल रहा हूँ ... फोरट्रान बाइट्स !!|author=MTSBS{{clarify|date=April 2015}}|
 
1981 में द मिशिगन टेक्निक में बेसिकली स्पीकिंग...[[फोरट्रान]] बाइट्स शीर्षक वाले कंप्यूटर लैंग्वेज स्पूफ!!, लेखक ने फोरट्रान का वर्णन करते हुए कहा कि इसमें पूरी तरह से स्पेगेटी कोड शामिल है।<ref>{{cite journal|journal=The Michigan Technic|title=मूल रूप से बोल रहा हूँ ... फोरट्रान बाइट्स !!|author=MTSBS{{clarify|date=April 2015}}|
volume=99|issue=4|date=March–April 1981}}</ref><!-- page 18 -->
volume=99|issue=4|date=March–April 1981}}</ref><!-- page 18 -->
[[रिचर्ड हैमिंग]] ने अपने व्याख्यानों में इसका वर्णन किया है<ref>{{cite book |last1=Hamming |first1=Richard |title=विज्ञान और इंजीनियरिंग करने की कला|date=1996 |isbn=9056995006}}</ref> बाइनरी कोड में शुरुआती प्रोग्रामिंग के संदर्भ में शब्द की व्युत्पत्ति:
[[रिचर्ड हैमिंग]] ने अपने व्याख्यानों में इसका वर्णन किया है<ref>{{cite book |last1=Hamming |first1=Richard |title=विज्ञान और इंजीनियरिंग करने की कला|date=1996 |isbn=9056995006}}</ref> बाइनरी कोड में शुरुआती प्रोग्रामिंग के संदर्भ में शब्द की व्युत्पत्ति:


{{Quote
{{Quote
|text=If, in fixing up an error, you wanted to insert some omitted instructions then you took the immediately preceding instruction and replaced it by a transfer to some empty space. There you put in the instruction you just wrote over, added the instructions you wanted to insert, and then followed by a transfer back to the main program. Thus the program soon became a sequence of jumps of the control to strange places. When, as almost always happens, there were errors in the corrections you then used the same trick again, using some other available space. As a result ''the control path of the program through storage soon took on the appearance of a can of spaghetti.'' Why not simply insert them in the run of instructions? Because then you would have to go over the entire program and change all the addresses which referred to any of the moved instructions! Anything but that!
|text=If, in fixing up an error, you wanted to insert some omitted instructions then you took the immediately preceding instruction and replaced it by a transfer to some empty space. There you put in the instruction you just wrote over, added the instructions you wanted to insert, and then followed by a transfer back to the main program. Thus the program soon became a sequence of jumps of the control to strange places. When, as almost always happens, there were errors in the corrections you then used the same trick again, using some other available space. As a result ''the control path of the program through storage soon took on the appearance of a can of spaghetti.'' Why not simply insert them in the run of instructions? Because then you would have to go over the entire program and change all the addresses which referred to any of the moved instructions! Anything but that!
यदि, किसी त्रुटि को ठीक करने में, आप कुछ छोड़े गए निर्देशों को सम्मिलित करना चाहते थे तो आपने तुरंत पूर्ववर्ती निर्देश ले लिया और इसे कुछ खाली स्थान पर स्थानांतरित करके बदल दिया। वहां आपने वह निर्देश डाला जो आपने अभी लिखा था, जो निर्देश आप सम्मिलित करना चाहते थे उसे जोड़ा, और उसके बाद मुख्य कार्यक्रम में वापस स्थानांतरित कर दिया। इस प्रकार यह कार्यक्रम जल्द ही अजीब स्थानों पर नियंत्रण की छलांग का एक क्रम बन गया। जब, जैसा कि लगभग हमेशा होता है, सुधारों में त्रुटियाँ थीं तो आपने कुछ अन्य उपलब्ध स्थान का उपयोग करके, उसी युक्ति का दोबारा उपयोग किया। परिणामस्वरूप ''भंडारण के माध्यम से प्रोग्राम का नियंत्रण पथ जल्द ही स्पेगेटी के डिब्बे जैसा दिखने लगा।'' क्यों न उन्हें निर्देशों के क्रम में ही सम्मिलित कर दिया जाए? क्योंकि तब आपको पूरे कार्यक्रम पर जाना होगा और उन सभी पतों को बदलना होगा जो किसी भी स्थानांतरित निर्देश को संदर्भित करते हैं! उसके अलावा कुछ भी!
}}
}}


Revision as of 20:08, 24 June 2023

स्पेगेटी कोड असंरचित और जिन कोड का संरक्षित करफना कठिन है उनके लिए यह एक अपकर्षसूचक वाक्यांश है। स्पेगेटी कोड कई कारकों के कारण हो सकता है, जैसे अस्थिर परियोजना आवश्यकताएं, प्रोग्रामिंग शैली नियमों की कमी, और अपर्याप्त क्षमता या अनुभव वाले सॉफ़्टवेयर इंजीनियर है।[1]


अर्थ

वह कोड जो संरचित प्रोग्रामिंग संरचनाओं के बजाय GOTO कथनों का अत्यधिक उपयोग करता है, जिसके परिणामस्वरूप जटिल और अप्राप्य प्रोग्राम बनते हैं, अक्सर स्पेगेटी कोड कहा जाता है।[2] इस तरह के कोड में एक जटिल और पेचीदा नियंत्रण संरचना होती है, जिसके परिणामस्वरूप एक प्रोग्राम प्रवाह होता है जो वैचारिक रूप से स्पेगेटी के कटोरे की तरह मुड़ा हुआ और उलझा हुआ होता है।[3]

राष्ट्रीय मानक और प्रौद्योगिकी संस्थान द्वारा 1980 के प्रकाशन में, वाक्यांश स्पेगेटी प्रोग्राम का उपयोग खंडित और बिखरी हुई फाइलों वाले पुराने कार्यक्रमों का वर्णन करने के लिए किया गया था।[4]

स्पेगेटी कोड एक एंटी-पैटर्न का भी वर्णन कर सकता है जिसमें ऑब्जेक्ट-ओरिएंटेड कोड एक प्रक्रियात्मक शैली में लिखा जाता है, जैसे कि ऐसी कक्षाएं बनाना जिनकी विधियां अत्यधिक लंबी और गड़बड़ हैं, या बहुरूपता जैसी ऑब्जेक्ट-ओरिएंटेड अवधारणाओं को त्यागना है।[5] स्पेगेटी कोड के इस रूप की उपस्थिति एक प्रणाली की बोधगम्यता को महत्वपूर्ण रूप से कम कर सकती है।[6]

इतिहास

यह स्पष्ट नहीं है कि स्पेगेटी कोड वाक्यांश आम उपयोग में कब आया; हालाँकि, 1977 में गाइ स्टील की मैकरोनी इज़ बेटर दैन स्पेगेटी सहित कई संदर्भ सामने आए।[7] 1978 की पुस्तक ए प्राइमर ऑन डिसिप्लिन्ड प्रोग्रामिंग यूजिंग पीएल/आई, पीएल/सीएस, एंड पीएल/सीटी में, रिचर्ड कॉनवे ने उन प्रोग्रामों का वर्णन किया है जिनकी "स्पेगेटी की प्लेट के समान स्वच्छ तार्किक संरचना होती है",[8] एक वाक्यांश दोहराया गया है 1979 की पुस्तक एन इंट्रोडक्शन टू प्रोग्रामिंग उन्होंने डेविड ग्रिज़ के साथ मिलकर लिखी थी।[9] 1988 के पेपर ए स्पाइरल मॉडल ऑफ सॉफ्टवेयर डेवलपमेंट एंड एन्हांसमेंट में, इस शब्द का उपयोग कोड और फिक्स मॉडल के पुराने अभ्यास का वर्णन करने के लिए किया गया है, जिसमें योजना की कमी थी और अंततः वॉटरफॉल मॉडल का विकास हुआ।[10] 1979 की पुस्तक स्ट्रक्चर्ड प्रोग्रामिंग फॉर द COBOL प्रोग्रामर में, लेखक पॉल नोल ने खराब संरचित स्रोत कोड का वर्णन करने के लिए स्पेगेटी कोड और चूहे के घोंसले वाक्यांशों को पर्यायवाची के रूप में उपयोग किया है।[11]

Ada - यूरोप '93 सम्मेलन में, Ada (प्रोग्रामिंग भाषा) को अपने प्रतिबंधात्मक अपवाद प्रचार तंत्र के कारण स्पेगेटी कोड के बजाय समझने योग्य बनाने के लिए प्रोग्रामर को मजबूर करने के रूप में वर्णित किया गया था।[12]

1981 में द मिशिगन टेक्निक में बेसिकली स्पीकिंग...फोरट्रान बाइट्स शीर्षक वाले कंप्यूटर लैंग्वेज स्पूफ!!, लेखक ने फोरट्रान का वर्णन करते हुए कहा कि इसमें पूरी तरह से स्पेगेटी कोड शामिल है।[13]

रिचर्ड हैमिंग ने अपने व्याख्यानों में इसका वर्णन किया है[14] बाइनरी कोड में शुरुआती प्रोग्रामिंग के संदर्भ में शब्द की व्युत्पत्ति:

If, in fixing up an error, you wanted to insert some omitted instructions then you took the immediately preceding instruction and replaced it by a transfer to some empty space. There you put in the instruction you just wrote over, added the instructions you wanted to insert, and then followed by a transfer back to the main program. Thus the program soon became a sequence of jumps of the control to strange places. When, as almost always happens, there were errors in the corrections you then used the same trick again, using some other available space. As a result the control path of the program through storage soon took on the appearance of a can of spaghetti. Why not simply insert them in the run of instructions? Because then you would have to go over the entire program and change all the addresses which referred to any of the moved instructions! Anything but that!


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

संबंधित वाक्यांश

रैवियोली कोड

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


लसग्ना कोड

See also: Architectural layer and Layer (object-oriented design)

Lasagna कोड उस कोड को संदर्भित करता है जिसकी परतें इतनी जटिल और आपस में गुंथी हुई हैं कि एक परत में परिवर्तन करने से अन्य सभी परतों में परिवर्तन की आवश्यकता होगी।[16]


उदाहरण

बुनियादी प्रोग्रामिंग भाषा में स्पेगेटी कोड का एक तुच्छ उदाहरण माना जाएगा। कार्यक्रम प्रत्येक संख्या को 1 से 100 तक स्क्रीन पर उसके वर्ग के साथ प्रिंट करता है। इंडेंटेशन का उपयोग कोड और प्रोग्राम द्वारा की जाने वाली विभिन्न क्रियाओं में अंतर करने के लिए नहीं किया जाता है GOTO बयान लाइन नंबरों पर निर्भरता पैदा करते हैं। एक क्षेत्र से दूसरे क्षेत्र में निष्पादन के प्रवाह की भविष्यवाणी करना कठिन है। स्पेगेटी कोड की वास्तविक दुनिया में होने वाली घटनाएँ अधिक जटिल हैं और कार्यक्रम के रखरखाव की लागत में बहुत अधिक वृद्धि कर सकती हैं। 

1 i=0;
2 i=i+1;
3 PRINT i; "squared=";i*i;
4 IF i>=100 THEN GOTO 6;
5 GOTO 2;
6 PRINT "Program Completed.";
7 END

यहाँ एक संरचित प्रोग्रामिंग शैली में लिखा गया समान कोड है: 

1 FOR i=1 TO 100
2     PRINT i;"squared=";i*i
3 NEXT i
4 PRINT "Program Completed."
5 END

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

यहाँ एम्बेडेड GOTO कथनों के साथ स्पेगेटी कोड का एक और उदाहरण दिया गया है। 

  INPUT "How many numbers should be sorted? "; T
  DIM n(T)
  FOR i = 1 TO T
    PRINT "NUMBER:"; i
    INPUT n(i)
  NEXT i
  'Calculations:
  C = T
 E180:
  C = INT(C / 2)
  IF C = 0 THEN GOTO C330
  D = T - C
  E = 1
 I220:
  f = E
 F230:
  g = f + C
  IF n(f) > n(g) THEN SWAP n(f), n(g)
  f = f - C
  IF f > 0 THEN GOTO F230
  E = E + 1
  IF E > D THEN GOTO E180
 GOTO I220
 C330:
  PRINT "The sorted list is"
  FOR i = 1 TO T
    PRINT n(i)
  NEXT i


यह भी देखें

संदर्भ

  1. ↑ Markus, Pizka (2004). "Straightening spaghetti-code with refactoring?" (PDF). Software Engineering Research and Practice: 846–852. Archived from the original (PDF) on 5 March 2018. Retrieved 5 March 2018.
  2. ↑ Cram, David; Hedley, Paul (2005). "Pronouns and procedural meaning: The relevance of spaghetti code and paranoid delusion" (PDF). Oxford University Working Papers in Linguistics, Philology and Phonetics. 10: 187–210. Retrieved 5 March 2018.
  3. ↑ Horstmann, Cay (2008). "Chapter 6 - Iteration". एपी कंप्यूटर साइंस के लिए जावा कॉन्सेप्ट्स (in English) (5th ed. [i.e. 2nd ed.]. ed.). Hoboken, NJ: J. Wiley & Sons. pp. 235–236. ISBN 978-0-470-18160-7. Retrieved 2 January 2017.
  4. ↑ United States National Bureau of Standards (1980). एएसटीएम विशेष तकनीकी प्रकाशन. United States Government Printing Office.
  5. ↑ Moha, N.; Gueheneuc, Y. G.; Duchien, L.; Meur, A. F. Le (January 2010). "DECOR: A Method for the Specification and Detection of Code and Design Smells". IEEE Transactions on Software Engineering. 36 (1): 20–36. CiteSeerX 10.1.1.156.1524. doi:10.1109/TSE.2009.50. ISSN 0098-5589. S2CID 14767901.
  6. ↑ Abbes, M.; Khomh, F.; Gueheneuc, Y. G.; Antoniol, G. (2011). प्रोग्राम कॉम्प्रिहेंशन पर दो एंटीपैटर्न, ब्लॉब और स्पेगेटी कोड के प्रभाव का एक अनुभवजन्य अध्ययन. pp. 181–190. CiteSeerX 10.1.1.294.1685. doi:10.1109/CSMR.2011.24. ISBN 978-1-61284-259-2. S2CID 14152638. {{cite book}}: |journal= ignored (help)
  7. ↑ Guy Lewis Steele. 1977. Macaroni is better than spaghetti. In Proceedings of the 1977 symposium on Artificial intelligence and programming languages. Association for Computing Machinery, New York, NY, USA, 60–66. DOI:https://doi.org/10.1145/800228.806933
  8. ↑ Conway, Richard (1978). A primer on disciplined programming using PL/I, PL/CS, and PL/CT. Winthrop Publishers. ISBN 978-0-87626-712-7.
  9. ↑ Conway, Richard; Gries, David (1979). प्रोग्रामिंग का एक परिचय (3rd ed.). Little, Brown. ISBN 978-0-316-15414-7.
  10. ↑ Boehm, Barry W. (May 1988). "सॉफ्टवेयर विकास और वृद्धि का एक सर्पिल मॉडल". IEEE Computer. 21 (2): 61–72. doi:10.1109/2.59. S2CID 1781829.
  11. ↑ Noll, Paul (1977). Structured programming for the COBOL programmer: design, documentation, coding, testing. M. Murach & Associates.
  12. ↑ Schwille, Jürgen (1993). "Use and abuse of exceptions — 12 guidelines for proper exception handling". Lecture Notes in Computer Science. Ada – Europe '93 (Proceedings). Lecture Notes in Computer Science. Vol. 688. Springer Berlin Heidelberg. pp. 142–152. doi:10.1007/3-540-56802-6_12. ISBN 978-3-540-56802-5.
  13. ↑ MTSBS[clarification needed] (March–April 1981). "मूल रूप से बोल रहा हूँ ... फोरट्रान बाइट्स !!". The Michigan Technic. 99 (4).{{cite journal}}: CS1 maint: multiple names: authors list (link)
  14. ↑ Hamming, Richard (1996). विज्ञान और इंजीनियरिंग करने की कला. ISBN 9056995006.
  15. ↑ Troyer, O. De (13 May 1991). "The OO-binary relationship model : A truly object oriented conceptual model". pp. 561–578. doi:10.1007/3-540-54059-8_104. ISBN 978-3-319-98176-5. S2CID 10894568. {{cite book}}: |journal= ignored (help); Missing or empty |title= (help)
  16. ↑ Tomov, Latchezar; Ivanova, Valentina (October 2014). "काउंटरएक्सप्लेम्स द्वारा सॉफ्टवेयर इंजीनियरिंग में अच्छे अभ्यास सिखाना". Computer Science and Education in Computer Science (1): 397–405. Retrieved 5 March 2018.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=स्पेगेटी_कोड&oldid=204921’