C # डेवलपर्स न्यूलाइन ओपनिंग कोष्ठक क्यों बनाते हैं? [बन्द है]

Question

मैंने पिछले कई वर्षों में ज्यादातर मुख्य रूप से C # और SQL के साथ काम किया है। प्रत्येक प्रोग्रामर जो मैंने उस समय के साथ काम किया है, वह एक नई लाइन पर एक फ़ंक्शन या नियंत्रण प्रवाह विवरण के शुरुआती ब्रेस को रखने की आदत में था। इसलिए ...

public void MyFunction(string myArgument)
{
     //do stuff
}

if(myBoolean == true)
{
    //do something
}
else
{
    //do something else
}

मैं हमेशा से मारा गया हूं कि यह कितना बेकार है, खासकर अगर / अन्यथा बयानों में। और मुझे पता है कि विकल्प C के बाद के संस्करणों में मौजूद हैं, जैसे:

if(myBoolean == true)
    //do something on one line of code

लेकिन शायद ही किसी ने उनका इस्तेमाल किया हो। सभी ने कर्ली-ब्रेस-ऑन-न्यूलाइन चीज़ की।

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

function MyJavaScriptFunction() {
    //do something
}

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

अब, मैंने कोड कोड SE पर यह प्रश्न देखा: https://codereview.stackexchange.com/questions/48035/questions-responses-let-me-tell-you-about-you जिसमें मैंने सीखा कि जावा में, मैं जिस भाषा से अधिक परिचित नहीं हूं, उसे आधुनिक जावास्क्रिप्ट फैशन में, घोषणा के ठीक बाद अपने घुंघराले ब्रेसिज़ को खोलने के लिए डी-कठोरता माना जाता है।

मैं हमेशा यह समझ चुका था कि C # को मूल रूप से Java के बाद बनाया गया था, और इसे समान बेसल कोडिंग मानकों के साथ रखा गया था। लेकिन इस उदाहरण में, ऐसा नहीं लगता है। इसलिए मुझे लगता है कि एक अच्छा कारण होना चाहिए: क्या कारण है? C # डेवलपर्स (और विजुअल स्टूडियो) एक नई लाइन पर घुंघराले कोष्ठक खोलने को क्यों लागू करते हैं?

Comments

कन्वेंशन बस इतना ही है।

— ऊद

विजुअल स्टूडियो कुछ भी लागू नहीं करता है, कोड शैली विन्यास योग्य है। कुछ डिफ़ॉल्ट होने की आवश्यकता है। कौन सा डिफ़ॉल्ट "बेहतर" उच्चतम क्रम का बिकेशिंग है।

— फोजि

लाइन के अंत में ब्रेस प्राचीन K & R C मानक है। कर्निघन और रिची ने सी भाषा का आविष्कार किया जब कंप्यूटर प्रदर्शित करता है केवल 25 लाइनें (23 यदि आप हेडर और स्टेटस लाइनें जोड़ते हैं)। यह वास्तव में किसी भी अधिक मामला नहीं है, है ना? क्या महत्वपूर्ण है एक परियोजना के दौरान स्थिरता है। वहाँ रहे हैं भी वैज्ञानिक दिखा रहा है कि अपनी पंक्ति में ब्रेस (वास्तव में कोड के रूप में एक ही स्तर पर इंडेंट,) कोड को बेहतर बनाता है पढ़ाई समझ लोग क्या सोचते हैं वे सौंदर्यशास्त्र के बारे में सोच के बावजूद।

— क्रेग

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

— क्रेग

एक साइड नोट के रूप में, if(myBoolean == true)मुझे इससे कोई मतलब नहीं है। जबकि हम उस पर हैं, जबकि नहीं if ((myBoolean == true) == true)?? बस if (myBoolean)और इतना ही काफी है। क्षमा करें, मेरा एक पालतू जानवर।

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

Answer 1

ब्रायन केर्निघन और डेनिस रिची की पुस्तक द सी प्रोग्रामिंग लैंग्वेज से लाइन के अंत में ब्रेस प्राचीन K & R C मानक है, जिसे उन्होंने 1978 में UNIX ऑपरेटिंग सिस्टम और C रिकॉर्डिंग भाषा के सह-आविष्कार के बाद प्रकाशित किया था (मुझे लगता है कि C था) ज्यादातर रिची द्वारा डिजाइन किया गया), एटी एंड टी में।

"एक सच्ची कंस शैली" के बारे में लौ युद्ध हुआ करते थे।

रिची ने सी भाषा का आविष्कार किया, और कर्निघन ने पहला ट्यूटोरियल लिखा, जब कंप्यूटर केवल पाठ की कुछ पंक्तियों को दिखाता है। वास्तव में, UNICS (बाद में UNIX) का विकास DEC PDP-7 पर शुरू हुआ, जिसने एक यूजर इंटरफेस के लिए टाइपराइटर, प्रिंटर और पेपर टेप का उपयोग किया। UNIX और C 24-लाइन टेक्स्ट टर्मिनलों के साथ PDP-11 पर समाप्त हो गए थे। इतना ऊर्ध्वाधर स्थान वास्तव में एक प्रीमियम पर था। हम सभी आज थोड़ा बेहतर डिस्प्ले और उच्च रिज़ॉल्यूशन वाले प्रिंटर हैं, है ना? मेरा मतलब है, मैं आपके बारे में नहीं जानता, लेकिन मेरे सामने अभी तीन (3) 24 "1080p डिस्प्ले हैं। :-)

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

क्या वास्तव में महत्वपूर्ण है एक परियोजना के दौरान स्थिरता, या कम से कम किसी दिए गए स्रोत कोड फ़ाइल के भीतर।

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

if( true )
    {
    // do some stuff
    }

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

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

संपादित करें : बस इस सटीक मुद्दे के एक आदर्श उदाहरण के लिए Apple goto failबग देखें , जिसमें वास्तविक दुनिया के बहुत गंभीर परिणाम थे।

if( true )
    doSomething();

हो जाता है ...

if( true )
    doSomething();
    doSomethingElse();

इस मामले में, doSomethingElse()परीक्षण के परिणाम की परवाह किए बिना, हर बार निष्पादित करता है, लेकिन क्योंकि यह doSomething()कथन के समान स्तर के लिए प्रेरित है, इसलिए इसे याद करना आसान है। यह वास्तव में यकीन नहीं है; इसे वापस अध्ययन करता है। यह रखरखाव के दौरान स्रोत कोड में शुरू किए गए बग का एक बड़ा स्रोत है।

फिर भी, मैं स्वीकार करता हूं कि जावास्क्रिप्ट क्लोजर सिंटैक्स अपनी तर्ज पर ब्रेसेस के साथ थोड़ा मूर्खतापूर्ण दिखता है ... सौंदर्य से। :-)

Comments

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

— आमोन

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

— जॉन आर। स्ट्रॉहम

@ क्रेग: पुराने पास्कल / डेल्फी दिनों में, मैंने आमतौर पर सिंगल-लाइन ब्लॉक के लिए इसे टाला, क्योंकि पास्कल उपयोग करता है beginऔर endब्रेसिज़ के स्थान पर, जो इस तरह की त्रुटियों को वास्तव में याद करना मुश्किल है, और यह अर्धविराम प्लेसमेंट के लिए सख्त भी है - लेकिन खर्च करना पिछले साल 4 दिन सी में एक समस्या डिबगिंग जो अंत में किसी के ब्रेस प्लेसमेंट की कमी के कारण हो रहा था ..... मुझे लगता है कि एक संकलक विकल्प होना चाहिए जो नियंत्रण बयानों के लिए ब्रेसिज़ को अनिवार्य बनाता है!

— मार्क के कोवन

कृपया "... वैज्ञानिक अध्ययन दिखा रहे हैं कि अपनी लाइन पर ब्रेस ..." के लिए संदर्भ प्रदान करें। कम से कम दो संदर्भ (अन्यथा यह होगा बिना अध्ययन , नहीं पढ़ाई ), यह सिर्फ हवा में बेतरतीब ढंग से शूटिंग कर रहा है।

— एरिक

@ क्रेग, क्या आप कुछ सुराग प्रदान कर सकते हैं कि आपके द्वारा उल्लिखित उन शोध अध्ययनों को कैसे खोजें?

— ग्रेज़गोरेज़ एडम कोवल्स्की

Answer 2

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

दृश्य स्टूडियो में यह डिफ़ॉल्ट क्यों है, मुझे नहीं पता।

Comments

यह विज़ुअल स्टूडियो में डिफ़ॉल्ट है क्योंकि यह माइक्रोसॉफ्ट के लिए आम तौर पर स्वीकार की जाने वाली कोडिंग शैली थी, जिस तरह से वापस, और वास्तव में माइक्रोसॉफ्ट में कम से कम कुछ टीमों की शैली न केवल अपनी पंक्तियों पर ब्रेसिज़ थी, बल्कि अपनी तर्ज पर ब्रेसिज़ और इंडेंट किया। तो यह Visual Studio में एक विकल्प है, साथ ही (मैं व्यक्तिगत रूप से इसे पसंद करता हूं)।

— क्रेग

@ क्रेग: Ewwwwwwwww

— मोनिका

@PreferenceBean हम्म। व्यक्तिगत रूप से मैं K & R शैली को नापसंद करता हूं, क्योंकि कोष्ठक केवल रेखाओं के छोर पर शोर में खो जाते हैं और पाठ मुझे स्पष्ट दिखता है, जो न सिर्फ एक सौंदर्यगत प्राथमिकता है, बल्कि पठनीयता / समझ पर वास्तविक प्रभाव है। मुझे वर्टिकल व्हाट्सएप पसंद है। यह 12 दिनों में थोड़ा अलग था "पुराने दिनों में पाठ की 24 पंक्तियों के साथ मॉनिटर जब ऊर्ध्वाधर स्थान कीमती था।

— क्रेग

@ क्रेग: ब्रेस को इंडेंट करने के लिए कोई बहाना नहीं है: पी

— विथ मोनिका

@ क्रेग Microsoft कर्मचारियों को दुखी करने के लिए?

— मतीन उल्हाक

Answer 3

जैसा कि मैंने यहां इस उत्तर में परिकल्पना की है - https://softwareengineering.stackexchange.com/a/159081/29029 - मुझे लगता है कि अल्लमैन के ब्रेसिंग के साथ जाने का निर्णय पास्कल विरासत का संकेत हो सकता है, यह देखते हुए कि हेजलसबर्ग ने डेल्फी को C # डिजाइन करने से पहले बनाया था। । विधि नामों के लिए पास्कल मामले के समान।

व्यक्तिगत रूप से मेरा मानना ​​है कि "रोम में रोमन जैसा करते हैं" कहावत का पालन करते हैं। मैं जावा में Allman's का उपयोग करता हूं, लेकिन जावा में K & R। मुझे इसकी आदत है कि कन्वेंशन को किसी भी तरह से स्विच करना मुझे परेशान करता है।

मेरा मानना ​​है कि कुछ सम्मेलन विविधता वास्तव में "बहुभाषी" डेवलपर के लिए फायदेमंद है क्योंकि यह याद रखने में मदद करता है कि वे किस भाषा में इस समय कोडिंग कर रहे हैं और विभिन्न आदतों को अलग करना आसान बनाता है। यह मानसिक स्मृति के बराबर है, इसलिए बोलना है।

Comments

"बहुभाषी डेवलपर" लाइन के लिए वास्तव में +1। मैं गंभीरता से अपनी खुद की लाइनों और इंडेंट पर ब्रेसिज़ पसंद करता हूं। हालाँकि, काम पर, उदाहरण के लिए, ASP.NET (MVC) प्रोजेक्ट्स, मुझे लगता है कि मुझे "सही" शैली के साथ C # पसंद है, और जावास्क्रिप्ट "जावास्क्रिप्ट" शैली के साथ। यह थोड़ा जीभ-इन-गाल है, लेकिन ईमानदारी से इसका हिस्सा यह है कि लाइन के अंत में ब्रेस के साथ जावास्क्रिप्ट का क्लोजर सिंटैक्स अधिक आकर्षक है। इसलिए मैं सौंदर्यशास्त्र का उतना ही गुलाम हूं जितना कोई और ...

— क्रेग

विधि के नाम के लिए PascalCase माइक्रोसॉफ्ट पर एक मानक एक था लंबे से पहले एंडर्स हेल्स्बर्ग बोर्लेन्ड छोड़ दिया माइक्रोसॉफ्ट पर एक प्रतिष्ठित सॉफ्टवेयर इंजीनियर होने के लिए समय है।

— क्रेग

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

— tgm1024

कार्यक्रम के प्रवाह को नियंत्रित करने के लिए व्हाट्सएप का उपयोग करना पागलपन है। पाइथन इन दिनों लोकप्रिय है, लेकिन पाइथन का यह पहलू पहले से थोड़ा पागल हो गया है।

— क्रेग

@ क्रेग अजगर प्रशंसक यहाँ, जावास्क्रिप्ट में कुछ किया पाने की कोशिश कर रहा है। goto failकार्यक्रम के प्रवाह को नियंत्रित करने के लिए इंडेंट का उपयोग करते हुए आपके अन्य उत्तर, और आपके बारे में आपके संपादन को देखते हुए कि मनुष्य स्वाभाविक रूप से क्या करना चाहता है, इसलिए आप जो देखते हैं वही निष्पादित होता है। यदि यह गलत है तो यह सादा काम नहीं करता है। यह समझने के लिए कि उन ब्रेसिज़ का क्या मतलब है, क्या वे वास्तव में इंडेंटेशन को दर्शाते हैं, कार्यक्रम को समझने के ऊपर और ऊपर अतिरिक्त काम है। ब्रेसिज़ के लिए इंडेंटेशन बेमानी है, इसलिए यदि ब्रेसिज़ उपयोगी होते हैं तो प्रोग्रामर इसका उपयोग क्यों करते हैं? किसी भी भाषा में डीप नेस्टिंग अनजाने में होती है। जस 'कहिन'।

— नील_यूके

Answer 4

वह सम्मलेन जो आप जावा के साथ जोड़ते हैं, वह है K & R स्टाइल, या "वन ट्रू ब्रेस स्टाइल," और मूल रूप से C. से आता है। यह पृष्ठ आदरणीय शब्दजाल फ़ाइल से इंडेंट-स्टाइल दिखाता है कि अंतर कितना पुराना है।

मैंने हमेशा सोचा है कि ऑलमैन शैली और इसके वेरिएंट इस बात का प्रतिबिंब हैं कि लेखक कोड के बारे में कैसे सोचते हैं, कीवर्ड के स्तर तक ब्लॉक डेलिमिटर को कैसे बढ़ाते हैं, कुछ भाषाएं कोड के ब्लॉक के आसपास "शुरू" और "अंत" का उपयोग करती हैं।

Comments

मैं इस धारणा के तहत हूँ कि इन दिनों OTBS (एक सच्ची ब्रेस स्टाइल) का अर्थ है कि नियंत्रण कथनों के बाद ब्रेसिज़ को कभी भी बाहर नहीं छोड़ना, यहाँ तक कि कोड की एकल पंक्तियों के लिए भी। देखें Apple गोटो फेल बग।

— क्रेग