इंडेंटेशन शैली: Difference between revisions

Revision as of 18:20, 2 March 2023

कंप्यूटर प्रोग्रामिंग में एक इंडेंटेशन शैली प्रोग्राम संरचना को संप्रेषित करने के लिए कोड के ब्लॉक (प्रोग्रामिंग) के इंडेंटेशन (टाइपसेटिंग) को नियंत्रित करने वाला एक सम्मेलन है। यह लेख मोटे तौर पर फ्री-फॉर्म भाषाओं को संबोधित करता है जैसे [[सी (प्रोग्रामिंग भाषा)]] और इसके वंश लेकिन अधिकांश अन्य प्रोग्रामिंग भाषाओं (विशेष रूप से घुंघराले ब्रैकेट प्रोग्रामिंग भाषा में) पर लागू हो सकते हैं जहां व्हॉट्सएप वर्ण है अन्यथा नगण्य। इंडेंटेशन शैली प्रोग्रामिंग शैली का केवल एक पहलू है।

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

इस लेख में कोष्ठक को संदर्भित करने के लिए शब्द कोष्ठक का उपयोग किया गया है और कर्ली कोष्ठक को संदर्भित करने के लिए शब्द कोष्ठक का उपयोग किया गया है।

यौगिक कथनो में ब्रेस प्लेसमेंट

इंडेंटेशन शैली के बीच मुख्य अंतर यौगिक कथन के ब्रेसेस लगाने में निहित है ({...}) जो अक्सर एक नियंत्रण कथन का अनुसरण करता है (if, while, for...). नीचे दी गई तालिका इस आलेख में चर्चा की गई बयानों की शैली के लिए इस प्लेसमेंट को दर्शाती है; कार्य घोषणा शैली एक और स्थितिया है। बयानों में ब्रेस प्लेसमेंट की शैली कार्य परिभाषा के ब्रेस प्लेसमेंट की शैली से भिन्न हो सकती है। स्थिरता के लिए प्रत्येक शैली की पसंदीदा इंडेंटेशन गहराई के बजाय इंडेंटेशन गहराई को 4 रिक्त स्थान पर स्थिर रखा गया है।

ब्रेस प्लेसमेंट	शैलियों
जबकि ( एक्स == वाई ) { कुछ (); कुछ और (); }	सभी मर्द
जबकि ( एक्स == वाई ) { कुछ (); कुछ और (); }	के एंड आर
जबकि ( एक्स == वाई ) { कुछ (); कुछ और (); }	जीएनयू
जबकि ( एक्स == वाई ) { कुछ (); कुछ और (); }	गोरे लोग
जबकि ( एक्स == वाई ) { कुछ (); कुछ और (); }	होर्स्टमैन
जबकि ( एक्स == वाई ) { कुछ (); कुछ और (); }	पिको
जबकि ( एक्स == वाई ) { कुछ (); कुछ और (); }	रैटलिफ
जबकि ( एक्स == वाई ) { कुछ (); कुछ और (); }	तुतलाना
# परिभाषित डब्ल्यू (सी, बी) {जबकि (सी) {बी}} डब्ल्यू ( एक्स == वाई , एस (); से ();)	एपीएल

टैब, रिक्त स्थान और इंडेंटेशन का आकार

टैब के लिए प्रदर्शित चौड़ाई अधिकांश प्रोग्रामिंग संपादकों में मनमाने मूल्यों पर सेट की जा सकती है जिसमें Notepad++ (एमएस-विंडोज), TextEdit (MacOS/X), Emacs (यूनिक्स), vi (यूनिक्स), और nano (यूनिक्स) सम्मिलित हैं। इसके अतिरिक्त इन संपादकों को विशिष्ट इंडेंटेशन योजनाओं से मेल खाने के लिए टैब और रिक्त स्थान का मिश्रण उत्पन्न करने या टैब और रिक्त स्थान के बीच परिवर्तित करने के लिए कॉन्फ़िगर किया जा सकता है। यूनिक्स में टैब की चौड़ाई को टर्मिनल पेजर में भी सेट किया जा सकता है जैसे कम (यूनिक्स), और फ़िल्टर द्वारा फ्लाई पर परिवर्तित किया जा सकता है जैसे विस्तृत / अनएक्सपैंड।

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

हार्ड टैब और स्पेस के बीच चुनाव को लेकर प्रोग्रामरों के बीच बहस चल रही है। कई प्रारंभिक प्रोग्रामर इंडेंट करने टाइप करने में आसानी के लिए और स्रोत फ़ाइल आकार को बचाने के लिए टैब कुंजी वर्णों का उपयोग करते थे। कुछ प्रोग्रामर जैसे जेमी ज़विंस्की कहते हैं कि टैब के बजाय रिक्त स्थान का उपयोग करने से क्रॉस-प्लेटफ़ॉर्म पोर्टेबिलिटी बढ़ जाती है।^[1] अन्य जैसे कि वर्डप्रेस कोडिंग मानकों के लेखक इसके विपरीत कहते हैं कि हार्ड टैब पोर्टेबिलिटी बढ़ाते हैं।^[2] गिटहब पर शीर्ष 400,000 कोष के एक सर्वेक्षण में पाया गया कि रिक्त स्थान अधिक सामान्य हैं।^[3]

इंडेंटेशन का आकार प्राय: शैली से स्वतंत्र होता है। 1983 में PASCAL कोड पर किए गए एक प्रयोग में पाया गया कि इंडेंटेशन आकार ने बोधगम्यता को महत्वपूर्ण रूप से प्रभावित किया। 2 और 4 अक्षरों के बीच का इंडेंटेशन आकार इष्टतम साबित हुआ।^[4] रूबी (प्रोग्रामिंग भाषा) कई खोल स्क्रिप्ट भाषा और HTML प्रारूपण के कुछ रूपों के लिए दो स्पेस प्रति इंडेंटेशन लेवल का प्राय: उपयोग किया जाता है।^{[citation needed]}

उपकरण

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

Emacs में, हिटिंग सहित इंडेंटेशन समस्याओं को स्वचालित रूप से ठीक करने के लिए विभिन्न कमांड उपलब्ध हैं Tab किसी दिए गए लाइन पर (गलत विन्यास में)। M-x indent-region कोड के बड़े हिस्से को ठीक से इंडेंट करने के लिए इस्तेमाल किया जा सकता है। मोड के आधार पर, Emacs प्रमुख इंडेंटेशन स्पेस को रिक्त स्थान के बाद उचित संख्या में टैब के साथ बदल सकता है, जिसके परिणामस्वरूप प्रत्येक स्रोत लाइन को इंडेंट करने के लिए वर्णों की न्यूनतम संख्या होती है।

लोचदार टैबस्टॉप एक सारणीकरण शैली है जिसे टेक्स्ट एडिटर से समर्थन की आवश्यकता होती है, जहां ब्लॉक में एक पंक्ति की लंबाई बदलने पर टेक्स्ट के पूरे ब्लॉक को स्वचालित रूप से संरेखित रखा जाता है।

शैलियाँ

के एंड आर शैली

के एंड आर शैली (कर्निघन और रिची शैली), और हैकर शब्दजाल में बारीकी से संबंधित एक सच्ची ब्रेस शैली^[5]^[6] (1TBS के रूप में संक्षिप्त^[7]), प्राय: सी, सी ++, और अन्य घुंघराले-ब्रेस प्रोग्रामिंग भाषाओं में उपयोग की जाती हैं। यह मूल यूनिक्स कर्नेल, ब्रायन कर्निघन और डेनिस रिची में इस्तेमाल की जाने वाली शैली थी। रिची की पुस्तक द [[कर्ली-ब्रेस प्रोग्रामिंग भाषा ]], साथ ही कर्निघन और पी. जे. प्लेगर की पुस्तक प्रोग्रामिंग शैली के तत्व

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

एक कार्य के अंदर बहु-पंक्ति ब्लॉक, हालांकि, उनके संबंधित नियंत्रण बयानों के समान लाइन पर उनके उद्घाटन ब्रेसिज़ होते हैं; क्लोजिंग ब्रेसिज़ स्वयं की एक पंक्ति में रहते हैं, जब तक कि एक कीवर्ड द्वारा पीछा नहीं किया जाता else या while. इस तरह के गैर-टाइपोग्राफिक संरेखण ब्रेसिज़ को मिस्र के ब्रेसिज़ (या मिस्र के कोष्ठक) के नाम से जाना जाता है, जो प्राचीन मिस्र के कुछ काल्पनिक पोज़ में हथियारों के समान हैं।^[8]^[9]^[10] K&R में, सिंगल-लाइन ब्लॉक में ब्रेसेस नहीं होते हैं।

<वाक्यविन्यास प्रकाश लैंग = सी> इंट मेन (इंट एआरजीसी, चार * एआरजीवी []) {

   ...
   जबकि (एक्स == वाई) {
       कुछ();
       कुछ और();

       अगर (कुछ_त्रुटि)
           do_सही (); // K&R में सिंगल-स्टेटमेंट ब्लॉक में ब्रेसेस नहीं होते हैं।
       अन्य
           जारी_जैसा_सामान्य ();
   }

   अंतिम बात ();
   ...

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

सी प्रोग्रामिंग भाषा #इन्फ्लुएंस इस शैली को स्पष्ट रूप से निर्दिष्ट नहीं करता है, हालांकि पूरी किताब में इसका लगातार पालन किया जाता है। पुस्तक से: <ब्लॉककोट> ब्रेसिज़ की स्थिति कम महत्वपूर्ण है, हालांकि लोग भावुक विश्वास रखते हैं। हमने कई लोकप्रिय शैलियों में से एक को चुना है। एक शैली चुनें जो आपको सूट करे, फिर उसका लगातार उपयोग करें। </ब्लॉककोट>

सी भाषा के पुराने संस्करणों में, तर्क प्रकारों को बाद की पंक्ति पर घोषित करने की आवश्यकता होती है (यानी, कार्य के शीर्षलेख के ठीक बाद):

<वाक्यविन्यास प्रकाश लैंग = सी> /* फंक्शन प्रोटोटाइप के बिना मूल प्री-आईएसओ सी शैली */ इंट मेन (एआरजीसी, एआरजीवी)

   इंट एआरजीसी;
   चार * अर्गव [];

{

...

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

वैरिएंट: 1TBS (OTBS)

एक सच्ची ब्रेस शैली (1TBS या OTBS के रूप में संक्षिप्त^[7] के एंड आर के समान है। मुख्य दो अंतर यह हैं कि फ़ंक्शंस में उनके शुरुआती ब्रेसिज़ एक ही रेखा पर एक स्थान से अलग होते हैं, और यह कि ब्रेसिज़ को नियंत्रण कथन के लिए छोड़ा नहीं जाता है, इसके दायरे में केवल एक कथन होता है।^[11] इस शैली में, नए कोड लाइनों के सम्मिलन की अनुमति देने वाले निर्माण अलग-अलग लाइनों पर होते हैं, और सम्मिलन को प्रतिबंधित करने वाले निर्माण एक पंक्ति पर होते हैं। इस सिद्धांत को एकल-पंक्ति सशर्त सहित हर अगर, और, जबकि, आदि को मजबूत करके बढ़ाया जाता है, ताकि कोड की एक नई पंक्ति को कहीं भी सम्मिलित करना हमेशा सुरक्षित रहे (यानी, इस तरह के सम्मिलन से निष्पादन का प्रवाह असहमत नहीं होगा) स्रोत कोड इंडेंटिंग)।

इस शैली के सुझाए गए फायदे यह हैं कि शुरुआती ब्रेस को अकेले अतिरिक्त लाइन की आवश्यकता नहीं होती है, और एंडिंग ब्रेस उस कथन के साथ लाइन अप करता है जो वैचारिक रूप से संबंधित है। इस शैली की एक लागत यह है कि एक ब्लॉक के अंतिम ब्रेस को अकेले एक पूरी लाइन की आवश्यकता होती है, जिसे आंशिक रूप से if/else ब्लॉक और डू/जबकि ब्लॉक में हल किया जा सकता है:

<वाक्यविन्यास प्रकाश लैंग = सी> शून्य चेकनेगेटिव (एक्स) {

   अगर (एक्स <0) {
       पुट (नकारात्मक);
   } अन्य {
       अऋणात्मक (एक्स);
   }

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

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

संस्करण: लिनक्स कर्नेल

K&R शैली का एक लघु संस्करण Linux कर्नेल शैली है, जो Linux कर्नेल के स्रोत ट्री में इसके व्यापक उपयोग के लिए जानी जाती है।^[12] लिनस टोरवाल्ड्स दृढ़ता से सभी योगदानकर्ताओं को इसका पालन करने की सलाह देते हैं। शैली के एंड आर से कई तत्वों को उधार लेती है।

कर्नेल शैली इंडेंटेशन के लिए टैब का विश्राम स्थान का उपयोग करती है (टैब स्टॉप प्रत्येक 8 वर्ण सेट करता है)। किसी कार्य के घुंघराले ब्रेसिज़ को खोलना कार्य हेडर के बाद लाइन की शुरुआत में जाता है। कोई भी अन्य ओपनिंग कर्ली ब्रेसेस उसी लाइन पर चलते हैं, जिस पर संबंधित कथन एक स्पेस द्वारा अलग किया जाता है। ए में लेबल switch बयान संलग्न ब्लॉक के साथ गठबंधन कर रहे हैं (इंडेंट का केवल एक स्तर है)। लाइन की लंबाई 80 वर्णों तक सीमित हुआ करती थी – इसे 2020 में बढ़ाकर 100 कर दिया गया था, लेकिन मूल सीमा को अभी भी पसंद किया जाता है।^[13] यौगिक कथन के सिंगल-स्टेटमेंट बॉडी (जैसे कि अगर, जबकि, और डू-वाइल) को घुंघराले ब्रेसिज़ से घिरा नहीं होना चाहिए। यदि, हालांकि, एक में एक या एक से अधिक सबस्टेटमेंट if-else कथन में ब्रेसिज़ की आवश्यकता होती है, तो दोनों सबस्टेटमेंट को कर्ली ब्रेसिज़ के अंदर लपेटा जाना चाहिए:

<वाक्यविन्यास प्रकाश लैंग = सी> इंट पावर (इंट एक्स, इंट वाई) {

       इंट परिणाम;

       अगर (वाई <0) {
               परिणाम = 0;
       } अन्य {
               परिणाम = 1;
               जबकि (y-- > 0)
                       परिणाम * = एक्स;
       }
       वापसी परिणाम;

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

संस्करण: अनिवार्य ब्रेसिज़

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

इस शैली की लागत यह है कि अंतिम ब्लॉक के लिए एक अतिरिक्त पूर्ण लाइन की आवश्यकता होती है (मध्यवर्ती ब्लॉकों को छोड़कर if/else if/else निर्माण करता है और करते हैं/जबकि ब्लॉक करता है)।

संस्करण: जावा

जबकि जावा (प्रोग्रामिंग भाषा) को कभी-कभी अन्य शैलियों में लिखा जाता है, जावा कोड का एक महत्वपूर्ण निकाय #K&R Style|K&R शैली के एक मामूली संस्करण का उपयोग करता है जिसमें ओपनिंग ब्रेस एक ही लाइन पर होता है न कि केवल एक कार्य के अंदर ब्लॉक के लिए, लेकिन कक्षा या विधि घोषणाओं के लिए भी। यह शैली काफी हद तक व्यापक है क्योंकि सन माइक्रोसिस्टम्स की मूल शैली गाइड करती है^[14]^[15]^[16] इस K&R संस्करण का उपयोग किया, और परिणामस्वरूप, जावा क्लास लाइब्रेरी के लिए अधिकांश मानक स्रोत कोड इस शैली में लिखे गए हैं। यह #Allman शैली के साथ-साथ ActionScript और JavaScript के लिए भी एक लोकप्रिय इंडेंटेशन शैली है।

संस्करण: स्ट्रॉस्ट्रुप

स्ट्रॉस्ट्रुप शैली बज़्ने स्ट्रॉस्ट्रुप का सी ++ के लिए के एंड आर शैली का अनुकूलन है, जैसा कि उनकी पुस्तकों में प्रयोग किया जाता है, जैसे कि प्रोग्रामिंग: प्रिंसिपल्स एंड प्रैक्टिस यूजिंग सी ++ और सी ++ प्रोग्रामिंग भाषा^[17] ऊपर दिए गए वेरिएंट के विपरीत, स्ट्रॉस्ट्रुप एक cuddled else का उपयोग नहीं करता है। इस प्रकार, स्ट्राउस्ट्रप लिखेंगे^[17]

<वाक्यविन्यास प्रकाश लैंग = सी>

   अगर (एक्स <0) {
       पुट (नकारात्मक);
       नकारात्मक (एक्स);
   }
   अन्य {
       पुट (गैर-नकारात्मक);
       अऋणात्मक (एक्स);
   }

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

स्ट्रॉस्ट्रुप कक्षाओं के लिए के एंड आर शैली का विस्तार करता है, उन्हें निम्नानुसार लिखता है:

<वाक्यविन्यास लैंग = सीपीपी>

   वर्ग वेक्टर {
   जनता:
       वेक्टर (इंट एस): एलेम (नया डबल [एस]), एसजेड (एस) {} // एक वेक्टर का निर्माण
       डबल और ऑपरेटर [] (इंट आई) {वापसी तत्व [i]; } // एलिमेंट एक्सेस: सबस्क्रिप्टिंग
       int आकार () {वापसी sz; }
   निजी:
       डबल * एलिम; // तत्वों के लिए सूचक
       इंट एसजेड; // तत्वों की संख्या
   };

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

स्ट्रॉस्ट्रुप लेबल को इंडेंट नहीं करता है public: और private:. इसके अतिरिक्त इस शैली में, जबकि एक कार्य की ओपनिंग ब्रेस एक नई लाइन पर शुरू होती है, एक क्लास की ओपनिंग ब्रेस उसी लाइन पर होती है जिस पर क्लास का नाम होता है।

स्ट्रॉस्ट्रुप छोटे कार्यों को एक पंक्ति में लिखने की अनुमति देता है। स्ट्राउस्ट्रप शैली एक नामांकित इंडेंटेशन शैली है जो संपादक Emacs में उपलब्ध है। स्ट्रॉस्ट्रुप अपने आधुनिक सी++ कोर दिशानिर्देशों में बताए गए अनुसार सी++ के साथ एक के एंड आर-व्युत्पन्न शैली लेआउट को प्रोत्साहित करता है।^[18]

वैरिएंट: बीएसडी केएनएफ

कर्नेल सामान्य रूप भी कहा जाता है, यह बर्कले सॉफ्टवेयर वितरण (BSD) ऑपरेटिंग सिस्टम में उपयोग किए जाने वाले अधिकांश कोड का रूप है। हालांकि ज्यादातर कर्नेल कोड के लिए अभिप्रेत है, यह यूजरलैंड (कंप्यूटिंग) कोड में भी व्यापक रूप से उपयोग किया जाता है। बेल लैब्स संस्करण 6 और 7 यूनिक्स स्रोत कोड में उपयोग किए जाने के रूप में यह अनिवार्य रूप से के एंड आर शैली का एक पूरी तरह से प्रलेखित संस्करण है।^[19] SunOS कर्नेल और यूजरलैंड एक समान इंडेंटेशन शैली का उपयोग करते हैं।^[19]केएनएफ की तरह, यह भी एटी एंड टी शैली के दस्तावेजों पर आधारित था और इसे कभी-कभी बिल जॉय नॉर्मल फॉर्म भी कहा जाता है।^[20] SunOS दिशानिर्देश 1996 में प्रकाशित हुआ था; एएनएसआई सी पर संक्षेप में चर्चा की गई है। स्रोत फ़ाइलों की सूची के इंडेंटेशन की शुद्धता को बिल शैनन द्वारा लिखित cstyle प्रोग्राम द्वारा सत्यापित किया जा सकता है।^[19]^[20]^[21] इस शैली में, हार्ड टेबुलेटर (ts in vi) को आठ कॉलम में रखा जाता है, जबकि एक सॉफ्ट टेबुलेटर को अक्सर एक सहायक (sw in vi) के रूप में भी परिभाषित किया जाता है, और चार पर सेट किया जाता है। हार्ड टेबुलेटर्स का उपयोग कोड ब्लॉक इंडेंट करने के लिए किया जाता है, जबकि अतिरिक्त इंडेंटेशन के सॉफ्ट टेबुलेटर (चार रिक्त स्थान) का उपयोग उन सभी निरंतर लाइनों के लिए किया जाता है जिन्हें कई लाइनों में विभाजित किया जाना चाहिए।

इसके अतिरिक्त कार्य कॉल कोष्ठक से पहले एक स्थान का उपयोग नहीं करते हैं, हालांकि सी-भाषा मूल कथन जैसे if, while, do, switch और return करें (मामले में जहां return Parens के साथ प्रयोग किया जाता है)। ऐसे कार्य जो अपने शीर्ष-स्तरीय ब्लॉक में कोई स्थानीय चर घोषित नहीं करते हैं, उनके शुरुआती ब्लॉक ब्रेस के बाद भी एक खाली रेखा छोड़नी चाहिए।

यहाँ कुछ नमूने देखें:

<वाक्यविन्यास प्रकाश लैंग = सी> जबकि (एक्स == वाई) {

       कुछ();
       कुछ और();

} अंतिम बात (); </वाक्यविन्यास हाइलाइट>

<वाक्यविन्यास प्रकाश लैंग = सी> अगर (डेटा! = न्यूल एंड& रेस> 0) {

       अगर (JS_DefineProperty (सीएक्स, ओ, डेटा,
           STRING_TO_JSVAL(JS_NewStringCopyN(cx, डेटा, Res)),
           न्यूल, न्यूल, जेएसपीआरओपी_ENUMERATE)! = 0) {
               QUEUE_EXCEPTION(आंतरिक त्रुटि!);
               गोटो गलती;
       }
       पीक्यू फ्रीमेम (डेटा);

} अन्य {

       अगर (JS_DefineProperty (cx, o, डेटा, OBJECT_TO_JSVAL (NULL),
           न्यूल, न्यूल, जेएसपीआरओपी_ENUMERATE)! = 0) {
               QUEUE_EXCEPTION(आंतरिक त्रुटि!);
               गोटो गलती;
       }

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

<वाक्यविन्यास प्रकाश लैंग = सी> स्थिर जेएसबूल pgresult_constructor(JSContext *cx, JSObject *obj, uintN argc,

   jsval * argv, jsval * रावल)

{

       QUEUE_EXCEPTION (पीग्रेसल्ट वर्ग उपयोगकर्ता-तत्काल योग्य नहीं है);

       वापसी (JS_FALSE);

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

ऑलमैन शैली

ऑलमैन शैली का नाम एरिक एलमैन के नाम पर रखा गया है। इसे कभी-कभी बीएसडी शैली भी कहा जाता है क्योंकि ऑलमैन ने बर्कले सॉफ्टवेयर डिस्ट्रीब्यूशन यूनिक्स के लिए कई उपयोगिताओं को लिखा था (हालांकि इसे अलग-अलग बीएसडी केएनएफ शैली के साथ भ्रमित नहीं होना चाहिए; ऊपर देखें)।

यह शैली अगली पंक्ति पर नियंत्रण कथन से जुड़े ब्रेस को नियंत्रण कथन के समान स्तर पर इंडेंट करती है। कोष्ठकों के भीतर कथनों को अगले स्तर पर इंडेंट किया जाता है।^[22] <वाक्यविन्यास प्रकाश लैंग = सी> जबकि (एक्स == वाई) {

   कुछ();
   कुछ और();

}

अंतिम बात (); </वाक्यविन्यास हाइलाइट>

यह शैली पास्कल (प्रोग्रामिंग भाषा) भाषाओं और कारोबार-एसक्यूएल द्वारा उपयोग किए जाने वाले मानक इंडेंटेशन के समान है, जहां ब्रेसिज़ कीवर्ड के बराबर हैं I begin और end.

<वाक्यविन्यास लैंग = पास्कल> (* पास्कल में ऑलमैन कोड इंडेंटेशन शैली का उदाहरण *) प्रक्रिया dosomething(x, y: पूर्णांक); शुरू

   जबकि x = y करते हैं
   शुरू
       कुछ();
       कुछ और();
   अंत;

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

उदाहरण के लिए, निम्नलिखित अभी भी वाक्य रचनात्मक रूप से सही है: <वाक्यविन्यास प्रकाश लैंग = सी> // जबकि (एक्स == वाई) {

   कुछ();
   कुछ और();

} </वाक्यविन्यास हाइलाइट> जैसा यह है: <वाक्यविन्यास प्रकाश लैंग = सी> // के लिए (int i=0; i <x; i++) // जबकि (एक्स == वाई) अगर (एक्स == वाई) {

   कुछ();
   कुछ और();

} </वाक्यविन्यास हाइलाइट> इस तरह भी, सशर्त संकलन के साथ: <वाक्यविन्यास प्रकाश लैंग = सी>

   इंट सी;

ifdef HAS_GETCH

   जबकि ((सी = getch ())! = ईओएफ)

अन्य

   जबकि ((सी = getchar ())! = ईओएफ)

अगर अंत

   {
       do_something (सी);
   }

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

वैरिएंट: ऑलमैन-8

शिक्षा में उपयोग के लिए एक लोकप्रिय संस्करण,^{[citation needed]} Allman-8 8-स्पेस इंडेंटेशन टैब और K&R के Linux कर्नेल वेरिएंट की 80-कॉलम सीमा का उपयोग करता है। शैली कथित तौर पर प्रोजेक्टर पर पठनीयता में सुधार करने में मदद करती है। साथ ही, इंडेंटेशन आकार और कॉलम प्रतिबंध कोड ब्लॉक के अत्यधिक नेस्टिंग की पहचान करने के लिए एक दृश्य क्यू बनाने में मदद करता है। ये लाभ नए डेवलपर्स और शिक्षार्थियों को कोड जटिलता को प्रबंधित करने के लिए निहित मार्गदर्शन प्रदान करने में मदद करने के लिए गठबंधन करते हैं।^{[citation needed]}

गोरे लोग शैली

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

जार्गन फ़ाइल के अनुसार, व्हाईटस्मिथ, #ऑलमैन शैली के साथ, समान लोकप्रियता के साथ सबसे आम ब्रेसिंग शैली रही है।^[5]

यह शैली नियंत्रण कथन से जुड़े ब्रेस को अगली पंक्ति पर इंडेंट करती है। ब्रेसिज़ के भीतर कथन्स को ब्रेसिज़ के समान स्तर पर इंडेंट किया जाता है।

रैटलिफ़ शैली की तरह, समापन ब्रेस को ब्रेसिज़ के भीतर बयानों के समान ही इंडेंट किया जाता है।^[23]

<वाक्यविन्यास प्रकाश लैंग = सी> जबकि (एक्स == वाई)

   {
   कुछ();
   कुछ और();
   }

अंतिम बात (); </वाक्यविन्यास हाइलाइट>

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

एक उदाहरण: <वाक्यविन्यास प्रकाश लैंग = सी> अगर (डेटा! = न्यूल एंड& रेस> 0)

   {
   if (!JS_DefineProperty(cx, o, data , STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)), NULL, NULL, JSPROP_ENUMERATE))
       {
       QUEUE_EXCEPTION(आंतरिक त्रुटि!);
       गोटो गलती;
       }
   पीक्यू फ्रीमेम (डेटा);
   }

और अगर (!JS_DefineProperty(cx, o, data , OBJECT_TO_JSVAL(NULL), NULL, NULL, JSPROP_ENUMERATE))

   {
   QUEUE_EXCEPTION(आंतरिक त्रुटि!);
   गोटो गलती;
   }

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

else if कथन के रूप में व्यवहार किया जाता है, जैसे कि #elif प्रीप्रोसेसर कथन।

जीएनयू शैली

ऑलमैन शैली और #व्हाईटस्मिथ्स शैली शैली की तरह, GNU शैली एक लाइन पर खुद से ब्रेसिज़ लगाती है, दो स्पेस द्वारा इंडेंट किया जाता है, सिवाए फंक्शन डेफिनिशन को ओपन करने के, जहां वे इंडेंट नहीं होते हैं।^[24] किसी भी मामले में, निहित कोड को ब्रेसिज़ से दो रिक्त स्थान द्वारा इंडेंट किया जाता है।

रिचर्ड स्टालमैन द्वारा लोकप्रिय, लेआउट लिस्प (प्रोग्रामिंग भाषा) कोड लिखने की उनकी पृष्ठभूमि से प्रभावित हो सकता है।^[25] लिस्प में, एक ब्लॉक (एक प्रोग्न) के बराबर एक प्रथम श्रेणी की डेटा इकाई है, और इसे अपना इंडेंटेशन स्तर देने से उस पर जोर देने में मदद मिलती है, जबकि सी में, एक ब्लॉक केवल सिंटैक्स है। यह शैली 1960 और 1970 के दशक की कुछ ALGOL और XPL प्रोग्रामिंग भाषा पाठ्यपुस्तकों में भी पाई जा सकती है।^[26]^[27]^[discuss] हालांकि सीधे इंडेंटेशन से संबंधित नहीं है, जीएनयू कोडिंग शैली में कार्य के तर्कों की ब्रैकेटेड सूची से पहले एक स्थान भी सम्मिलित है।

<वाक्यविन्यास प्रकाश लैंग = सी> स्थैतिक चार * concat (चार *s1, चार *s2) {

 जबकि (एक्स == वाई)
   {
     कुछ ();
     कुछ और ();
   }
 अंतिम बात ();

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

यह शैली #ऑलमैन शैली और #व्हाईटस्मिथ शैली के लाभों को जोड़ती है, जिससे ब्लॉक से बाहर नहीं खड़े होने वाले ब्रेसिज़ के संभावित व्हाइटस्मिथ नुकसान को दूर किया जाता है। एक नुकसान यह है कि अंतिम ब्रेस अब उस कथन के अनुरूप नहीं है जिससे यह अवधारणात्मक रूप से संबंधित है। एक और संभावित नुकसान यह है कि यह एक वैचारिक स्तर के लिए इंडेंट के दो दृश्य स्तरों का उपयोग करके स्थान को बर्बाद कर सकता है, लेकिन वास्तव में यह संभावना नहीं है, क्योंकि एकल-स्तरीय इंडेंटेशन वाले सिस्टम में, प्रत्येक स्तर प्राय: कम से कम 4 रिक्त स्थान होता है, जैसा कि 2 * जीएनयू शैली में 2 रिक्त स्थान।

GNU कोडिंग मानक इस शैली की अनुशंसा करते हैं, और जीएनयू परियोजना सॉफ़्टवेयर के लगभग सभी अनुरक्षक इसका उपयोग करते हैं।^{[citation needed]} GNU Emacs टेक्स्ट एडिटर और GNU सिस्टम का इंडेंट (Unix) कमांड गलत रूप से इस शैली के अनुसार कोड को रिफॉर्मेट करेगा।^[28] जो लोग GNU Emacs, या समान रूप से एक्स्टेंसिबल/अनुकूलन योग्य संपादकों का उपयोग नहीं करते हैं, वे पा सकते हैं कि उनके संपादक की स्वचालित इंडेंटेशन सेटिंग्स इस शैली के लिए अनुपयोगी हैं। हालांकि, केएनएफ शैली के लिए डिफॉल्ट करने वाले कई संपादक जीएनयू शैली के साथ अच्छी तरह से सामना करते हैं जब टैब की चौड़ाई दो स्थानों पर सेट होती है; इसी तरह, GNU Emacs केवल टैब की चौड़ाई को आठ स्थानों पर सेट करके KNF शैली के अनुकूल हो जाता है। दोनों ही मामलों में, स्वचालित सुधार मूल रिक्ति को नष्ट कर देता है, लेकिन स्वचालित लाइन इंडेंटिंग ठीक से काम करेगी।

स्टीव मैककोनेल, अपनी पुस्तक कोड पूर्ण में, इस शैली का उपयोग करने के खिलाफ सलाह देते हैं: वह एक कोड नमूना चिह्नित करता है जो कोडिंग हॉरर आइकन के साथ इसका उपयोग करता है, विशेष रूप से खतरनाक कोड का प्रतीक है, और कहता है कि यह पठनीयता को बाधित करता है।^[23] लिनक्स कर्नेल कोडिंग शैली प्रलेखन भी इस शैली के खिलाफ दृढ़ता से अनुशंसा करता है, पाठकों से जीएनयू कोडिंग मानकों की एक प्रति को एक महान प्रतीकात्मक संकेत के रूप में जलाने का आग्रह करता है।^[29]

होर्स्टमैन शैली

के एस. होर्स्टमैन द्वारा कम्प्यूटिंग कॉन्सेप्ट्स विद सी++ एसेंशियल्स का 1997 का संस्करण ओपनिंग ब्रेस के समान लाइन पर एक ब्लॉक के पहले कथन को रखकर #ऑलमैन शैली को अपनाता है। इस शैली का उपयोग जेन्सेन और विर्थ के पास्कल यूजर मैनुअल और रिपोर्ट के उदाहरणों में भी किया जाता है।^[30] <वाक्यविन्यास प्रकाश लैंग = सी> जबकि (एक्स == वाई) { कुछ();

   कुछ और();
   //...
   अगर (एक्स <0)
   {प्रिंटफ (नकारात्मक);
       नकारात्मक (एक्स);
   }
   अन्य
   {प्रिंटफ (गैर-नकारात्मक);
       अऋणात्मक (एक्स);
   }

} अंतिम बात (); </वाक्यविन्यास हाइलाइट>

यह शैली K&R शैली की एक पंक्ति की बचत के साथ पठनीयता के लिए ब्रेसिज़ के ऊर्ध्वाधर संरेखण को बनाए रखते हुए और आसानी से ब्लॉक की पहचान करके #Allman शैली के लाभों को जोड़ती है। हालाँकि, 2003 का संस्करण अब ऑलमैन शैली का उपयोग करता है।^[31]

पिको शैली

यह शैली पिको (प्रोग्रामिंग भाषा) भाषा में इसके डिजाइनरों द्वारा सबसे अधिक उपयोग की जाती है। पिको में रिटर्न कथन का अभाव है, और टर्मिनेटर के बजाय अर्धविराम को कथन सेपरेटर के रूप में उपयोग करता है। यह इस वाक्यविन्यास को उत्पन्न करता है:^[32]

<पूर्व> सामान (एन): {एक्स: 3 * एन;

 वाई: डू स्टफ (एक्स);
 वाई + एक्स}

</पूर्व>

फायदे और नुकसान के एंड आर शैली के साथ स्क्रीन रियल एस्टेट को बचाने के समान हैं। एक अतिरिक्त लाभ यह है कि प्रारंभिक और समापन ब्रेसिज़ K&R शैली के सापेक्ष अनुप्रयोग में सुसंगत हैं (दोनों कोड की एक पंक्ति के साथ स्थान साझा करते हैं), जहां एक ब्रेस कोड की एक पंक्ति के साथ स्थान साझा करता है और एक ब्रेस में केवल एक पंक्ति होती है।

रैटलिफ शैली

प्रोग्रामर एट वर्क पुस्तक में,^[33] सी. वेन रैटलिफ़ ने नीचे दी गई शैली का उपयोग करते हुए चर्चा की। शैली 1TBS की तरह शुरू होती है लेकिन फिर नेस्टेड ब्लॉक के इंडेंटेशन के साथ क्लोजिंग ब्रेस लाइन अप हो जाती है। रैटलिफ़ लोकप्रिय dBase-II और -III चौथी पीढ़ी की प्रोग्रामिंग भाषाओं के पीछे मूल प्रोग्रामर थे। उन्होंने संकेत दिया कि यह मूल रूप से डिजिटल अनुसंधान इंक से सामग्री में प्रलेखित था। इस शैली को कभी-कभी बैनर शैली कहा जाता है,^[34] संभवतः एक खंभे से लटके हुए बैनर के समानता के लिए। इस शैली में, जो कि #व्हाईटस्मिथ्स शैली के लिए है जैसे के एंड आर ऑलमैन के लिए है, समापन नियंत्रण को सूची में अंतिम आइटम के समान ही इंडेंट किया गया है (और इस प्रकार उचित रूप से प्रमुखता खो देता है)^[23]शैली कुछ लोगों के लिए विज़ुअल स्कैनिंग को आसान बना सकती है, क्योंकि किसी भी ब्लॉक के हेडर ही उस स्तर पर एक्सडेंट होते हैं (सिद्धांत यह है कि पूर्व ब्लॉक का समापन नियंत्रण K&R में अगले ब्लॉक हेडर के दृश्य प्रवाह के साथ हस्तक्षेप करता है और ऑलमैन शैली)। सॉफ्टवेयर टूल्स में रैटफोर कोड में कर्निघन और प्लेगर इस शैली का उपयोग करते हैं।^[35] <वाक्यविन्यास प्रकाश लैंग = सी>

// सी में
के लिए (i = 0; i <10; i++) {
    अगर (मैं% 2 == 0) {
        कुछ करो (मैं);
        }
    अन्य {
        कुछ और करो (i);
        }
    }

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

या, मार्कअप भाषा में...

<वाक्यविन्यास हाइलाइट लैंग = html4सख्त>

lots of stuff...

     more stuff

alternative for short lines

etc.

... etc

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

लिस्प शैली

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

<वाक्यविन्यास प्रकाश लैंग = सी> // सी में के लिए (i = 0; i <10; i++)

   {अगर (मैं% 2 == 0)
       {कुछ करो(i);}
    अन्य
       {कुछ और करें(i);
        doThirdThing(i);}}

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

<वाक्यविन्यास लैंग = अजगर>

पायथन में

मैं सीमा में (10) के लिए:

   अगर मैं% 2 == 0:
       do_something (मैं)
   अन्य:
       do_something_else(मैं)
       do_third_thing(i)

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

<वाक्यविन्यास प्रकाश लैंग = लिस्प>

लिस्प में

(डॉटाइम्स (मैं 10)

   (अगर (= (रेम आई 2) 0)
       (करो-कुछ मैं)
       (प्रोग्न
           (करो-कुछ-और मैं)
           (करो-तीसरी-चीज़ i))))

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

हास्केल शैली

हास्केल (प्रोग्रामिंग भाषा) लेआउट ब्रेसिज़ के प्लेसमेंट को वैकल्पिक बना सकता है, हालांकि भाषा में ब्रेसिज़ और अर्धविरामों की अनुमति है।^[36] नीचे दिए गए दो खंड संकलक के लिए समान रूप से स्वीकार्य हैं:

<वाक्यविन्यास लैंग = हास्केल> ब्रेसलेस = करना

 पाठ <- सामग्री प्राप्त करें
 होने देना
   फर्स्टवर्ड = हेड $ शब्द टेक्स्ट
   bigWord = मैप toUpper FirstWord
 putStrLn बिगवर्ड

कंजूस = करना

 {पाठ <- getContents
 ; होने देना
     { फर्स्टवर्ड = हेड $ शब्द टेक्स्ट
     ; bigWord = मैप toUpper FirstWord
     }
 ; putStrLn बिगवर्ड
 }

</वाक्यविन्यास हाइलाइट> हास्केल में, लेआउट ब्रेसिज़ को बदल सकता है। प्राय: प्रक्रियात्मक प्रोग्रामिंग के लिए ब्रेसिज़ और अर्धविराम छोड़े जाते हैं do वर्गों और सामान्य रूप से कार्यक्रम पाठ, लेकिन शैली का उपयोग प्राय: सूचियों, अभिलेखों और अन्य वाक्य-विन्यास तत्वों के लिए किया जाता है, जो कोष्ठक या ब्रेसिज़ की कुछ जोड़ी से बना होता है, जो अल्पविराम या अर्धविराम से अलग होते हैं।^[37] यदि कोड कीवर्ड का अनुसरण करता है where, let, या of ब्रेसिज़ और अर्धविराम छोड़ देता है, तो इंडेंटेशन महत्वपूर्ण है।^[38]

एपीएल शैली

प्राय: एपीएल कितना संक्षिप्त है, इसके उदाहरण के लिए, यहां गेम ऑफ लाइफ के लिए स्टेप फंक्शन का कार्यान्वयन है: <syntaxhighlight lang=apl> जीवन←{⊃1⍵∨.∧3 4=+/+⌿¯1 0 1∘.⊖¯1 0 1⌽¨⊂⍵} </वाक्यविन्यास हाइलाइट> एपीएल (प्रोग्रामिंग भाषा) शैली सी एपीएल कोड की संक्षिप्त शैली जैसा दिखता है, और प्राय: उनके कार्यान्वयन में उपयोग किया जाता है।^[39] इस शैली का नेतृत्व आर्थर व्हिटनी (कंप्यूटर वैज्ञानिक) द्वारा किया गया था, और इसका उपयोग के (प्रोग्रामिंग भाषा), आर्थर की अपनी परियोजना के कार्यान्वयन में किया जाता है। J (प्रोग्रामिंग भाषा ) प्रोग्रामिंग भाषा को भी इस शैली में लागू किया गया है। विशेष रूप से, APL के सभी कार्यान्वयन C की इस शैली का उपयोग नहीं करते हैं, अर्थात्: GNU APL और Dyalog APL।

एपीएल शैली सी इंडेंटेशन के अतिरिक्त प्राय: नामों को एकल या दोहरे वर्णों में छोटा किया जाता है: इंडेंटेशन की मात्रा को कम करने के लिए, और कई पंक्तियों में फैले भाव।

अन्य विचार

ब्लॉक का ट्रैक खोना

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

प्रोग्रामर जो शुरुआती ब्रेसिज़ की गिनती पर भरोसा करते हैं, उन्हें के एंड आर जैसे इंडेंटेशन शैलियों में कठिनाई हो सकती है, जहां शुरुआती ब्रेस अपने नियंत्रण प्रवाह से दृष्टि से अलग नहीं होते हैं। प्रोग्रामर जो इंडेंटेशन पर अधिक भरोसा करते हैं, उन शैलियों से अधिक लाभ प्राप्त करेंगे जो लंबवत रूप से कॉम्पैक्ट हैं, जैसे K&R, क्योंकि ब्लॉक छोटे हैं।

जैसे नियंत्रण बयानों का ट्रैक खोने से बचने के लिए for, एक बड़े इंडेंटेशन का उपयोग किया जा सकता है, जैसे कि 8-यूनिट-चौड़ा हार्ड टैब, बड़े कार्यों को छोटे और अधिक पठनीय कार्यों में विभाजित करने के साथ। Linux इस तरह से किया जाता है, जबकि K&R शैली का उपयोग किया जाता है।

vi परिवार के पाठ संपादकों में, ब्लॉक सीमाओं को ट्रैक करने का एक तरीका यह है कि टेक्स्ट कर्सर को ब्रेसिज़ में से किसी एक पर रखें और दबाएं % चाबी। इसके बाद कर्सर विपरीत ब्रेस पर कूद जाता है। चूंकि टेक्स्ट कर्सर next कुंजी (अर्थात।, n key) ने दिशात्मक पोजीशनिंग जानकारी को बनाए रखा (चाहे up या down कुंजी को पहले दबाया गया था), मैक्रो (कंप्यूटर विज्ञान) #कीबोर्ड और माउस मैक्रोज़ ( . key) का उपयोग टेक्स्ट कर्सर को अगले ब्रेस पर रखने के लिए किया जा सकता है,^[40] एक उपयुक्त कोडिंग शैली दी गई। इसके बजाय, % कुंजी का उपयोग कोडिंग मानक को लागू करने के लिए किया जा सकता है।

समापन ब्रेस के बाद जोड़े गए इनलाइन टिप्पणियों का उपयोग करने का दूसरा तरीका है:

<वाक्यविन्यास प्रकाश लैंग = सी> के लिए (int i = 0; i <कुल; i++) {

   फू (बार);

} // के लिए (मैं) </वाक्यविन्यास हाइलाइट>

<वाक्यविन्यास प्रकाश लैंग = सी> अगर (एक्स <0) {

  बार (फू);

} // अगर (एक्स <0) </वाक्यविन्यास हाइलाइट>

इस पद्धति का प्रमुख नुकसान कई स्थानों पर डुप्लिकेट कोड बनाए रखना है।

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

वक्तव्य सम्मिलन

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

<वाक्यविन्यास प्रकाश लैंग = सी> के लिए (int i = 0; i <10; i++)

   वूप्स (बार); /* 10 बार दोहराया, i 0 से 9 तक */

{

   केवल एकबार(); /* प्रोग्रामर ने इसे 10 बार करने का इरादा किया था */

} // for (i) ← यह टिप्पणी अब मान्य नहीं है, और बहुत भ्रामक है! </वाक्यविन्यास हाइलाइट>

K&R शैली कंट्रोल कथन और ओपनिंग ब्रेस को एक ही लाइन पर रखकर इस समस्या से बचा जाता है।

यह भी देखें

माध्यमिक संकेतन
वाक्य - विन्यास पर प्रकाश डालना
इंडेंटेशन (टाइपसेटिंग) # प्रोग्रामिंग में इंडेंटेशन

संदर्भ

↑ Zawinski, Jamie (2000). "Tabs versus Spaces: An Eternal Holy War". Retrieved 6 June 2016.
↑ "WordPress Coding Standards". Retrieved 6 June 2016.
↑ Hoffa, Felipe (26 July 2017). "400,000 GitHub repositories, 1 billion files, 14 terabytes of code: Spaces or Tabs?". Medium (in English). Retrieved 9 July 2019.
↑ Miara, Richard J.; Musselman, Joyce A.; Navarro, Juan A. & Shneiderman, Ben (November 1983). "Program Indentation and Comprehensibility" (PDF). Communications of the ACM. 26 (11): 861–867. doi:10.1145/182.358437. S2CID 11767796. Retrieved 3 August 2017.
↑ ^5.0 ^5.1 ^5.2 "The Jargon File". 4.4.7. 29 December 2003. Retrieved 18 August 2014.
↑ Darwin, Ian F. (1988). Checking C programs with Lint. California: O'Reilly and Assosciates. p. 51. ISBN 9780937175309.
↑ ^7.0 ^7.1 "1TBS".
↑ "Java Style Guide". Archived from the original on 12 July 2018. Using either "Egyptian" curly braces or C-style curly braces is acceptable
↑ "Egyptian brackets". Foldoc. A humourous [sic] term for K&R indent style, referring to the "one hand up in front, one down behind" pose
↑ "Google JavaScript Style Guide". Braces follow the Kernighan and Ritchie style ("Egyptian brackets") for nonempty blocks and block-like constructs
↑ ^11.0 ^11.1 "Brace styles and JavaScript". 7 January 2013. Retrieved 8 November 2018.
↑ A detailed description of the style is given at kernel.org.
↑ Larabel, Michael. "The Linux Kernel Deprecates The 80 Character Line Coding Style". Phoronix. Phoronix Media. Retrieved 1 May 2022.
↑ Reddy, Achut (30 March 2000). "Java Coding Style Guide" (PDF). Sun Microsystems. Archived from the original (PDF) on 28 February 2006. Retrieved 30 May 2008.
↑ "Java Code Conventions" (PDF). Sun Microsystems. 12 September 1997. Archived from the original (PDF) on 13 May 2008. Retrieved 30 May 2008.
↑ "Code Conventions for the Java Programming Language". Sun Microsystems. 20 March 1997. Retrieved 30 May 2008.
↑ ^17.0 ^17.1 Stroustrup, Bjarne (September 2010). "PPP Style Guide" (PDF).
↑ Stroustrup, Bjarne. "C++ Core Guidelines". GitHub. Retrieved 3 November 2018.
↑ ^19.0 ^19.1 ^19.2 Shannon, Bill (19 August 1996). "C Style and Coding Standards for SunOS" (PDF). 1.8. Sun Microsystems, Inc. Retrieved 15 June 2019.
↑ ^20.0 ^20.1 Gregg, Brendan. "DTraceToolkit Style Guide". Retrieved 6 February 2015.
↑ Shannon, Bill (9 September 1998). "cstyle.pl". illumos-gate. 1.58. Sun Microsystems, Inc. Retrieved 6 February 2015.
↑ "indent style". The on-line hacker Jargon File. 4.4.7. 29 December 2003. Retrieved 20 March 2022 – via catb.
↑ ^23.0 ^23.1 ^23.2 McConnell, Steve (2004). Code Complete: A practical handbook of software construction. Redmond, WA: Microsoft Press. pp. 746–747. ISBN 978-0-7356-1967-8.
↑ ^24.0 ^24.1 "Formatting Your Source Code". GNU Coding Standards. Retrieved 6 June 2016.
↑ Stallman, Richard (28 October 2002). "My Lisp Experiences and the Development of GNU Emacs (Transcript of speech at the International Lisp Conference)". Retrieved 6 June 2016.
↑ Baumann, Richard [in Deutsch]; Feliciano, Manuel; Bauer, Friedrich Ludwig; Samelson, Klaus (1964). Introduction to ALGOL – A primer for the non-specialist, emphasizing the practical uses of the algorithmic language. Series in Automatic Computation. Englewood Cliffs, New Jersey, USA: Prentice-Hall, Inc. ISBN 0-13-477828-6. LCCN 64-10740. ark:/13960/t6qz35p37. Retrieved 23 October 2022.
↑ W. M. McKeeman, J. J. Horning, and D. B. Wortman, A Compiler Generator, 1970, https://archive.org/details/compilergenerato00mcke
↑ Tested on the sample source code above on Ubuntu 18.04 with GNU indent 2.2.11 and GNU Emacs 25.2.2 started with emacs --no-init-file.
↑ "Linux kernel coding style". Retrieved 1 January 2017.
↑ Jensen, Kathleen; Wirth, Niklaus (1974). PASCAL User Manual and Report. Springer-Verlag.
↑ Horstmann Style Guide
↑ Ohno, Asako (2013). "A methodology to teach exemplary coding style considering students' coding style feature contains fluctuations". 2013 IEEE Frontiers in Education Conference (FIE): 1908–1910. doi:10.1109/fie.2013.6685167. ISBN 9781467352611. S2CID 28385526.
↑ Lammers, Susan (1986). Programmers at Work. Microsoft Press. ISBN 978-0-914845-71-3.
↑ Pattee, Jim. "Artistic Style 2.05 Documentation". Artistic Style. Retrieved 24 April 2015.
↑ Kernighan, Brian W.; Plauger, P. J. (1976). Software Tools. Addison-Wesley.
↑ "The Haskell 98 Report". haskell.org. Retrieved 3 March 2016.
↑ Lipovača, Miran. "Making Our Own Types and Typeclasses". learnyouahaskell.com. Retrieved 3 February 2016.
↑ Haskell Report 1.2 (1992), p.131 B.4 "Layout"
↑ "The J Incunabulum". jsoftware.com. Retrieved 19 May 2022.
↑ Lamb, Linda. Learning the vi editor. O'Reilly.

बाहरी संबंध

C Style: Standards and Guidelines: Defining Programming Standards for Professional C Programmers, Prentice Hall, ISBN 0-13-116898-3 / ISBN 978-0-13-116898-5 (full text is also online). Straker, David (1992).
Contextual Indent
GNU Coding Standards
Source Code Formatters at Curlie

टैब और स्पेस

टैब बनाम स्पेस: एक शाश्वत पवित्र युद्ध जेमी ज़विंस्की द्वारा
क्यों मैं स्रोत कोड में कोई टैब पसंद नहीं करता एडम स्पियर्स द्वारा
मुझे स्रोत कोड में टैब रखना क्यों पसंद है (संग्रहीत)
इलास्टिक टैबस्टॉप - टैब-बनाम-स्पेस समस्या का समाधान

श्रेणी:सॉफ़्टवेयर युद्ध श्रेणी:पाठ संपादक सुविधाएँ श्रेणी:स्रोत कोड

[1] Zawinski, Jamie (2000). "Tabs versus Spaces: An Eternal Holy War". Retrieved 6 June 2016.

[2] "WordPress Coding Standards". Retrieved 6 June 2016.

[3] Hoffa, Felipe (26 July 2017). "400,000 GitHub repositories, 1 billion files, 14 terabytes of code: Spaces or Tabs?". Medium (in English). Retrieved 9 July 2019.

[4] Miara, Richard J.; Musselman, Joyce A.; Navarro, Juan A. & Shneiderman, Ben (November 1983). "Program Indentation and Comprehensibility" (PDF). Communications of the ACM. 26 (11): 861–867. doi:10.1145/182.358437. S2CID 11767796. Retrieved 3 August 2017.

[jargon-5] 5.0 ^5.1 ^5.2 "The Jargon File". 4.4.7. 29 December 2003. Retrieved 18 August 2014.

[6] Darwin, Ian F. (1988). Checking C programs with Lint. California: O'Reilly and Assosciates. p. 51. ISBN 9780937175309.

[catb.org-7] 7.0 ^7.1 "1TBS".

[8] "Java Style Guide". Archived from the original on 12 July 2018. Using either "Egyptian" curly braces or C-style curly braces is acceptable

[9] "Egyptian brackets". Foldoc. A humourous [sic] term for K&R indent style, referring to the "one hand up in front, one down behind" pose

[10] "Google JavaScript Style Guide". Braces follow the Kernighan and Ritchie style ("Egyptian brackets") for nonempty blocks and block-like constructs

[onetruestyle-11] 11.0 ^11.1 "Brace styles and JavaScript". 7 January 2013. Retrieved 8 November 2018.

[12] A detailed description of the style is given at kernel.org.

[13] Larabel, Michael. "The Linux Kernel Deprecates The 80 Character Line Coding Style". Phoronix. Phoronix Media. Retrieved 1 May 2022.

[14] Reddy, Achut (30 March 2000). "Java Coding Style Guide" (PDF). Sun Microsystems. Archived from the original (PDF) on 28 February 2006. Retrieved 30 May 2008.

[15] "Java Code Conventions" (PDF). Sun Microsystems. 12 September 1997. Archived from the original (PDF) on 13 May 2008. Retrieved 30 May 2008.

[16] "Code Conventions for the Java Programming Language". Sun Microsystems. 20 March 1997. Retrieved 30 May 2008.

[ppp-17] 17.0 ^17.1 Stroustrup, Bjarne (September 2010). "PPP Style Guide" (PDF).

[18] Stroustrup, Bjarne. "C++ Core Guidelines". GitHub. Retrieved 3 November 2018.

[C_Style_and_Coding_Standards_for_SunOS-19] 19.0 ^19.1 ^19.2 Shannon, Bill (19 August 1996). "C Style and Coding Standards for SunOS" (PDF). 1.8. Sun Microsystems, Inc. Retrieved 15 June 2019.

[DTraceToolkit_Style_Guide-20] 20.0 ^20.1 Gregg, Brendan. "DTraceToolkit Style Guide". Retrieved 6 February 2015.

[illumos-gate_cstyle-21] Shannon, Bill (9 September 1998). "cstyle.pl". illumos-gate. 1.58. Sun Microsystems, Inc. Retrieved 6 February 2015.

[allman-22] "indent style". The on-line hacker Jargon File. 4.4.7. 29 December 2003. Retrieved 20 March 2022 – via catb.

[mcconnell-23] 23.0 ^23.1 ^23.2 McConnell, Steve (2004). Code Complete: A practical handbook of software construction. Redmond, WA: Microsoft Press. pp. 746–747. ISBN 978-0-7356-1967-8.

[gnu.org-24] 24.0 ^24.1 "Formatting Your Source Code". GNU Coding Standards. Retrieved 6 June 2016.

[gnu.org-lisp-25] Stallman, Richard (28 October 2002). "My Lisp Experiences and the Development of GNU Emacs (Transcript of speech at the International Lisp Conference)". Retrieved 6 June 2016.

[26] Baumann, Richard [in Deutsch]; Feliciano, Manuel; Bauer, Friedrich Ludwig; Samelson, Klaus (1964). Introduction to ALGOL – A primer for the non-specialist, emphasizing the practical uses of the algorithmic language. Series in Automatic Computation. Englewood Cliffs, New Jersey, USA: Prentice-Hall, Inc. ISBN 0-13-477828-6. LCCN 64-10740. ark:/13960/t6qz35p37. Retrieved 23 October 2022.

[27] W. M. McKeeman, J. J. Horning, and D. B. Wortman, A Compiler Generator, 1970, https://archive.org/details/compilergenerato00mcke

[28] Tested on the sample source code above on Ubuntu 18.04 with GNU indent 2.2.11 and GNU Emacs 25.2.2 started with emacs --no-init-file.

[29] "Linux kernel coding style". Retrieved 1 January 2017.

[30] Jensen, Kathleen; Wirth, Niklaus (1974). PASCAL User Manual and Report. Springer-Verlag.

[31] Horstmann Style Guide

[32] Ohno, Asako (2013). "A methodology to teach exemplary coding style considering students' coding style feature contains fluctuations". 2013 IEEE Frontiers in Education Conference (FIE): 1908–1910. doi:10.1109/fie.2013.6685167. ISBN 9781467352611. S2CID 28385526.

[lammers-33] Lammers, Susan (1986). Programmers at Work. Microsoft Press. ISBN 978-0-914845-71-3.

[pattee-34] Pattee, Jim. "Artistic Style 2.05 Documentation". Artistic Style. Retrieved 24 April 2015.

[35] Kernighan, Brian W.; Plauger, P. J. (1976). Software Tools. Addison-Wesley.

[36] "The Haskell 98 Report". haskell.org. Retrieved 3 March 2016.

[37] Lipovača, Miran. "Making Our Own Types and Typeclasses". learnyouahaskell.com. Retrieved 3 February 2016.

[38] Haskell Report 1.2 (1992), p.131 B.4 "Layout"

[39] "The J Incunabulum". jsoftware.com. Retrieved 19 May 2022.

[40] Lamb, Linda. Learning the vi editor. O'Reilly.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

Anonymous

Search

इंडेंटेशन शैली: Difference between revisions

Namespaces

More

Page actions

Revision as of 18:20, 2 March 2023

Contents

यौगिक कथनो में ब्रेस प्लेसमेंट

टैब, रिक्त स्थान और इंडेंटेशन का आकार

उपकरण

शैलियाँ

के एंड आर शैली

वैरिएंट: 1TBS (OTBS)

संस्करण: लिनक्स कर्नेल

संस्करण: अनिवार्य ब्रेसिज़

संस्करण: जावा

संस्करण: स्ट्रॉस्ट्रुप

वैरिएंट: बीएसडी केएनएफ

ऑलमैन शैली

वैरिएंट: ऑलमैन-8

गोरे लोग शैली

जीएनयू शैली

होर्स्टमैन शैली

पिको शैली

रैटलिफ शैली

लिस्प शैली

हास्केल शैली

एपीएल शैली

अन्य विचार

ब्लॉक का ट्रैक खोना

वक्तव्य सम्मिलन

यह भी देखें

संदर्भ

बाहरी संबंध

टैब और स्पेस

Navigation

Navigation

Wiki tools

Wiki tools

@@ Line 2: / Line 2: @@
 {{For|a general discussion of indentation|Indentation (typesetting)}}
 {{Use dmy dates|date=October 2022}}
-[[कंप्यूटर प्रोग्रामिंग]] में, एक इंडेंटेशन शैली प्रोग्राम संरचना को संप्रेषित करने के लिए कोड के [[ब्लॉक (प्रोग्रामिंग)]] के [[इंडेंटेशन (टाइपसेटिंग)]] को नियंत्रित करने वाला एक सम्मेलन है। यह लेख मोटे तौर पर फ्री-फॉर्म भाषाओं को संबोधित करता है, जैसे [[सी ([[प्रोग्रामिंग भाषा]])]] और इसके वंश, लेकिन अधिकांश अन्य प्रोग्रामिंग भाषाओं (विशेष रूप से [[घुंघराले ब्रैकेट प्रोग्रामिंग भाषा]] में) पर लागू हो सकते हैं (और अक्सर होते हैं), जहां व्हॉट्सएप वर्ण है अन्यथा नगण्य। इंडेंटेशन शैली [[प्रोग्रामिंग शैली]] का केवल एक पहलू है।
-इंडेंटेशन अधिकांश प्रोग्रामिंग भाषाओं की आवश्यकता नहीं है, जहां इसे द्वितीयक संकेतन के रूप में उपयोग किया जाता है। इसके बजाय, इंडेंटिंग मानव पाठकों को प्रोग्राम की संरचना को बेहतर ढंग से व्यक्त करने में मदद करती है। विशेष रूप से, इसका उपयोग नियंत्रण प्रवाह निर्माणों जैसे स्थितियों या लूपों, और उनके भीतर और बाहर निहित कोड के बीच की कड़ी को स्पष्ट करने के लिए किया जाता है। हालाँकि, कुछ भाषाएँ (जैसे कि [[पायथन (प्रोग्रामिंग भाषा)]] और [[ओकैम (प्रोग्रामिंग भाषा)]]) ब्रेसिज़ या कीवर्ड का उपयोग करने के बजाय संरचना का निर्धारण करने के लिए इंडेंटेशन का उपयोग करती हैं; इसे ऑफ-साइड नियम कहा जाता है। ऐसी भाषाओं में, संकलक या दुभाषिया के लिए इंडेंटेशन अर्थपूर्ण है; यह केवल एक स्पष्टता या शैली के मुद्दे से अधिक है।
+[[कंप्यूटर प्रोग्रामिंग]] में एक इंडेंटेशन शैली प्रोग्राम संरचना को संप्रेषित करने के लिए कोड के [[ब्लॉक (प्रोग्रामिंग)]] के [[इंडेंटेशन (टाइपसेटिंग)]] को नियंत्रित करने वाला एक सम्मेलन है। यह लेख मोटे तौर पर फ्री-फॉर्म भाषाओं को संबोधित करता है जैसे [[सी ([[प्रोग्रामिंग भाषा]])]] और इसके वंश लेकिन अधिकांश अन्य प्रोग्रामिंग भाषाओं (विशेष रूप से [[घुंघराले ब्रैकेट प्रोग्रामिंग भाषा]] में) पर लागू हो सकते हैं जहां व्हॉट्सएप वर्ण है अन्यथा नगण्य। इंडेंटेशन शैली [[प्रोग्रामिंग शैली]] का केवल एक पहलू है।
-इस लेख में [[कोष्ठक]]#कोष्ठक को संदर्भित करने के लिए शब्द कोष्ठक का उपयोग किया गया है, और कर्ली कोष्ठक को संदर्भित करने के लिए शब्द कोष्ठक का उपयोग किया गया है।
+इंडेंटेशन अधिकांश प्रोग्रामिंग भाषाओं की आवश्यकता नहीं है जहां इसे द्वितीयक संकेतन के रूप में उपयोग किया जाता है। इसके बजाय इंडेंटिंग मानव पाठकों को प्रोग्राम की संरचना को बेहतर ढंग से व्यक्त करने में मदद करती है। विशेष रूप से इसका उपयोग नियंत्रण प्रवाह निर्माणों जैसे स्थितियों या लूपों और उनके भीतर और बाहर निहित कोड के बीच की कड़ी को स्पष्ट करने के लिए किया जाता है। हालाँकि कुछ भाषाएँ (जैसे कि [[पायथन (प्रोग्रामिंग भाषा)]] और [[ओकैम (प्रोग्रामिंग भाषा)]]) ब्रेसिज़ या कीवर्ड का उपयोग करने के बजाय संरचना का निर्धारण करने के लिए इंडेंटेशन का उपयोग करती हैं और इसे ऑफ-साइड नियम कहा जाता है। ऐसी भाषाओं में संकलक या दुभाषिया के लिए इंडेंटेशन अर्थपूर्ण है। यह केवल एक स्पष्टता या शैली के मुद्दे से अधिक है।
-== कंपाउंड स्टेटमेंट्स में ब्रेस प्लेसमेंट ==
+इस लेख में कोष्ठक को संदर्भित करने के लिए शब्द कोष्ठक का उपयोग किया गया है और कर्ली कोष्ठक को संदर्भित करने के लिए शब्द कोष्ठक का उपयोग किया गया है।
-इंडेंटेशन स्टाइल के बीच मुख्य अंतर कंपाउंड स्टेटमेंट के ब्रेसेस लगाने में निहित है (<code>{...}</code>) जो अक्सर एक नियंत्रण कथन का अनुसरण करता है (<code>if</code>, <code>while</code>, <code>for</code>...). नीचे दी गई तालिका इस आलेख में चर्चा की गई बयानों की शैली के लिए इस प्लेसमेंट को दर्शाती है; फ़ंक्शन घोषणा शैली एक और मामला है। बयानों में ब्रेस प्लेसमेंट की शैली फ़ंक्शन परिभाषा के ब्रेस प्लेसमेंट की शैली से भिन्न हो सकती है। स्थिरता के लिए, प्रत्येक शैली की पसंदीदा इंडेंटेशन गहराई के बावजूद इंडेंटेशन गहराई को 4 रिक्त स्थान पर स्थिर रखा गया है।
+== यौगिक कथनो में ब्रेस प्लेसमेंट ==
+इंडेंटेशन शैली के बीच मुख्य अंतर यौगिक कथन के ब्रेसेस लगाने में निहित है (<code>{...}</code>) जो अक्सर एक नियंत्रण कथन का अनुसरण करता है (<code>if</code>, <code>while</code>, <code>for</code>...). नीचे दी गई तालिका इस आलेख में चर्चा की गई बयानों की शैली के लिए इस प्लेसमेंट को दर्शाती है; कार्य  घोषणा शैली एक और स्थितिया है। बयानों में ब्रेस प्लेसमेंट की शैली कार्य परिभाषा के ब्रेस प्लेसमेंट की शैली से भिन्न हो सकती है। स्थिरता के लिए प्रत्येक शैली की पसंदीदा इंडेंटेशन गहराई के बजाय इंडेंटेशन गहराई को 4 रिक्त स्थान पर स्थिर रखा गया है।
 {| class="wikitable"
-! Brace placement !! Styles
+! ब्रेस प्लेसमेंट !! शैलियों
 |-
-| style="padding: 0 4px" | <syntaxhighlight lang=c>
+| style="padding: 0 4px" |  जबकि ( एक्स == वाई )
-while (x == y)
+ {
-{
+     कुछ ();
-    something();
+     कुछ और ();
-    somethingelse();
+ }
-}
-</syntaxhighlight>
+| सभी मर्द
-| [[#Allman style|Allman]]
 |-
-| style="padding: 0 4px" | <syntaxhighlight lang=c>
+| style="padding: 0 4px" |  जबकि ( एक्स == वाई ) {
-while (x == y) {
+     कुछ ();
-    something();
+     कुछ और ();
-    somethingelse();
+ }
-}
-</syntaxhighlight>
+| के एंड आर
-| [[#K&R style|K&R]]
 |-
-| style="padding: 0 4px" | <syntaxhighlight lang=c>
+| style="padding: 0 4px" |  जबकि ( एक्स == वाई )
-while (x == y)
+   {
-  {
+     कुछ ();
-    something ();
+     कुछ और ();
-    somethingelse ();
+   }
-  }
-</syntaxhighlight>
+| जीएनयू
-| [[#GNU style|GNU]]
 |-
-| style="padding: 0 4px" | <syntaxhighlight lang=c>
+| style="padding: 0 4px" |  जबकि ( एक्स == वाई )
-while (x == y)
+     {
-    {
+     कुछ ();
-    something();
+     कुछ और ();
-    somethingelse();
+     }
-    }
-</syntaxhighlight>
+| गोरे लोग
-| [[#Whitesmiths style|Whitesmiths]]
 |-
-| style="padding: 0 4px" | <syntaxhighlight lang=c>
+| style="padding: 0 4px" |  जबकि ( एक्स == वाई )
-while (x == y)
+ { कुछ ();
-{   something();
+     कुछ और ();
-    somethingelse();
+ }
-}
-</syntaxhighlight>
+| होर्स्टमैन
-| [[#Horstmann style|Horstmann]]
 |-
-| style="padding: 0 4px" | <syntaxhighlight lang=c>
+| style="padding: 0 4px" |  जबकि ( एक्स == वाई )
-while (x == y)
+ { कुछ ();
-{   something();
+     कुछ और (); }
-    somethingelse(); }
-</syntaxhighlight>
+| पिको
-| [[#Pico style|Pico]]
 |-
-| style="padding: 0 4px" | <syntaxhighlight lang=c>
+| style="padding: 0 4px" |  जबकि ( एक्स == वाई ) {
-while (x == y) {
+     कुछ ();
-    something();
+     कुछ और ();
-    somethingelse();
+     }
-    }
-</syntaxhighlight>
+| रैटलिफ
-| [[#Ratliff style|Ratliff]]
 |-
-| style="padding: 0 4px" | <syntaxhighlight lang=c>
+| style="padding: 0 4px" |  जबकि ( एक्स == वाई )
-while (x == y)
+   { कुछ ();
-  { something();
+     कुछ और (); }
-    somethingelse(); }
-</syntaxhighlight>
+| तुतलाना
-| [[#Lisp style|Lisp]]
 |-
-| style="padding: 0 4px" | <syntaxhighlight lang=c>
+| style="padding: 0 4px" |  <nowiki># परिभाषित डब्ल्यू (सी, बी) {जबकि (सी) {बी}}
-#define W(c,b) {while(c){b}}
+ डब्ल्यू ( एक्स == वाई , एस (); से ();)</nowiki>
-W(x==y,s();se();)
-</syntaxhighlight>
+| एपीएल
-| [[#APL style|APL]]
 |}
 == टैब, रिक्त स्थान और इंडेंटेशन का आकार ==
-टैब के लिए प्रदर्शित चौड़ाई अधिकांश प्रोग्रामिंग संपादकों में मनमाने मूल्यों पर सेट की जा सकती है, जिसमें [[Notepad++]] (MS-Windows), [[TextEdit]] (MacOS/X), Emacs (Unix), vi (Unix), और nano (Unix) शामिल हैं। इसके अलावा, इन संपादकों को विशिष्ट इंडेंटेशन योजनाओं से मेल खाने के लिए टैब और रिक्त स्थान का मिश्रण उत्पन्न करने या टैब और रिक्त स्थान के बीच कनवर्ट करने के लिए कॉन्फ़िगर किया जा सकता है। [[यूनिक्स]] में, टैब की चौड़ाई को [[टर्मिनल पेजर]] में भी सेट किया जा सकता है, जैसे [[कम (यूनिक्स)]], और फ़िल्टर द्वारा फ्लाई पर परिवर्तित किया जा सकता है, जैसे [[विस्तृत करें (यूनिक्स)]]/[[unexpand]]।
+टैब के लिए प्रदर्शित चौड़ाई अधिकांश प्रोग्रामिंग संपादकों में मनमाने मूल्यों पर सेट की जा सकती है जिसमें [[Notepad++]] (एमएस-विंडोज), [[TextEdit]] (MacOS/X), Emacs (यूनिक्स), vi (यूनिक्स), और nano (यूनिक्स) सम्मिलित हैं। इसके अतिरिक्त  इन संपादकों को विशिष्ट इंडेंटेशन योजनाओं से मेल खाने के लिए टैब और रिक्त स्थान का मिश्रण उत्पन्न करने या टैब और रिक्त स्थान के बीच परिवर्तित करने के लिए कॉन्फ़िगर किया जा सकता है। [[यूनिक्स]] में टैब की चौड़ाई को [[टर्मिनल पेजर]] में भी सेट किया जा सकता है जैसे [[कम (यूनिक्स)]], और फ़िल्टर द्वारा फ्लाई पर परिवर्तित किया जा सकता है जैसे विस्तृत / अनएक्सपैंड।
-यूनिक्स संपादक आठ स्तंभों के अंतराल पर पोजिशनिंग टैब के लिए डिफ़ॉल्ट हैं, जबकि [[मैक (कंप्यूटर)]] और [[माइक्रोसॉफ़्ट विंडोज़]] | एमएस-विंडोज वातावरण चार कॉलमों के लिए डिफ़ॉल्ट हैं। यह अंतर स्रोत कोड मिसलिग्न्मेंट का कारण बनता है, जब टैब और रिक्त स्थान को मिलाने वाला इंडेंटेशन एक कॉन्फ़िगरेशन के तहत प्रदर्शित होता है जो लेखक के कॉन्फ़िगरेशन से अलग टैब प्रदर्शित करता है।
-हार्ड टैब और स्पेस के बीच चुनाव को लेकर प्रोग्रामरों के बीच बहस चल रही है। कई प्रारंभिक प्रोग्रामर इंडेंट करने, टाइप करने में आसानी के लिए और स्रोत फ़ाइल आकार को बचाने के लिए टैब कुंजी वर्णों का उपयोग करते थे। कुछ प्रोग्रामर, जैसे [[जेमी ज़विंस्की]], कहते हैं कि टैब के बजाय रिक्त स्थान का उपयोग करने से [[क्रॉस-प्लेटफॉर्म]] [[में porting]] बढ़ जाती है।<ref>{{cite web |url=http://www.jwz.org/doc/tabs-vs-spaces.html |title=Tabs versus Spaces: An Eternal Holy War |first=Jamie |last=Zawinski |year=2000 |access-date=6 June 2016}}</ref> अन्य, जैसे कि [[WordPress के]] कोडिंग मानकों के लेखक, इसके विपरीत कहते हैं: हार्ड टैब पोर्टेबिलिटी बढ़ाते हैं।<ref>{{cite web |url=http://codex.wordpress.org/WordPress_Coding_Standards#Indentation |title=WordPress Coding Standards |access-date=6 June 2016}}</ref> [[GitHub]] पर शीर्ष 400,000 रिपॉजिटरी के एक सर्वेक्षण में पाया गया कि रिक्त स्थान अधिक सामान्य हैं।<ref>{{cite web|url=https://medium.com/@hoffa/400-000-github-repositories-1-billion-files-14-terabytes-of-code-spaces-or-tabs-7cfe0b5dd7fd|title=400,000 GitHub repositories, 1 billion files, 14 terabytes of code: Spaces or Tabs?|last=Hoffa|first=Felipe|date=2017-07-26|website=Medium|language=en|access-date=2019-07-09}}</ref>
+यूनिक्स संपादक आठ स्तंभों के अंतराल पर स्थिति निर्धारण टैब के लिए गलत हैं जबकि [[मैक (कंप्यूटर)]] और [[माइक्रोसॉफ़्ट विंडोज़]] | एमएस-विंडोज वातावरण चार कॉलमों के लिए गलत  हैं। यह अंतर स्रोत कोड मिसलिग्न्मेंट का कारण बनता है जब टैब और रिक्त स्थान को मिलाने वाला इंडेंटेशन एक विन्यास के तहत प्रदर्शित होता है जो लेखक के विन्यास से अलग टैब प्रदर्शित करता है।
-इंडेंटेशन का आकार आमतौर पर शैली से स्वतंत्र होता है। 1983 में PASCAL कोड पर किए गए एक प्रयोग में पाया गया कि इंडेंटेशन आकार ने बोधगम्यता को महत्वपूर्ण रूप से प्रभावित किया। 2 और 4 अक्षरों के बीच का इंडेंटेशन आकार इष्टतम साबित हुआ।<ref>{{cite journal |last1=Miara |first1=Richard J. |last2=Musselman |first2=Joyce A. |last3=Navarro |first3=Juan A. |last4=Shneiderman |first4=Ben |name-list-style=amp |date=November 1983 |title=Program Indentation and Comprehensibility |url=http://www.cs.umd.edu/~ben/papers/Miara1983Program.pdf |access-date=3 August 2017 |journal=Communications of the ACM |volume=26 |number=11 |pages=861–867 |doi=10.1145/182.358437|s2cid=11767796 }}</ref> [[रूबी (प्रोग्रामिंग भाषा)]], कई [[खोल स्क्रिप्ट]]िंग लैंग्वेज और [[HTML]] फॉर्मेटिंग के कुछ रूपों के लिए, दो स्पेस प्रति इंडेंटेशन लेवल का आमतौर पर उपयोग किया जाता है।{{Citation needed|date=February 2007}}
+हार्ड टैब और स्पेस के बीच चुनाव को लेकर प्रोग्रामरों के बीच बहस चल रही है। कई प्रारंभिक प्रोग्रामर इंडेंट करने टाइप करने में आसानी के लिए और स्रोत फ़ाइल आकार को बचाने के लिए टैब कुंजी वर्णों का उपयोग करते थे। कुछ प्रोग्रामर जैसे [[जेमी ज़विंस्की]] कहते हैं कि टैब के बजाय रिक्त स्थान का उपयोग करने से क्रॉस-प्लेटफ़ॉर्म पोर्टेबिलिटी बढ़ जाती है।<ref>{{cite web |url=http://www.jwz.org/doc/tabs-vs-spaces.html |title=Tabs versus Spaces: An Eternal Holy War |first=Jamie |last=Zawinski |year=2000 |access-date=6 June 2016}}</ref> अन्य जैसे कि वर्डप्रेस कोडिंग मानकों के लेखक इसके विपरीत कहते हैं कि हार्ड टैब पोर्टेबिलिटी बढ़ाते हैं।<ref>{{cite web |url=http://codex.wordpress.org/WordPress_Coding_Standards#Indentation |title=WordPress Coding Standards |access-date=6 June 2016}}</ref> [[GitHub|गिटहब]] पर शीर्ष 400,000 कोष के एक सर्वेक्षण में पाया गया कि रिक्त स्थान अधिक सामान्य हैं।<ref>{{cite web|url=https://medium.com/@hoffa/400-000-github-repositories-1-billion-files-14-terabytes-of-code-spaces-or-tabs-7cfe0b5dd7fd|title=400,000 GitHub repositories, 1 billion files, 14 terabytes of code: Spaces or Tabs?|last=Hoffa|first=Felipe|date=2017-07-26|website=Medium|language=en|access-date=2019-07-09}}</ref>
+इंडेंटेशन का आकार प्राय: शैली से स्वतंत्र होता है। 1983 में PASCAL कोड पर किए गए एक प्रयोग में पाया गया कि इंडेंटेशन आकार ने बोधगम्यता को महत्वपूर्ण रूप से प्रभावित किया। 2 और 4 अक्षरों के बीच का इंडेंटेशन आकार इष्टतम साबित हुआ।<ref>{{cite journal |last1=Miara |first1=Richard J. |last2=Musselman |first2=Joyce A. |last3=Navarro |first3=Juan A. |last4=Shneiderman |first4=Ben |name-list-style=amp |date=November 1983 |title=Program Indentation and Comprehensibility |url=http://www.cs.umd.edu/~ben/papers/Miara1983Program.pdf |access-date=3 August 2017 |journal=Communications of the ACM |volume=26 |number=11 |pages=861–867 |doi=10.1145/182.358437|s2cid=11767796 }}</ref> [[रूबी (प्रोग्रामिंग भाषा)]] कई [[खोल स्क्रिप्ट]] भाषा और [[HTML]]  प्रारूपण के कुछ रूपों के लिए दो स्पेस प्रति इंडेंटेशन लेवल का प्राय: उपयोग किया जाता है।{{Citation needed|date=February 2007}}
 == उपकरण ==
-इंडेंटेशन शैलियों के बीच कनवर्ट करने के लिए कई टूल हैं, जैसे <code>[[indent (Unix)|indent]]</code>, कई यूनिक्स जैसे [[ऑपरेटिंग सिस्टम]] के साथ शामिल एक प्रोग्राम।
+इंडेंटेशन शैलियों के बीच परिवर्तित करने के लिए कई टूल हैं, जैसे <code>[[indent (Unix)|indent]]</code>, कई यूनिक्स जैसे [[ऑपरेटिंग सिस्टम]] के साथ सम्मिलित  एक प्रोग्राम।
-[[Emacs]] में, हिटिंग सहित इंडेंटेशन समस्याओं को स्वचालित रूप से ठीक करने के लिए विभिन्न कमांड उपलब्ध हैं <code>Tab</code> किसी दिए गए लाइन पर (डिफ़ॉल्ट कॉन्फ़िगरेशन में)। <code>M-x indent-region</code> कोड के बड़े हिस्से को ठीक से इंडेंट करने के लिए इस्तेमाल किया जा सकता है। मोड के आधार पर, Emacs प्रमुख इंडेंटेशन स्पेस को रिक्त स्थान के बाद उचित संख्या में टैब के साथ बदल सकता है, जिसके परिणामस्वरूप प्रत्येक स्रोत लाइन को इंडेंट करने के लिए वर्णों की न्यूनतम संख्या होती है।
+[[Emacs]] में, हिटिंग सहित इंडेंटेशन समस्याओं को स्वचालित रूप से ठीक करने के लिए विभिन्न कमांड उपलब्ध हैं <code>Tab</code> किसी दिए गए लाइन पर (गलत  विन्यास में)। <code>M-x indent-region</code> कोड के बड़े हिस्से को ठीक से इंडेंट करने के लिए इस्तेमाल किया जा सकता है। मोड के आधार पर, Emacs प्रमुख इंडेंटेशन स्पेस को रिक्त स्थान के बाद उचित संख्या में टैब के साथ बदल सकता है, जिसके परिणामस्वरूप प्रत्येक स्रोत लाइन को इंडेंट करने के लिए वर्णों की न्यूनतम संख्या होती है।
 [[लोचदार टैबस्टॉप]] एक सारणीकरण शैली है जिसे टेक्स्ट एडिटर से समर्थन की आवश्यकता होती है, जहां ब्लॉक में एक पंक्ति की लंबाई बदलने पर टेक्स्ट के पूरे ब्लॉक को स्वचालित रूप से संरेखित रखा जाता है।
@@ Line 107: / Line 97: @@
 === के एंड आर शैली ===
 {{anchor|1TBS|OTBS|1TBF}}
-के एंड आर शैली (कर्निघन और रिची शैली), और हैकर शब्दजाल में बारीकी से संबंधित एक सच्ची ब्रेस शैली<ref name=jargon>{{cite web |url=http://www.catb.org/jargon/html/I/indent-style.html |title=The Jargon File |version=4.4.7 |date=29 December 2003 |access-date=18 August 2014}}</ref><ref>{{cite book |url={{google books|id=vweTteq3OLQC|page=51|plain-url=yes}} |title=Checking C programs with Lint |first=Ian F. |last=Darwin |publisher=O'Reilly and Assosciates |location=California |page=51 |isbn=9780937175309|year=1988 }}</ref> (1TBS के रूप में संक्षिप्त<ref name="catb.org">{{Cite web|url=http://catb.org/jargon/html/0/one-TBS.html|title=1TBS}}</ref>), आमतौर पर सी, [[सी ++]], और अन्य घुंघराले-ब्रेस प्रोग्रामिंग भाषाओं में उपयोग की जाती हैं। यह मूल यूनिक्स कर्नेल, [[ब्रायन कर्निघन]] और डेनिस रिची में इस्तेमाल की जाने वाली शैली थी। रिची की पुस्तक द [[[[कर्ली-ब्रेस प्रोग्रामिंग लैंग्वेज]]]], साथ ही कर्निघन और पी. जे. प्लेगर की पुस्तक [[प्रोग्रामिंग शैली के तत्व]]
+के एंड आर शैली (कर्निघन और रिची शैली), और हैकर शब्दजाल में बारीकी से संबंधित एक सच्ची ब्रेस शैली<ref name=jargon>{{cite web |url=http://www.catb.org/jargon/html/I/indent-style.html |title=The Jargon File |version=4.4.7 |date=29 December 2003 |access-date=18 August 2014}}</ref><ref>{{cite book |url={{google books|id=vweTteq3OLQC|page=51|plain-url=yes}} |title=Checking C programs with Lint |first=Ian F. |last=Darwin |publisher=O'Reilly and Assosciates |location=California |page=51 |isbn=9780937175309|year=1988 }}</ref> (1TBS के रूप में संक्षिप्त<ref name="catb.org">{{Cite web|url=http://catb.org/jargon/html/0/one-TBS.html|title=1TBS}}</ref>), प्राय: सी, [[सी ++]], और अन्य घुंघराले-ब्रेस प्रोग्रामिंग भाषाओं में उपयोग की जाती हैं। यह मूल यूनिक्स कर्नेल, [[ब्रायन कर्निघन]] और डेनिस रिची में इस्तेमाल की जाने वाली शैली थी। रिची की पुस्तक द [[[[कर्ली-ब्रेस प्रोग्रामिंग लैंग्वेज|कर्ली-ब्रेस प्रोग्रामिंग भाषा]] ]], साथ ही कर्निघन और पी. जे. प्लेगर की पुस्तक [[प्रोग्रामिंग शैली के तत्व]]
-के एंड आर का पालन करते समय, प्रत्येक फ़ंक्शन में अगली पंक्ति में उसी इंडेंटेशन स्तर पर उसके शीर्षलेख के रूप में उद्घाटन ब्रेस होता है, ब्रेसिज़ के भीतर बयान इंडेंट होते हैं, और अंत में समापन ब्रेस फ़ंक्शन के शीर्षलेख के समान इंडेंटेशन स्तर पर होता है अपनी खुद की एक पंक्ति में।
+के एंड आर का पालन करते समय, प्रत्येक कार्य  में अगली पंक्ति में उसी इंडेंटेशन स्तर पर उसके शीर्षलेख के रूप में उद्घाटन ब्रेस होता है, ब्रेसिज़ के भीतर बयान इंडेंट होते हैं, और अंत में समापन ब्रेस कार्य  के शीर्षलेख के समान इंडेंटेशन स्तर पर होता है अपनी खुद की एक पंक्ति में।
-{{anchor|Egyptian}} एक फ़ंक्शन के अंदर बहु-पंक्ति ब्लॉक, हालांकि, उनके संबंधित नियंत्रण बयानों के समान लाइन पर उनके उद्घाटन ब्रेसिज़ होते हैं; क्लोजिंग ब्रेसिज़ स्वयं की एक पंक्ति में रहते हैं, जब तक कि एक कीवर्ड द्वारा पीछा नहीं किया जाता <code>else</code> या <code>while</code>. इस तरह के गैर-[[टाइपोग्राफिक संरेखण]] ब्रेसिज़ को मिस्र के ब्रेसिज़ (या मिस्र के कोष्ठक) के नाम से जाना जाता है, जो प्राचीन मिस्र के कुछ काल्पनिक पोज़ में हथियारों के समान हैं।<ref>{{cite web |title=Java Style Guide |url=https://www.seas.upenn.edu/~cis120/current/java_style.shtml#f |quote=Using either "Egyptian" curly braces or C-style curly braces is acceptable |url-status=dead |archive-url=https://web.archive.org/web/20180712222126/https://www.seas.upenn.edu/~cis120/current/java_style.shtml |archive-date=2018-07-12}}</ref><ref>{{cite web |title=Egyptian brackets |url=http://foldoc.org/Egyptian+brackets |website=[[Foldoc]] |quote=A {{sic|humou|rous}} term for K&R indent style, referring to the "one hand up in front, one down behind" pose}}</ref><ref>{{cite web |title=Google JavaScript Style Guide |url=https://google.github.io/styleguide/jsguide.html#formatting-nonempty-blocks |quote=Braces follow the Kernighan and Ritchie style ("Egyptian brackets") for nonempty blocks and block-like constructs}}</ref> K&R में, सिंगल-लाइन ब्लॉक में ब्रेसेस नहीं होते हैं।
+{{anchor|Egyptian}} एक कार्य  के अंदर बहु-पंक्ति ब्लॉक, हालांकि, उनके संबंधित नियंत्रण बयानों के समान लाइन पर उनके उद्घाटन ब्रेसिज़ होते हैं; क्लोजिंग ब्रेसिज़ स्वयं की एक पंक्ति में रहते हैं, जब तक कि एक कीवर्ड द्वारा पीछा नहीं किया जाता <code>else</code> या <code>while</code>. इस तरह के गैर-[[टाइपोग्राफिक संरेखण]] ब्रेसिज़ को मिस्र के ब्रेसिज़ (या मिस्र के कोष्ठक) के नाम से जाना जाता है, जो प्राचीन मिस्र के कुछ काल्पनिक पोज़ में हथियारों के समान हैं।<ref>{{cite web |title=Java Style Guide |url=https://www.seas.upenn.edu/~cis120/current/java_style.shtml#f |quote=Using either "Egyptian" curly braces or C-style curly braces is acceptable |url-status=dead |archive-url=https://web.archive.org/web/20180712222126/https://www.seas.upenn.edu/~cis120/current/java_style.shtml |archive-date=2018-07-12}}</ref><ref>{{cite web |title=Egyptian brackets |url=http://foldoc.org/Egyptian+brackets |website=[[Foldoc]] |quote=A {{sic|humou|rous}} term for K&R indent style, referring to the "one hand up in front, one down behind" pose}}</ref><ref>{{cite web |title=Google JavaScript Style Guide |url=https://google.github.io/styleguide/jsguide.html#formatting-nonempty-blocks |quote=Braces follow the Kernighan and Ritchie style ("Egyptian brackets") for nonempty blocks and block-like constructs}}</ref> K&R में, सिंगल-लाइन ब्लॉक में ब्रेसेस नहीं होते हैं।
 <वाक्यविन्यास प्रकाश लैंग = सी>
@@ Line 132: / Line 122: @@
 </वाक्यविन्यास हाइलाइट>
-सी प्रोग्रामिंग लैंग्वेज#इन्फ्लुएंस इस शैली को स्पष्ट रूप से निर्दिष्ट नहीं करता है, हालांकि पूरी किताब में इसका लगातार पालन किया जाता है। पुस्तक से:
+सी प्रोग्रामिंग भाषा #इन्फ्लुएंस इस शैली को स्पष्ट रूप से निर्दिष्ट नहीं करता है, हालांकि पूरी किताब में इसका लगातार पालन किया जाता है। पुस्तक से:
 <ब्लॉककोट>
 ब्रेसिज़ की स्थिति कम महत्वपूर्ण है, हालांकि लोग भावुक विश्वास रखते हैं। हमने कई लोकप्रिय शैलियों में से एक को चुना है। एक शैली चुनें जो आपको सूट करे, फिर उसका लगातार उपयोग करें।
 </ब्लॉककोट>
-सी भाषा के पुराने संस्करणों में, तर्क प्रकारों को बाद की पंक्ति पर घोषित करने की आवश्यकता होती है (यानी, फ़ंक्शन के शीर्षलेख के ठीक बाद):
+सी भाषा के पुराने संस्करणों में, तर्क प्रकारों को बाद की पंक्ति पर घोषित करने की आवश्यकता होती है (यानी, कार्य  के शीर्षलेख के ठीक बाद):
 <वाक्यविन्यास प्रकाश लैंग = सी>
-/* फंक्शन प्रोटोटाइप के बिना मूल प्री-आईएसओ सी स्टाइल */
+/* फंक्शन प्रोटोटाइप के बिना मूल प्री-आईएसओ सी शैली */
 इंट मेन (एआरजीसी, एआरजीवी)
      इंट एआरजीसी;
@@ Line 156: / Line 146: @@
 इस शैली में, नए कोड लाइनों के सम्मिलन की अनुमति देने वाले निर्माण अलग-अलग लाइनों पर होते हैं, और सम्मिलन को प्रतिबंधित करने वाले निर्माण एक पंक्ति पर होते हैं। इस सिद्धांत को एकल-पंक्ति सशर्त सहित हर अगर, और, जबकि, आदि को मजबूत करके बढ़ाया जाता है, ताकि कोड की एक नई पंक्ति को कहीं भी सम्मिलित करना हमेशा सुरक्षित रहे (यानी, इस तरह के सम्मिलन से निष्पादन का प्रवाह असहमत नहीं होगा) स्रोत कोड इंडेंटिंग)।
-इस शैली के सुझाए गए फायदे यह हैं कि शुरुआती ब्रेस को अकेले अतिरिक्त लाइन की आवश्यकता नहीं होती है, और एंडिंग ब्रेस उस स्टेटमेंट के साथ लाइन अप करता है जो वैचारिक रूप से संबंधित है। इस शैली की एक लागत यह है कि एक ब्लॉक के अंतिम ब्रेस को अकेले एक पूरी लाइन की आवश्यकता होती है, जिसे आंशिक रूप से if/else ब्लॉक और डू/जबकि ब्लॉक में हल किया जा सकता है:
+इस शैली के सुझाए गए फायदे यह हैं कि शुरुआती ब्रेस को अकेले अतिरिक्त लाइन की आवश्यकता नहीं होती है, और एंडिंग ब्रेस उस कथन के साथ लाइन अप करता है जो वैचारिक रूप से संबंधित है। इस शैली की एक लागत यह है कि एक ब्लॉक के अंतिम ब्रेस को अकेले एक पूरी लाइन की आवश्यकता होती है, जिसे आंशिक रूप से if/else ब्लॉक और डू/जबकि ब्लॉक में हल किया जा सकता है:
 <वाक्यविन्यास प्रकाश लैंग = सी>
@@ Line 168: / Line 158: @@
 </वाक्यविन्यास हाइलाइट>
-द वन ट्रू ब्रेस स्टाइल के कई उल्लेख हैं, लेकिन इसके वास्तविक रूप को लेकर कुछ भ्रम है। कुछ सूत्रों का कहना है कि यह ऊपर निर्दिष्ट भिन्नता है,<ref name=onetruestyle />जबकि अन्य ध्यान दें कि यह के एंड आर के लिए सिर्फ एक और हैकर शब्दजाल के रूप में है।<ref name=jargon/>
+द वन ट्रू ब्रेस शैली के कई उल्लेख हैं, लेकिन इसके वास्तविक रूप को लेकर कुछ भ्रम है। कुछ सूत्रों का कहना है कि यह ऊपर निर्दिष्ट भिन्नता है,<ref name=onetruestyle />जबकि अन्य ध्यान दें कि यह के एंड आर के लिए सिर्फ एक और हैकर शब्दजाल के रूप में है।<ref name=jargon/>
@@ Line 174: / Line 164: @@
 K&R शैली का एक लघु संस्करण Linux कर्नेल शैली है, जो Linux कर्नेल के स्रोत ट्री में इसके व्यापक उपयोग के लिए जानी जाती है।<ref>A detailed description of the style is given at [https://www.kernel.org/doc/html/latest/process/coding-style.html kernel.org].</ref> [[लिनस टोरवाल्ड्स]] दृढ़ता से सभी योगदानकर्ताओं को इसका पालन करने की सलाह देते हैं। शैली के एंड आर से कई तत्वों को उधार लेती है।
-कर्नेल शैली इंडेंटेशन के लिए [[टैब का विश्राम स्थान]] का उपयोग करती है (टैब स्टॉप प्रत्येक 8 वर्ण सेट करता है)। किसी फ़ंक्शन के घुंघराले ब्रेसिज़ को खोलना फ़ंक्शन हेडर के बाद लाइन की शुरुआत में जाता है। कोई भी अन्य ओपनिंग कर्ली ब्रेसेस उसी लाइन पर चलते हैं, जिस पर संबंधित स्टेटमेंट एक स्पेस द्वारा अलग किया जाता है। ए में लेबल <code>switch</code> बयान संलग्न ब्लॉक के साथ गठबंधन कर रहे हैं (इंडेंट का केवल एक स्तर है)। लाइन की लंबाई 80 वर्णों तक सीमित हुआ करती थी{{snd}} इसे 2020 में बढ़ाकर 100 कर दिया गया था, लेकिन मूल सीमा को अभी भी पसंद किया जाता है।<ref>{{cite web |last1=Larabel |first1=Michael |title=The Linux Kernel Deprecates The 80 Character Line Coding Style |url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Deprecates-80-Col |website=Phoronix |publisher=Phoronix Media |access-date=1 May 2022}}</ref> कंपाउंड स्टेटमेंट के सिंगल-स्टेटमेंट बॉडी (जैसे कि अगर, जबकि, और डू-वाइल) को घुंघराले ब्रेसिज़ से घिरा नहीं होना चाहिए। यदि, हालांकि, एक में एक या एक से अधिक सबस्टेटमेंट <code>if-else</code> स्टेटमेंट में ब्रेसिज़ की आवश्यकता होती है, तो दोनों सबस्टेटमेंट को कर्ली ब्रेसिज़ के अंदर लपेटा जाना चाहिए:
+कर्नेल शैली इंडेंटेशन के लिए [[टैब का विश्राम स्थान]] का उपयोग करती है (टैब स्टॉप प्रत्येक 8 वर्ण सेट करता है)। किसी कार्य  के घुंघराले ब्रेसिज़ को खोलना कार्य  हेडर के बाद लाइन की शुरुआत में जाता है। कोई भी अन्य ओपनिंग कर्ली ब्रेसेस उसी लाइन पर चलते हैं, जिस पर संबंधित कथन एक स्पेस द्वारा अलग किया जाता है। ए में लेबल <code>switch</code> बयान संलग्न ब्लॉक के साथ गठबंधन कर रहे हैं (इंडेंट का केवल एक स्तर है)। लाइन की लंबाई 80 वर्णों तक सीमित हुआ करती थी{{snd}} इसे 2020 में बढ़ाकर 100 कर दिया गया था, लेकिन मूल सीमा को अभी भी पसंद किया जाता है।<ref>{{cite web |last1=Larabel |first1=Michael |title=The Linux Kernel Deprecates The 80 Character Line Coding Style |url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Deprecates-80-Col |website=Phoronix |publisher=Phoronix Media |access-date=1 May 2022}}</ref> यौगिक कथन के सिंगल-स्टेटमेंट बॉडी (जैसे कि अगर, जबकि, और डू-वाइल) को घुंघराले ब्रेसिज़ से घिरा नहीं होना चाहिए। यदि, हालांकि, एक में एक या एक से अधिक सबस्टेटमेंट <code>if-else</code> कथन में ब्रेसिज़ की आवश्यकता होती है, तो दोनों सबस्टेटमेंट को कर्ली ब्रेसिज़ के अंदर लपेटा जाना चाहिए:
 <वाक्यविन्यास प्रकाश लैंग = सी>
@@ Line 198: / Line 188: @@
 ==== संस्करण: जावा ====
-जबकि [[जावा (प्रोग्रामिंग भाषा)]] को कभी-कभी अन्य शैलियों में लिखा जाता है, जावा कोड का एक महत्वपूर्ण निकाय #K&R Style|K&R शैली के एक मामूली संस्करण का उपयोग करता है जिसमें ओपनिंग ब्रेस एक ही लाइन पर होता है न कि केवल एक फ़ंक्शन के अंदर ब्लॉक के लिए, लेकिन कक्षा या विधि घोषणाओं के लिए भी।
+जबकि [[जावा (प्रोग्रामिंग भाषा)]] को कभी-कभी अन्य शैलियों में लिखा जाता है, जावा कोड का एक महत्वपूर्ण निकाय #K&R Style|K&R शैली के एक मामूली संस्करण का उपयोग करता है जिसमें ओपनिंग ब्रेस एक ही लाइन पर होता है न कि केवल एक कार्य  के अंदर ब्लॉक के लिए, लेकिन कक्षा या विधि घोषणाओं के लिए भी।
 यह शैली काफी हद तक व्यापक है क्योंकि [[सन माइक्रोसिस्टम्स]] की मूल शैली गाइड करती है<ref>{{cite web |url=http://developers.sun.com/prodtech/cc/products/archive/whitepapers/java-style.pdf |title=Java Coding Style Guide |last=Reddy |first=Achut |publisher=Sun Microsystems |date=30 March 2000 |access-date=30 May 2008 |url-status=dead |archive-url=https://web.archive.org/web/20060228095122/http://developers.sun.com/prodtech/cc/products/archive/whitepapers/java-style.pdf |archive-date=28 February 2006}}</ref><ref>{{cite web |url=http://java.sun.com/docs/codeconv/CodeConventions.pdf |title=Java Code Conventions |publisher=Sun Microsystems |date=12 September 1997 |access-date=30 May 2008 |url-status=dead |archive-url=https://web.archive.org/web/20080513084244/http://java.sun.com/docs/codeconv/CodeConventions.pdf |archive-date=13 May 2008}}</ref><ref>{{cite web
 | url=http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
@@ Line 235: / Line 225: @@
 </वाक्यविन्यास हाइलाइट>
-स्ट्रॉस्ट्रुप लेबल को इंडेंट नहीं करता है {{code|public:}} और {{code|private:}}. इसके अलावा, इस शैली में, जबकि एक फ़ंक्शन की ओपनिंग ब्रेस एक नई लाइन पर शुरू होती है, एक क्लास की ओपनिंग ब्रेस उसी लाइन पर होती है जिस पर क्लास का नाम होता है।
+स्ट्रॉस्ट्रुप लेबल को इंडेंट नहीं करता है {{code|public:}} और {{code|private:}}. इसके अतिरिक्त   इस शैली में, जबकि एक कार्य  की ओपनिंग ब्रेस एक नई लाइन पर शुरू होती है, एक क्लास की ओपनिंग ब्रेस उसी लाइन पर होती है जिस पर क्लास का नाम होता है।
 स्ट्रॉस्ट्रुप छोटे कार्यों को एक पंक्ति में लिखने की अनुमति देता है। स्ट्राउस्ट्रप शैली एक नामांकित इंडेंटेशन शैली है जो संपादक Emacs में उपलब्ध है। स्ट्रॉस्ट्रुप अपने आधुनिक सी++ कोर दिशानिर्देशों में बताए गए अनुसार सी++ के साथ एक के एंड आर-व्युत्पन्न शैली लेआउट को प्रोत्साहित करता है।<ref>{{cite web |last1=Stroustrup |first1=Bjarne |title=C++ Core Guidelines |url=https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#nl17-use-kr-derived-layout |website=GitHub |access-date=3 November 2018}}</ref>
@@ Line 245: / Line 235: @@
 इस शैली में, हार्ड टेबुलेटर (ts in [[vi]]) को आठ कॉलम में रखा जाता है, जबकि एक सॉफ्ट टेबुलेटर को अक्सर एक सहायक (sw in vi) के रूप में भी परिभाषित किया जाता है, और चार पर सेट किया जाता है। हार्ड टेबुलेटर्स का उपयोग कोड ब्लॉक इंडेंट करने के लिए किया जाता है, जबकि अतिरिक्त इंडेंटेशन के सॉफ्ट टेबुलेटर (चार रिक्त स्थान) का उपयोग उन सभी निरंतर लाइनों के लिए किया जाता है जिन्हें कई लाइनों में विभाजित किया जाना चाहिए।
-इसके अलावा, फ़ंक्शन कॉल कोष्ठक से पहले एक स्थान का उपयोग नहीं करते हैं, हालांकि सी-भाषा मूल कथन जैसे <code>if</code>, <code>while</code>, <code>do</code>, <code>switch</code> और <code>return</code> करें (मामले में जहां <code>return</code> Parens के साथ प्रयोग किया जाता है)। ऐसे कार्य जो अपने शीर्ष-स्तरीय ब्लॉक में कोई स्थानीय चर घोषित नहीं करते हैं, उनके शुरुआती ब्लॉक ब्रेस के बाद भी एक खाली रेखा छोड़नी चाहिए।
+इसके अतिरिक्त   कार्य  कॉल कोष्ठक से पहले एक स्थान का उपयोग नहीं करते हैं, हालांकि सी-भाषा मूल कथन जैसे <code>if</code>, <code>while</code>, <code>do</code>, <code>switch</code> और <code>return</code> करें (मामले में जहां <code>return</code> Parens के साथ प्रयोग किया जाता है)। ऐसे कार्य जो अपने शीर्ष-स्तरीय ब्लॉक में कोई स्थानीय चर घोषित नहीं करते हैं, उनके शुरुआती ब्लॉक ब्रेस के बाद भी एक खाली रेखा छोड़नी चाहिए।
 यहाँ कुछ नमूने देखें:
@@ Line 287: / Line 277: @@
 </वाक्यविन्यास हाइलाइट>
-=== ऑलमैन स्टाइल ===
+=== ऑलमैन शैली ===
 {{anchor|Allman|Allman style|BSD/Allman style}}
 ऑलमैन शैली का नाम [[एरिक एलमैन]] के नाम पर रखा गया है। इसे कभी-कभी बीएसडी शैली भी कहा जाता है क्योंकि ऑलमैन ने बर्कले सॉफ्टवेयर डिस्ट्रीब्यूशन यूनिक्स के लिए कई उपयोगिताओं को लिखा था (हालांकि इसे अलग-अलग बीएसडी केएनएफ शैली के साथ भ्रमित नहीं होना चाहिए; ऊपर देखें)।
@@ Line 305: / Line 295: @@
 <वाक्यविन्यास लैंग = पास्कल>
-(* पास्कल में ऑलमैन कोड इंडेंटेशन स्टाइल का उदाहरण *)
+(* पास्कल में ऑलमैन कोड इंडेंटेशन शैली का उदाहरण *)
 प्रक्रिया dosomething(x, y: पूर्णांक);
 शुरू
@@ Line 315: / Line 305: @@
 अंत;
 </वाक्यविन्यास हाइलाइट>
-इस शैली के परिणाम यह हैं कि इंडेंट कोड स्पष्ट रूप से उन पंक्तियों के द्वारा युक्त कथन से अलग होता है जो लगभग सभी व्हाइटस्पेस वर्ण होते हैं और समापन ब्रेस उसी कॉलम में होते हैं जो उद्घाटन ब्रेस के रूप में होते हैं। कुछ लोगों को लगता है कि इससे मैचिंग ब्रेसेस ढूंढना आसान हो जाता है। अवरुद्ध शैली संबंधित नियंत्रण कथन से कोड के ब्लॉक को भी चित्रित करती है। कंट्रोल स्टेटमेंट या कोड के ब्लॉक, या [[कोड रीफैक्टरिंग]] पर टिप्पणी करने या हटाने से लटकने या लापता ब्रेसिज़ के माध्यम से सिंटैक्स त्रुटियों को पेश करने की संभावना कम होती है। साथ ही, यह बाहरी फ़ंक्शन ब्लॉक के लिए ब्रेस प्लेसमेंट के अनुरूप है।
+इस शैली के परिणाम यह हैं कि इंडेंट कोड स्पष्ट रूप से उन पंक्तियों के द्वारा युक्त कथन से अलग होता है जो लगभग सभी व्हाइटस्पेस वर्ण होते हैं और समापन ब्रेस उसी कॉलम में होते हैं जो उद्घाटन ब्रेस के रूप में होते हैं। कुछ लोगों को लगता है कि इससे मैचिंग ब्रेसेस ढूंढना आसान हो जाता है। अवरुद्ध शैली संबंधित नियंत्रण कथन से कोड के ब्लॉक को भी चित्रित करती है। कंट्रोल कथन या कोड के ब्लॉक, या [[कोड रीफैक्टरिंग]] पर टिप्पणी करने या हटाने से लटकने या लापता ब्रेसिज़ के माध्यम से सिंटैक्स त्रुटियों को पेश करने की संभावना कम होती है। साथ ही, यह बाहरी कार्य  ब्लॉक के लिए ब्रेस प्लेसमेंट के अनुरूप है।
 उदाहरण के लिए, निम्नलिखित अभी भी वाक्य रचनात्मक रूप से सही है:
@@ Line 352: / Line 342: @@
-=== [[गोरे लोग]] स्टाइल ===
+=== [[गोरे लोग]] शैली ===
 व्हाइटस्मिथ शैली, जिसे कभी-कभी विशरट शैली भी कहा जाता है, मूल रूप से पहले वाणिज्यिक सी कंपाइलर, व्हाइटस्मिथ कंपाइलर के लिए प्रलेखन में उपयोग की गई थी। यह विंडोज के शुरुआती दिनों में भी लोकप्रिय था, क्योंकि इसका उपयोग तीन प्रभावशाली विंडोज प्रोग्रामिंग किताबों में किया गया था, [[डेविड ड्यूरेंट]], [[कार्लसन की क्षमता]] और [[पॉल याओ]] द्वारा प्रोग्रामर गाइड टू विंडोज, [[चार्ल्स पेटज़ोल्ड]] द्वारा [[प्रोग्रामिंग विंडोज]], और पीटर द्वारा विंडोज 3.0 पावर प्रोग्रामिंग तकनीक नॉर्टन और याओ।
 जार्गन फ़ाइल के अनुसार, व्हाईटस्मिथ, #ऑलमैन शैली के साथ, समान लोकप्रियता के साथ सबसे आम ब्रेसिंग शैली रही है।<ref name=jargon/>
-यह शैली नियंत्रण कथन से जुड़े ब्रेस को अगली पंक्ति पर इंडेंट करती है। ब्रेसिज़ के भीतर स्टेटमेंट्स को ब्रेसिज़ के समान स्तर पर इंडेंट किया जाता है।
+यह शैली नियंत्रण कथन से जुड़े ब्रेस को अगली पंक्ति पर इंडेंट करती है। ब्रेसिज़ के भीतर कथन्स को ब्रेसिज़ के समान स्तर पर इंडेंट किया जाता है।
 रैटलिफ़ शैली की तरह, समापन ब्रेस को ब्रेसिज़ के भीतर बयानों के समान ही इंडेंट किया जाता है।<ref name="mcconnell" />
@@ Line 371: / Line 361: @@
 </वाक्यविन्यास हाइलाइट>
-इस शैली के फायदे #Allman शैली के समान हैं। ब्लॉक स्पष्ट रूप से नियंत्रण बयानों से अलग हैं। ब्लॉक के साथ ब्रेसिज़ का संरेखण इस बात पर जोर देता है कि पूर्ण ब्लॉक संकल्पनात्मक और प्रोग्रामेटिक रूप से एक मिश्रित कथन है। ब्रेसिज़ को इंडेंट करना इस बात पर जोर देता है कि वे कंट्रोल स्टेटमेंट के अधीन हैं। अंतिम ब्रेस अब कथन के अनुरूप नहीं है, बल्कि ओपनिंग ब्रेस के साथ है।
+इस शैली के फायदे #Allman शैली के समान हैं। ब्लॉक स्पष्ट रूप से नियंत्रण बयानों से अलग हैं। ब्लॉक के साथ ब्रेसिज़ का संरेखण इस बात पर जोर देता है कि पूर्ण ब्लॉक संकल्पनात्मक और प्रोग्रामेटिक रूप से एक मिश्रित कथन है। ब्रेसिज़ को इंडेंट करना इस बात पर जोर देता है कि वे कंट्रोल कथन के अधीन हैं। अंतिम ब्रेस अब कथन के अनुरूप नहीं है, बल्कि ओपनिंग ब्रेस के साथ है।
 एक उदाहरण:
@@ Line 391: / Line 381: @@
 </वाक्यविन्यास हाइलाइट>
-<code>else if</code> कथन के रूप में व्यवहार किया जाता है, जैसे कि <code>#elif</code> प्रीप्रोसेसर स्टेटमेंट।
+<code>else if</code> कथन के रूप में व्यवहार किया जाता है, जैसे कि <code>#elif</code> प्रीप्रोसेसर कथन।
 === जीएनयू शैली ===
 {{Main article|GNU coding standards}}
-#ऑलमैन स्टाइल और #व्हाईटस्मिथ्स स्टाइल स्टाइल की तरह, [[GNU]] स्टाइल एक लाइन पर खुद से ब्रेसिज़ लगाती है, दो स्पेस द्वारा इंडेंट किया जाता है, सिवाए फंक्शन डेफिनिशन को ओपन करने के, जहां वे इंडेंट नहीं होते हैं।<ref name="gnu.org">{{cite web
+#ऑलमैन शैली और #व्हाईटस्मिथ्स शैली शैली की तरह, [[GNU]] शैली एक लाइन पर खुद से ब्रेसिज़ लगाती है, दो स्पेस द्वारा इंडेंट किया जाता है, सिवाए फंक्शन डेफिनिशन को ओपन करने के, जहां वे इंडेंट नहीं होते हैं।<ref name="gnu.org">{{cite web
 |url=https://www.gnu.org/prep/standards/html_node/Formatting.html
 |title=Formatting Your Source Code
@@ Line 402: / Line 392: @@
 }}</ref> किसी भी मामले में, निहित कोड को ब्रेसिज़ से दो रिक्त स्थान द्वारा इंडेंट किया जाता है।
-[[रिचर्ड स्टालमैन]] द्वारा लोकप्रिय, लेआउट [[लिस्प (प्रोग्रामिंग भाषा)]] कोड लिखने की उनकी पृष्ठभूमि से प्रभावित हो सकता है।<ref name="gnu.org-lisp">{{cite web |url=https://www.gnu.org/gnu/rms-lisp.html |title=My Lisp Experiences and the Development of GNU Emacs (Transcript of speech at the International Lisp Conference) |first=Richard |last=Stallman |date=28 October 2002 |access-date=6 June 2016}}</ref> लिस्प में, एक ब्लॉक (एक प्रोग्न) के बराबर एक प्रथम श्रेणी की डेटा इकाई है, और इसे अपना इंडेंटेशन स्तर देने से उस पर जोर देने में मदद मिलती है, जबकि सी में, एक ब्लॉक केवल सिंटैक्स है। यह शैली 1960 और 1970 के दशक की कुछ [[ALGOL]] और [[XPL]] प्रोग्रामिंग भाषा पाठ्यपुस्तकों में भी पाई जा सकती है।<ref>{{cite book |author-last1=Baumann |author-first1=Richard |author-link1=:de:Richard Baumann (Mathematiker) |author-last2=Feliciano |author-first2=Manuel<!--, Jr.? --> |author-last3=Bauer |author-first3=Friedrich Ludwig |author-link3=Friedrich Ludwig Bauer |author-last4=Samelson |author-first4=Klaus |author-link4=Klaus Samelson |date=1964 |title=Introduction to ALGOL – A primer for the non-specialist, emphasizing the practical uses of the algorithmic language |series=Series in Automatic Computation |publisher=[[Prentice-Hall, Inc.]] |publication-place=Englewood Cliffs, New Jersey, USA |isbn=0-13-477828-6 |lccn=64-10740 |id=ark:/13960/t6qz35p37 |url=https://archive.org/details/introductiontoal00baum |access-date=2022-10-23}}</ref><ref>W. M. McKeeman, J. J. Horning, and D. B. Wortman, ''A Compiler Generator'', 1970, https://archive.org/details/compilergenerato00mcke</ref>{{discuss|editorial option in lieu of source}} हालांकि सीधे इंडेंटेशन से संबंधित नहीं है, जीएनयू कोडिंग शैली में फ़ंक्शन के तर्कों की ब्रैकेटेड सूची से पहले एक स्थान भी शामिल है।
+[[रिचर्ड स्टालमैन]] द्वारा लोकप्रिय, लेआउट [[लिस्प (प्रोग्रामिंग भाषा)]] कोड लिखने की उनकी पृष्ठभूमि से प्रभावित हो सकता है।<ref name="gnu.org-lisp">{{cite web |url=https://www.gnu.org/gnu/rms-lisp.html |title=My Lisp Experiences and the Development of GNU Emacs (Transcript of speech at the International Lisp Conference) |first=Richard |last=Stallman |date=28 October 2002 |access-date=6 June 2016}}</ref> लिस्प में, एक ब्लॉक (एक प्रोग्न) के बराबर एक प्रथम श्रेणी की डेटा इकाई है, और इसे अपना इंडेंटेशन स्तर देने से उस पर जोर देने में मदद मिलती है, जबकि सी में, एक ब्लॉक केवल सिंटैक्स है। यह शैली 1960 और 1970 के दशक की कुछ [[ALGOL]] और [[XPL]] प्रोग्रामिंग भाषा पाठ्यपुस्तकों में भी पाई जा सकती है।<ref>{{cite book |author-last1=Baumann |author-first1=Richard |author-link1=:de:Richard Baumann (Mathematiker) |author-last2=Feliciano |author-first2=Manuel<!--, Jr.? --> |author-last3=Bauer |author-first3=Friedrich Ludwig |author-link3=Friedrich Ludwig Bauer |author-last4=Samelson |author-first4=Klaus |author-link4=Klaus Samelson |date=1964 |title=Introduction to ALGOL – A primer for the non-specialist, emphasizing the practical uses of the algorithmic language |series=Series in Automatic Computation |publisher=[[Prentice-Hall, Inc.]] |publication-place=Englewood Cliffs, New Jersey, USA |isbn=0-13-477828-6 |lccn=64-10740 |id=ark:/13960/t6qz35p37 |url=https://archive.org/details/introductiontoal00baum |access-date=2022-10-23}}</ref><ref>W. M. McKeeman, J. J. Horning, and D. B. Wortman, ''A Compiler Generator'', 1970, https://archive.org/details/compilergenerato00mcke</ref>{{discuss|editorial option in lieu of source}} हालांकि सीधे इंडेंटेशन से संबंधित नहीं है, जीएनयू कोडिंग शैली में कार्य  के तर्कों की ब्रैकेटेड सूची से पहले एक स्थान भी सम्मिलित  है।
 <वाक्यविन्यास प्रकाश लैंग = सी>
@@ Line 417: / Line 407: @@
 </वाक्यविन्यास हाइलाइट><ref name="gnu.org"/>
-यह शैली #ऑलमैन शैली और #व्हाईटस्मिथ शैली के लाभों को जोड़ती है, जिससे ब्लॉक से बाहर नहीं खड़े होने वाले ब्रेसिज़ के संभावित व्हाइटस्मिथ नुकसान को दूर किया जाता है। एक नुकसान यह है कि अंतिम ब्रेस अब उस कथन के अनुरूप नहीं है जिससे यह अवधारणात्मक रूप से संबंधित है। एक और संभावित नुकसान यह है कि यह एक वैचारिक स्तर के लिए इंडेंट के दो दृश्य स्तरों का उपयोग करके स्थान को बर्बाद कर सकता है, लेकिन वास्तव में यह संभावना नहीं है, क्योंकि एकल-स्तरीय इंडेंटेशन वाले सिस्टम में, प्रत्येक स्तर आमतौर पर कम से कम 4 रिक्त स्थान होता है, जैसा कि 2 * जीएनयू शैली में 2 रिक्त स्थान।
+यह शैली #ऑलमैन शैली और #व्हाईटस्मिथ शैली के लाभों को जोड़ती है, जिससे ब्लॉक से बाहर नहीं खड़े होने वाले ब्रेसिज़ के संभावित व्हाइटस्मिथ नुकसान को दूर किया जाता है। एक नुकसान यह है कि अंतिम ब्रेस अब उस कथन के अनुरूप नहीं है जिससे यह अवधारणात्मक रूप से संबंधित है। एक और संभावित नुकसान यह है कि यह एक वैचारिक स्तर के लिए इंडेंट के दो दृश्य स्तरों का उपयोग करके स्थान को बर्बाद कर सकता है, लेकिन वास्तव में यह संभावना नहीं है, क्योंकि एकल-स्तरीय इंडेंटेशन वाले सिस्टम में, प्रत्येक स्तर प्राय: कम से कम 4 रिक्त स्थान होता है, जैसा कि 2 * जीएनयू शैली में 2 रिक्त स्थान।
 GNU कोडिंग मानक इस शैली की अनुशंसा करते हैं, और [[जीएनयू परियोजना]] सॉफ़्टवेयर के लगभग सभी अनुरक्षक इसका उपयोग करते हैं।{{Citation needed|date=February 2013}}
-[[GNU Emacs]] टेक्स्ट एडिटर और GNU सिस्टम का इंडेंट (Unix) कमांड डिफ़ॉल्ट रूप से इस शैली के अनुसार कोड को रिफॉर्मेट करेगा।<ref>Tested on the sample source code above on Ubuntu 18.04 with GNU indent 2.2.11 and GNU Emacs 25.2.2 started with <code>emacs --no-init-file</code>.</ref> जो लोग GNU Emacs, या समान रूप से एक्स्टेंसिबल/अनुकूलन योग्य संपादकों का उपयोग नहीं करते हैं, वे पा सकते हैं कि उनके संपादक की स्वचालित इंडेंटेशन सेटिंग्स इस शैली के लिए अनुपयोगी हैं। हालांकि, केएनएफ शैली के लिए डिफॉल्ट करने वाले कई संपादक जीएनयू शैली के साथ अच्छी तरह से सामना करते हैं जब टैब की चौड़ाई दो स्थानों पर सेट होती है; इसी तरह, GNU Emacs केवल टैब की चौड़ाई को आठ स्थानों पर सेट करके KNF शैली के अनुकूल हो जाता है। दोनों ही मामलों में, स्वचालित सुधार मूल रिक्ति को नष्ट कर देता है, लेकिन स्वचालित लाइन इंडेंटिंग ठीक से काम करेगी।
+[[GNU Emacs]] टेक्स्ट एडिटर और GNU सिस्टम का इंडेंट (Unix) कमांड गलत  रूप से इस शैली के अनुसार कोड को रिफॉर्मेट करेगा।<ref>Tested on the sample source code above on Ubuntu 18.04 with GNU indent 2.2.11 and GNU Emacs 25.2.2 started with <code>emacs --no-init-file</code>.</ref> जो लोग GNU Emacs, या समान रूप से एक्स्टेंसिबल/अनुकूलन योग्य संपादकों का उपयोग नहीं करते हैं, वे पा सकते हैं कि उनके संपादक की स्वचालित इंडेंटेशन सेटिंग्स इस शैली के लिए अनुपयोगी हैं। हालांकि, केएनएफ शैली के लिए डिफॉल्ट करने वाले कई संपादक जीएनयू शैली के साथ अच्छी तरह से सामना करते हैं जब टैब की चौड़ाई दो स्थानों पर सेट होती है; इसी तरह, GNU Emacs केवल टैब की चौड़ाई को आठ स्थानों पर सेट करके KNF शैली के अनुकूल हो जाता है। दोनों ही मामलों में, स्वचालित सुधार मूल रिक्ति को नष्ट कर देता है, लेकिन स्वचालित लाइन इंडेंटिंग ठीक से काम करेगी।
 [[स्टीव मैककोनेल]], अपनी पुस्तक [[कोड पूर्ण]] में, इस शैली का उपयोग करने के खिलाफ सलाह देते हैं: वह एक कोड नमूना चिह्नित करता है जो कोडिंग हॉरर आइकन के साथ इसका उपयोग करता है, विशेष रूप से खतरनाक कोड का प्रतीक है, और कहता है कि यह पठनीयता को बाधित करता है।<ref name="mcconnell" >{{cite book |title=Code Complete: A practical handbook of software construction |url=https://archive.org/details/codecomplete0000mcco |url-access=registration |last=McConnell |first=Steve |publisher=Microsoft Press |year=2004 |isbn=978-0-7356-1967-8 |location=Redmond, WA |pages=[https://archive.org/details/codecomplete0000mcco/page/746 746–747] |author-link=Steve McConnell}}</ref> लिनक्स कर्नेल कोडिंग शैली प्रलेखन भी इस शैली के खिलाफ दृढ़ता से अनुशंसा करता है, पाठकों से जीएनयू कोडिंग मानकों की एक प्रति को एक महान प्रतीकात्मक संकेत के रूप में जलाने का आग्रह करता है।<ref>{{cite web |title=Linux kernel coding style |url=https://www.kernel.org/doc/Documentation/process/coding-style.rst |access-date=1 January 2017}}</ref>
@@ Line 426: / Line 416: @@
 === होर्स्टमैन शैली ===
-के एस. होर्स्टमैन द्वारा कम्प्यूटिंग कॉन्सेप्ट्स विद सी++ एसेंशियल्स का 1997 का संस्करण ओपनिंग ब्रेस के समान लाइन पर एक ब्लॉक के पहले स्टेटमेंट को रखकर #ऑलमैन शैली को अपनाता है। इस शैली का उपयोग जेन्सेन और विर्थ के पास्कल यूजर मैनुअल और रिपोर्ट के उदाहरणों में भी किया जाता है।<ref>{{cite book |first1=Kathleen |last1=Jensen |first2=Niklaus |last2=Wirth |title=PASCAL User Manual and Report |publisher=Springer-Verlag |year=1974}}</ref>
+के एस. होर्स्टमैन द्वारा कम्प्यूटिंग कॉन्सेप्ट्स विद सी++ एसेंशियल्स का 1997 का संस्करण ओपनिंग ब्रेस के समान लाइन पर एक ब्लॉक के पहले कथन को रखकर #ऑलमैन शैली को अपनाता है। इस शैली का उपयोग जेन्सेन और विर्थ के पास्कल यूजर मैनुअल और रिपोर्ट के उदाहरणों में भी किया जाता है।<ref>{{cite book |first1=Kathleen |last1=Jensen |first2=Niklaus |last2=Wirth |title=PASCAL User Manual and Report |publisher=Springer-Verlag |year=1974}}</ref>
 <वाक्यविन्यास प्रकाश लैंग = सी>
 जबकि (एक्स == वाई)
@@ Line 448: / Line 438: @@
 === पिको शैली ===
-यह शैली [[पिको (प्रोग्रामिंग भाषा)]] भाषा में इसके डिजाइनरों द्वारा सबसे अधिक उपयोग की जाती है। पिको में रिटर्न स्टेटमेंट का अभाव है, और टर्मिनेटर के बजाय अर्धविराम को स्टेटमेंट सेपरेटर के रूप में उपयोग करता है। यह इस वाक्यविन्यास को उत्पन्न करता है:<ref>{{Cite journal|last=Ohno|first=Asako|date=2013|title=A methodology to teach exemplary coding style considering students' coding style feature contains fluctuations|journal=2013 IEEE Frontiers in Education Conference (FIE) |pages=1908–1910|doi=10.1109/fie.2013.6685167|isbn=9781467352611 |s2cid=28385526}}</ref>
+यह शैली [[पिको (प्रोग्रामिंग भाषा)]] भाषा में इसके डिजाइनरों द्वारा सबसे अधिक उपयोग की जाती है। पिको में रिटर्न कथन का अभाव है, और टर्मिनेटर के बजाय अर्धविराम को कथन सेपरेटर के रूप में उपयोग करता है। यह इस वाक्यविन्यास को उत्पन्न करता है:<ref>{{Cite journal|last=Ohno|first=Asako|date=2013|title=A methodology to teach exemplary coding style considering students' coding style feature contains fluctuations|journal=2013 IEEE Frontiers in Education Conference (FIE) |pages=1908–1910|doi=10.1109/fie.2013.6685167|isbn=9781467352611 |s2cid=28385526}}</ref>
 <!--no geshi support for pico-->
@@ Line 460: / Line 450: @@
 फायदे और नुकसान के एंड आर शैली के साथ स्क्रीन रियल एस्टेट को बचाने के समान हैं। एक अतिरिक्त लाभ यह है कि प्रारंभिक और समापन ब्रेसिज़ K&R शैली के सापेक्ष अनुप्रयोग में सुसंगत हैं (दोनों कोड की एक पंक्ति के साथ स्थान साझा करते हैं), जहां एक ब्रेस कोड की एक पंक्ति के साथ स्थान साझा करता है और एक ब्रेस में केवल एक पंक्ति होती है।
-=== रैटलिफ स्टाइल ===
+=== रैटलिफ शैली ===
-प्रोग्रामर एट वर्क पुस्तक में,<ref name=lammers>{{cite book |last=Lammers |first=Susan |title=Programmers at Work |year=1986 |publisher=Microsoft Press |isbn=978-0-914845-71-3 |url-access=registration |url=https://archive.org/details/programmersatwor00lamm_0 }}</ref> सी. वेन रैटलिफ़ ने नीचे दी गई शैली का उपयोग करते हुए चर्चा की। शैली 1TBS की तरह शुरू होती है लेकिन फिर नेस्टेड ब्लॉक के इंडेंटेशन के साथ क्लोजिंग ब्रेस लाइन अप हो जाती है। रैटलिफ़ लोकप्रिय [[dBase]]-II और -III [[चौथी पीढ़ी की प्रोग्रामिंग भाषा]]ओं के पीछे मूल प्रोग्रामर थे। उन्होंने संकेत दिया कि यह मूल रूप से [[डिजिटल अनुसंधान]] इंक से सामग्री में प्रलेखित था। इस शैली को कभी-कभी बैनर शैली कहा जाता है,<ref name=pattee>{{cite web |last1=Pattee |first1=Jim |title=Artistic Style 2.05 Documentation |url=http://astyle.sourceforge.net/astyle.html |website=Artistic Style |access-date=24 April 2015}}</ref> संभवतः एक खंभे से लटके हुए बैनर के समानता के लिए। इस शैली में, जो कि #व्हाईटस्मिथ्स शैली के लिए है जैसे के एंड आर ऑलमैन के लिए है, समापन नियंत्रण को सूची में अंतिम आइटम के समान ही इंडेंट किया गया है (और इस प्रकार उचित रूप से प्रमुखता खो देता है)<ref name="mcconnell" />शैली कुछ लोगों के लिए विज़ुअल स्कैनिंग को आसान बना सकती है, क्योंकि किसी भी ब्लॉक के हेडर ही उस स्तर पर एक्सडेंट होते हैं (सिद्धांत यह है कि पूर्व ब्लॉक का समापन नियंत्रण K&R में अगले ब्लॉक हेडर के दृश्य प्रवाह के साथ हस्तक्षेप करता है और ऑलमैन स्टाइल)। सॉफ्टवेयर टूल्स में रैटफोर कोड में कर्निघन और प्लेगर इस शैली का उपयोग करते हैं।<ref>{{cite book |first1=Brian W. |last1=Kernighan |first2=P. J. |last2=Plauger |title=Software Tools |url=https://archive.org/details/softwaretools00kern |url-access=registration |publisher=Addison-Wesley |year=1976}}</ref>
+प्रोग्रामर एट वर्क पुस्तक में,<ref name=lammers>{{cite book |last=Lammers |first=Susan |title=Programmers at Work |year=1986 |publisher=Microsoft Press |isbn=978-0-914845-71-3 |url-access=registration |url=https://archive.org/details/programmersatwor00lamm_0 }}</ref> सी. वेन रैटलिफ़ ने नीचे दी गई शैली का उपयोग करते हुए चर्चा की। शैली 1TBS की तरह शुरू होती है लेकिन फिर नेस्टेड ब्लॉक के इंडेंटेशन के साथ क्लोजिंग ब्रेस लाइन अप हो जाती है। रैटलिफ़ लोकप्रिय [[dBase]]-II और -III [[चौथी पीढ़ी की प्रोग्रामिंग भाषा]]ओं के पीछे मूल प्रोग्रामर थे। उन्होंने संकेत दिया कि यह मूल रूप से [[डिजिटल अनुसंधान]] इंक से सामग्री में प्रलेखित था। इस शैली को कभी-कभी बैनर शैली कहा जाता है,<ref name=pattee>{{cite web |last1=Pattee |first1=Jim |title=Artistic Style 2.05 Documentation |url=http://astyle.sourceforge.net/astyle.html |website=Artistic Style |access-date=24 April 2015}}</ref> संभवतः एक खंभे से लटके हुए बैनर के समानता के लिए। इस शैली में, जो कि #व्हाईटस्मिथ्स शैली के लिए है जैसे के एंड आर ऑलमैन के लिए है, समापन नियंत्रण को सूची में अंतिम आइटम के समान ही इंडेंट किया गया है (और इस प्रकार उचित रूप से प्रमुखता खो देता है)<ref name="mcconnell" />शैली कुछ लोगों के लिए विज़ुअल स्कैनिंग को आसान बना सकती है, क्योंकि किसी भी ब्लॉक के हेडर ही उस स्तर पर एक्सडेंट होते हैं (सिद्धांत यह है कि पूर्व ब्लॉक का समापन नियंत्रण K&R में अगले ब्लॉक हेडर के दृश्य प्रवाह के साथ हस्तक्षेप करता है और ऑलमैन शैली)। सॉफ्टवेयर टूल्स में रैटफोर कोड में कर्निघन और प्लेगर इस शैली का उपयोग करते हैं।<ref>{{cite book |first1=Brian W. |last1=Kernighan |first2=P. J. |last2=Plauger |title=Software Tools |url=https://archive.org/details/softwaretools00kern |url-access=registration |publisher=Addison-Wesley |year=1976}}</ref>
 <वाक्यविन्यास प्रकाश लैंग = सी>
   // सी में
@@ Line 546: / Line 536: @@
 </वाक्यविन्यास हाइलाइट>
 हास्केल में, लेआउट ब्रेसिज़ को बदल सकता है।
-आमतौर पर [[प्रक्रियात्मक प्रोग्रामिंग]] के लिए ब्रेसिज़ और अर्धविराम छोड़े जाते हैं <code>do</code> वर्गों और सामान्य रूप से कार्यक्रम पाठ, लेकिन शैली का उपयोग आमतौर पर सूचियों, अभिलेखों और अन्य वाक्य-विन्यास तत्वों के लिए किया जाता है, जो कोष्ठक या ब्रेसिज़ की कुछ जोड़ी से बना होता है, जो अल्पविराम या अर्धविराम से अलग होते हैं।<ref>{{cite web |url=http://learnyouahaskell.com/making-our-own-types-and-typeclasses |title=Making Our Own Types and Typeclasses |access-date=3 February 2016 |website=learnyouahaskell.com |last=Lipovača |first=Miran}}</ref> यदि कोड कीवर्ड का अनुसरण करता है <code>where</code>, <code>let</code>, या <code>of</code> ब्रेसिज़ और अर्धविराम छोड़ देता है, तो इंडेंटेशन महत्वपूर्ण है।<ref>Haskell Report 1.2 (1992), p.131 B.4 "Layout"</ref>
+प्राय: [[प्रक्रियात्मक प्रोग्रामिंग]] के लिए ब्रेसिज़ और अर्धविराम छोड़े जाते हैं <code>do</code> वर्गों और सामान्य रूप से कार्यक्रम पाठ, लेकिन शैली का उपयोग प्राय: सूचियों, अभिलेखों और अन्य वाक्य-विन्यास तत्वों के लिए किया जाता है, जो कोष्ठक या ब्रेसिज़ की कुछ जोड़ी से बना होता है, जो अल्पविराम या अर्धविराम से अलग होते हैं।<ref>{{cite web |url=http://learnyouahaskell.com/making-our-own-types-and-typeclasses |title=Making Our Own Types and Typeclasses |access-date=3 February 2016 |website=learnyouahaskell.com |last=Lipovača |first=Miran}}</ref> यदि कोड कीवर्ड का अनुसरण करता है <code>where</code>, <code>let</code>, या <code>of</code> ब्रेसिज़ और अर्धविराम छोड़ देता है, तो इंडेंटेशन महत्वपूर्ण है।<ref>Haskell Report 1.2 (1992), p.131 B.4 "Layout"</ref>
 === एपीएल शैली ===
-आम तौर पर एपीएल कितना संक्षिप्त है, इसके उदाहरण के लिए, यहां गेम ऑफ लाइफ के लिए स्टेप फंक्शन का कार्यान्वयन है:
+प्राय: एपीएल कितना संक्षिप्त है, इसके उदाहरण के लिए, यहां गेम ऑफ लाइफ के लिए स्टेप फंक्शन का कार्यान्वयन है:
-<syntaxhighlight lang=apl>
+<nowiki><syntaxhighlight lang=apl></nowiki>
 जीवन←{⊃1⍵∨.∧3 4=+/+⌿¯1 0 1∘.⊖¯1 0 1⌽¨⊂⍵}
 </वाक्यविन्यास हाइलाइट>
-[[एपीएल (प्रोग्रामिंग भाषा)]] स्टाइल सी एपीएल कोड की संक्षिप्त शैली जैसा दिखता है, और आमतौर पर उनके कार्यान्वयन में उपयोग किया जाता है।<ref>{{cite web |url=https://www.jsoftware.com/ioj/iojATW.htm |title=The J Incunabulum |access-date=19 May 2022 |website=jsoftware.com}}</ref> इस शैली का नेतृत्व [[आर्थर व्हिटनी (कंप्यूटर वैज्ञानिक)]] द्वारा किया गया था, और इसका उपयोग के (प्रोग्रामिंग भाषा), आर्थर की अपनी परियोजना के कार्यान्वयन में किया जाता है। J (प्रोग्रामिंग लैंग्वेज) प्रोग्रामिंग लैंग्वेज को भी इस शैली में लागू किया गया है। विशेष रूप से, APL के सभी कार्यान्वयन C की इस शैली का उपयोग नहीं करते हैं, अर्थात्: GNU APL और Dyalog APL।
+[[एपीएल (प्रोग्रामिंग भाषा)]] शैली सी एपीएल कोड की संक्षिप्त शैली जैसा दिखता है, और प्राय: उनके कार्यान्वयन में उपयोग किया जाता है।<ref>{{cite web |url=https://www.jsoftware.com/ioj/iojATW.htm |title=The J Incunabulum |access-date=19 May 2022 |website=jsoftware.com}}</ref> इस शैली का नेतृत्व [[आर्थर व्हिटनी (कंप्यूटर वैज्ञानिक)]] द्वारा किया गया था, और इसका उपयोग के (प्रोग्रामिंग भाषा), आर्थर की अपनी परियोजना के कार्यान्वयन में किया जाता है। J (प्रोग्रामिंग भाषा ) प्रोग्रामिंग भाषा  को भी इस शैली में लागू किया गया है। विशेष रूप से, APL के सभी कार्यान्वयन C की इस शैली का उपयोग नहीं करते हैं, अर्थात्: GNU APL और Dyalog APL।
-एपीएल शैली सी इंडेंटेशन के अलावा, आमतौर पर नामों को एकल या दोहरे वर्णों में छोटा किया जाता है: इंडेंटेशन की मात्रा को कम करने के लिए, और कई पंक्तियों में फैले भाव।
+एपीएल शैली सी इंडेंटेशन के अतिरिक्त   प्राय: नामों को एकल या दोहरे वर्णों में छोटा किया जाता है: इंडेंटेशन की मात्रा को कम करने के लिए, और कई पंक्तियों में फैले भाव।
 == अन्य विचार ==
 === ब्लॉक का ट्रैक खोना ===
-कुछ स्थितियों में, ब्लॉक सीमाओं का ट्रैक खोने का जोखिम होता है। यह अक्सर कोड के बड़े वर्गों में देखा जाता है जिसमें इंडेंटेशन के कई स्तरों के लिए नेस्टेड कई कंपाउंड स्टेटमेंट होते हैं। जब तक प्रोग्रामर नेस्टेड स्टेटमेंट के एक विशाल सेट के नीचे स्क्रॉल करता है, तब तक हो सकता है कि वे इस बात का ट्रैक खो चुके हों कि कौन से कंट्रोल स्टेटमेंट कहां जाते हैं। हालाँकि, अत्यधिक लंबे कोड के अन्य कारण हो सकते हैं, जैसे कि बहुत अधिक चक्रीय जटिलता, और इस समस्या का सामना करने वाला एक प्रोग्रामर इसके बजाय विचार कर सकता है कि क्या कोड रीफैक्टरिंग लंबी अवधि में मदद करेगा।
+कुछ स्थितियों में, ब्लॉक सीमाओं का ट्रैक खोने का जोखिम होता है। यह अक्सर कोड के बड़े वर्गों में देखा जाता है जिसमें इंडेंटेशन के कई स्तरों के लिए नेस्टेड कई यौगिक कथन होते हैं। जब तक प्रोग्रामर नेस्टेड कथन के एक विशाल सेट के नीचे स्क्रॉल करता है, तब तक हो सकता है कि वे इस बात का ट्रैक खो चुके हों कि कौन से कंट्रोल कथन कहां जाते हैं। हालाँकि, अत्यधिक लंबे कोड के अन्य कारण हो सकते हैं, जैसे कि बहुत अधिक चक्रीय जटिलता, और इस समस्या का सामना करने वाला एक प्रोग्रामर इसके बजाय विचार कर सकता है कि क्या कोड रीफैक्टरिंग लंबी अवधि में मदद करेगा।
 प्रोग्रामर जो शुरुआती ब्रेसिज़ की गिनती पर भरोसा करते हैं, उन्हें के एंड आर जैसे इंडेंटेशन शैलियों में कठिनाई हो सकती है, जहां शुरुआती ब्रेस अपने नियंत्रण प्रवाह से दृष्टि से अलग नहीं होते हैं। प्रोग्रामर जो इंडेंटेशन पर अधिक भरोसा करते हैं, उन शैलियों से अधिक लाभ प्राप्त करेंगे जो लंबवत रूप से कॉम्पैक्ट हैं, जैसे K&R, क्योंकि ब्लॉक छोटे हैं।
-जैसे नियंत्रण बयानों का ट्रैक खोने से बचने के लिए <code>[[for loop|for]]</code>, एक बड़े इंडेंटेशन का उपयोग किया जा सकता है, जैसे कि 8-यूनिट-चौड़ा हार्ड टैब, बड़े कार्यों को छोटे और अधिक पठनीय कार्यों में विभाजित करने के साथ। Linux इस तरह से किया जाता है, जबकि K&R स्टाइल का उपयोग किया जाता है।
+जैसे नियंत्रण बयानों का ट्रैक खोने से बचने के लिए <code>[[for loop|for]]</code>, एक बड़े इंडेंटेशन का उपयोग किया जा सकता है, जैसे कि 8-यूनिट-चौड़ा हार्ड टैब, बड़े कार्यों को छोटे और अधिक पठनीय कार्यों में विभाजित करने के साथ। Linux इस तरह से किया जाता है, जबकि K&R शैली का उपयोग किया जाता है।
 vi परिवार के पाठ संपादकों में, ब्लॉक सीमाओं को ट्रैक करने का एक तरीका यह है कि टेक्स्ट कर्सर को ब्रेसिज़ में से किसी एक पर रखें और दबाएं <code>%</code> चाबी। इसके बाद कर्सर विपरीत ब्रेस पर कूद जाता है। चूंकि टेक्स्ट कर्सर <code>next</code> कुंजी (अर्थात।, <code>n</code> key) ने दिशात्मक पोजीशनिंग जानकारी को बनाए रखा (चाहे <code>up</code> या <code>down</code> कुंजी को पहले दबाया गया था), मैक्रो (कंप्यूटर विज्ञान) #कीबोर्ड और माउस मैक्रोज़ ( <code>.</code> key) का उपयोग टेक्स्ट कर्सर को अगले ब्रेस पर रखने के लिए किया जा सकता है,<ref>{{cite book |first=Linda |last=Lamb |title=Learning the vi editor |url=https://archive.org/details/learningvieditor00lamb |url-access=registration |publisher=O'Reilly}}</ref> एक उपयुक्त कोडिंग शैली दी गई। इसके बजाय, <code>%</code> कुंजी का उपयोग कोडिंग मानक को लागू करने के लिए किया जा सकता है।
@@ Line 588: / Line 578: @@
 === वक्तव्य सम्मिलन ===
-मानक यूनिक्स लाइन संपादक, एड (टेक्स्ट एडिटर) का उपयोग करते समय के एंड आर शैली एक और सामान्य त्रुटि को रोकती है। कंट्रोल स्टेटमेंट और लूप ब्लॉक के ओपनिंग ब्रेस के बीच गलती से डाला गया एक स्टेटमेंट लूप की बॉडी को सिंगल ट्रिप में बदल देता है।
+मानक यूनिक्स लाइन संपादक, एड (टेक्स्ट एडिटर) का उपयोग करते समय के एंड आर शैली एक और सामान्य त्रुटि को रोकती है। कंट्रोल कथन और लूप ब्लॉक के ओपनिंग ब्रेस के बीच गलती से डाला गया एक कथन लूप की बॉडी को सिंगल ट्रिप में बदल देता है।
 <वाक्यविन्यास प्रकाश लैंग = सी>
@@ Line 598: / Line 588: @@
 </वाक्यविन्यास हाइलाइट>
-K&R स्टाइल कंट्रोल स्टेटमेंट और ओपनिंग ब्रेस को एक ही लाइन पर रखकर इस समस्या से बचा जाता है।
+K&R शैली कंट्रोल कथन और ओपनिंग ब्रेस को एक ही लाइन पर रखकर इस समस्या से बचा जाता है।
 == यह भी देखें ==

Anonymous

Search

इंडेंटेशन शैली: Difference between revisions

Revision as of 18:20, 2 March 2023

यौगिक कथनो में ब्रेस प्लेसमेंट

टैब, रिक्त स्थान और इंडेंटेशन का आकार

उपकरण

शैलियाँ

के एंड आर शैली

वैरिएंट: 1TBS (OTBS)

संस्करण: लिनक्स कर्नेल

संस्करण: अनिवार्य ब्रेसिज़

संस्करण: जावा

संस्करण: स्ट्रॉस्ट्रुप

वैरिएंट: बीएसडी केएनएफ

ऑलमैन शैली

वैरिएंट: ऑलमैन-8

गोरे लोग शैली

जीएनयू शैली

होर्स्टमैन शैली

पिको शैली

रैटलिफ शैली

लिस्प शैली

हास्केल शैली

एपीएल शैली

अन्य विचार

ब्लॉक का ट्रैक खोना

वक्तव्य सम्मिलन

यह भी देखें

संदर्भ

बाहरी संबंध

टैब और स्पेस

Navigation

Wiki tools

Page tools

Other projects

Hidden categories