ब्लॉक के लिए स्पष्ट मार्करों पर एक भाषा को इंडेंटेशन क्यों पसंद करना चाहिए?

Question

मैं हास्केल सीख रहा हूं, और मैं एक ऑटो इंडेंटेशन टूल की तलाश कर रहा था। मैंने बहुत कुछ नहीं देखा, और सीखा कि हास्केल (पाइथन के रूप में), इंडेंटेशन एक ब्लॉक को दर्शाता है। नतीजतन, मैं अनुमान लगा रहा हूं कि ऑटो फ़ार्मेटिंग टूल बनाना असंभव है, सी परिवार में अन्य भाषाओं की तरह मजबूत है, जो कि स्पष्ट मार्कर (जैसे {} (घुंघराले ब्रेस) या begin endकीवर्ड का उपयोग करते हैं।

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

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

भाषा डिजाइनर स्पष्ट ब्लॉक मार्करों पर इंडेंटेशन का चयन क्यों करेगा?

Comments

एक उत्तर नहीं है, लेकिन हास्केल व्हाईटस्पेस संवेदनशीलता को अजगर की तुलना में बहुत अधिक वैकल्पिक बनाता है । आप अधिकांश चीजों के लिए अर्धविरामों का उपयोग कर सकते हैं, और यदि वांछित हो तो घुंघराले ब्रेस में ब्लॉक लपेट सकते हैं। let x =1; y = 2; z = 3पूरी तरह से मान्य है, जैसा है do { putStrLn $ show x; putStrLn $ show y; putStrLn $ show z; }। वे एक ही लाइन पर होने की जरूरत नहीं है।

— KChaloux

"ऑटो फ़ॉर्मेटिंग टूल बनाना असंभव है" - वास्तव में, इंडेंटेशन नियमों के कारण पायथन में ऐसे ऑटो फॉर्मेटिंग टूल की कोई आवश्यकता नहीं है।

— डॉक्टर ब्राउन

उम, में वृद्धि खरोज है एक स्पष्ट ब्लॉक मार्कर।

— कार्ल बेवेलफेल्ट

@ K.Gkinis: भाषा डिजाइन निर्णय के पीछे सटीक प्रेरणा के लिए सबसे अच्छा स्रोत भाषा डिजाइनर खुद हैं।

— रॉबर्ट हार्वे

यह प्रश्न वास्तव में व्यक्तिपरक नहीं है। यह पूछता है कि कुछ भाषा डिजाइनरों ने एक निश्चित वाक्यविन्यास क्यों चुना। इसका उत्तर दिया जा सकता है। यदि प्रश्न पूछा गया था कि कौन सा वाक्यविन्यास सबसे अच्छा है , तो यह व्यक्तिपरक होगा।

— जैक्सबी

Answer 1

गुइडो वॉन रोसुम

गुइडो वान रोसुम के साथ एक साक्षात्कार से , जिसे books.google.com (जोर मेरा) के साथ पूर्ण संदर्भ में देखा जा सकता है :

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

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

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

रोसुम ने समूहन और इंडेंट के बीच असंगतता के कारण बग को भी देखा, और जाहिर तौर पर हालांकि कोड को संरचना करने के लिए केवल इंडेंटेशन पर भरोसा करना प्रोग्रामिंग त्रुटियों ¹ से सुरक्षित होगा ।

डोनाल्ड ई। नूथ और पीटर जे। लैंडिन

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

---

_{1. मुझे लगता है कि यह वास्तव में प्रोग्रामिंग त्रुटियों से पकड़ने और पुनर्प्राप्त करने के लिए समूह निर्माण और ऑटो-स्वरूपण दोनों के पक्ष में एक तर्क है , जो होने के लिए बाध्य हैं। यदि आप पायथन में अपना इंडेंटेशन खराब करते हैं, तो आपके कोड को डिबग करने वाले व्यक्ति को अनुमान लगाना होगा कि कौन सा सही है:}

if (test(x)):
  foo(x)
  bar(x)

_{दूँ barहमेशा कहा जा या केवल परीक्षण सफल होने के तो क्या होगा?}

_{समूह निर्माण, अतिरेक का एक स्तर जोड़ते हैं जो आपको अपने कोड को ऑटो-इंडेंट करने में गलती करने में मदद करते हैं। सी में, समतुल्य कोड निम्न प्रकार से ऑटो-इंडेंट किया जा सकता है:}

if (test(x))
  foo(x);
bar(x);

_{अगर मैं barउसी स्तर पर रहने का इरादा रखता हूं foo, तो कोड संरचना के आधार पर ऑटो-इंडेंटिंग मुझे यह देखने देता है कि कुछ गड़बड़ है जिसे चारों ओर ब्रेसिज़ जोड़कर ठीक किया जा सकता है fooऔर bar।}

_{में अजगर: मिथकों इंडेंटेशन के बारे में , वहाँ सी से एक माना जाता है कि बुरा उदाहरण है:}

/*  Warning:  bogus C code!  */

if (some condition)
        if (another condition)
                do_something(fancy);
else
        this_sucks(badluck);

_{उपरोक्त जैसा ही मामला है, Emacs में, मैं पूरे ब्लॉक / फ़ंक्शन को हाइलाइट करता हूं, टैब को दबाता हूं, और फिर सभी कोड को रीवाइंड किया जाता है। मानव इंडेंटेशन और कोड संरचना के बीच विसंगति मुझे बताती है कि कुछ बंद है (और पूर्ववर्ती टिप्पणी!)।}

_{इसके अलावा, मध्यवर्ती कोड जहां इंडेंटेशन सी में बंद है बस मास्टर शाखा के माध्यम से इसे नहीं बनाता है, जगह में सभी शैली की जांच जीसीसी / जेनकिंस मुझ पर चिल्लाएगी। मुझे हाल ही में पायथन में ऊपर वर्णित एक के समान एक समस्या थी, एक स्तर के इंडेंटेशन द्वारा एक बयान के साथ। कभी-कभी मेरे पास सी में कोड होता है जो एक समापन ब्रेस से परे होता है, लेकिन फिर मैंने टैब मारा और कोड "गलत तरीके से" संकेत देता है: यह बग को देखने का एक और मौका है।}

Comments

"धार्मिक युद्धों से बचने के लिए ..." मुझे आश्चर्य है कि सही कारण इतना तुच्छ है।

— रॉबर्ट हार्वे

@ रॉबर्टहर्वे: इस वाक्यांश पर जोर कॉरडम्प द्वारा है, न कि वैन रोसुम द्वारा। यदि आप संदर्भ में वैन रोसुम उद्धरण पढ़ते हैं तो यह प्राथमिक कारण नहीं है।

— जैक्सबी

@JacquesB कृपया मुझे बताएं कि कौन सा संदर्भ उद्धरण से गायब है, ताकि मैं उत्तर को संपादित कर सकूं।

— coredump

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

— जैक्सबी

@JacquesB क्योंकि एक बंद कंस टाइप करना कुछ ऐसा है जो आप सक्रिय रूप से करते हैं; पर्याप्त नहीं है कि आप कुछ करना भूल सकते हैं। बेशक आप सही समय पर ब्रेस को बंद करना भूल सकते हैं, लेकिन आपको इसे अंततः करना होगा और इसके बारे में सोचने का एक और मौका मिलेगा। मुझे लगता है कि अजगर शुरुआत के लिए अच्छा काम करता है क्योंकि यह इंडेंटेशन पर ध्यान देने पर मजबूर करता है।

— मस्ताटो

Answer 2

यह अत्यधिक व्यक्तिपरक है और कई लौ युद्ध का कारण है। तथापि:

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

पायथन डिज़ाइन और इतिहास FAQ यह बहुत स्पष्ट रूप से बताता है:

पायथन बयानों के समूहन के लिए इंडेंटेशन का उपयोग क्यों करता है?

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

चूँकि वहाँ कोई आरंभ / अंत कोष्ठक नहीं हैं, इसलिए पार्सर और मानव पाठक द्वारा कथित समूहन के बीच असहमति नहीं हो सकती है।

यह सच है कि आप पायथन के लिए एक ऑटो इंडेंटेशन टूल नहीं बना सकते हैं, लेकिन यह एक अच्छी बात है: इसका मतलब है कि आपके पास सिंटैक्स में अतिरेक नहीं है, जिसे समेटने के लिए आपको स्वचालित टूल की आवश्यकता होती है।

पायस में रिक्त स्थान बनाम टैब एक वैध चिंता का विषय है, और एक ही कोडबेस में टैब और रिक्त स्थान (इंडेंटेशन के लिए) को कभी नहीं मिलाने की सिफारिश की गई है।

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

Comments

डबल-एंट्री अकाउंटिंग DRY का भी उल्लंघन करता है। अतिरेक कभी-कभी एक विशेषता है।

— coredump

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

— जैक्सबी

@ कॉर्डम्प - अब मुझे पता है कि मैं अकाउंटेंट क्यों नहीं हूं।

— जेफ़ओ

@coredump आपको COBOL की PROCEDURE DIVISION.भी याद आती है? मैं कभी नहीं बता सकता कि DATA DIVISIONइन नए भाषाओं में अंत कहां और प्रक्रियाएं कहां से शुरू होती हैं।

— msw

@coredump: "इंडेंटेशन विरोधाभासों को देखकर जो मेरे मन में था वह त्रुटियों को रोकने के लिए पर्याप्त है" - बिल्कुल।

— जैक्सबी

Answer 3

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

Comments

मैं देख सकता हूं कि क्यों अर्धविराम और घुंघराले ब्रेस शोर पर विचार करेगा। लेकिन क्या यह 4/8/12 बार स्थान टाइप करने के लिए कम उत्पादक नहीं है? और यदि आप एक को याद करते हैं (क्योंकि वे अदृश्य हैं) तो आप मुसीबत में हैं।

— मोनिका

इसलिए आप रिक्त स्थान के बजाय टैब का उपयोग करते हैं, या एक आईडीई जो समझता है कि टैब को चार-स्पेस ब्लॉक में कैसे परिवर्तित किया जाए।

— रॉबर्ट हार्वे

@ K.Gkinis: संकेतक अदृश्य नहीं हैं। लाइनों के सिरों पर केवल व्हाट्सएप अदृश्य है, लेकिन यह किसी भी भाषा में महत्वपूर्ण नहीं है। यदि आप टैब और रिक्त स्थान मिलाते हैं तो ही आप परेशानी में पड़ेंगे। तो ऐसा मत करो।

— जैक्सबी

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

— ब्रायन ओकले

@BryanOakley: हाँ, यही कारण है कि आपको इंडेंटेशन में टैब और रिक्त स्थान नहीं मिलाना चाहिए।

— जैक्सबी