क्या घुंघराले ब्रेसिज़ अपनी लाइन पर दिखाई देने चाहिए? [बन्द है]

273

घुंघराले ब्रेसिज़ को अपनी लाइन पर होना चाहिए या नहीं? आपने इस बारे में क्या सोचा?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

या यह होना चाहिए

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

या और भी

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

कृपया रचनात्मक बनें! बताएं कि क्यों, अनुभव साझा करें, इसे तथ्यों और संदर्भों के साथ वापस करें।

coding-style  code-formatting 
— टॉम विज्समैन
स्रोत
104
मैं "== सच" को ब्रेस प्लेसमेंट की पसंद से अधिक विचलित करता हूं।
— दान डायर
11
@ दान: मुझे लगता है कि हमेशा सशर्त अभिव्यक्ति का पता लगाने से स्पष्टता में मदद मिलती है।
— जादूगर 12
4
यदि आपकी IDE / संपादक मेल खाते हुए घुंघराले ब्रैकेट पहचान का समर्थन नहीं करती है तो केवल यही कारण होगा।
— leeand00
4
@ leeand00: हममें से कुछ अभी भी इसका अध्ययन / व्याख्या करने के लिए जटिल / अपरिचित कोड का प्रिंट आउट लेते हैं । एक अच्छा सुंदर-प्रिंटर हालांकि अधिकांश समस्याओं को कम करता है।
— Shog9
2
उदास सवाल बंद है। इंडेंट आधारित सिंटैक्स उपयोग के कुछ समय बाद मैं एक और ब्रेसिज़ संरचना (शायद अजीब) में बदल गया। ब्लॉक की अंतिम पंक्ति में अपने पहले लेकिन क्लोजिंग ब्रेस की तरह। (कोड लाइन के बाद)
— cnd

जवाबों:

88

जब मैं एक छात्र था तो मैं एक ही पंक्ति में घुंघराले ब्रेसिज़ लगाता था, ताकि कम लाइनें हों, और कोड कम पृष्ठों पर मुद्रित हो जाए। किसी एकल ब्रैकेट वर्ण को एक पंक्ति में छपा हुआ देखना कष्टप्रद है। (पर्यावरण, कागज अपव्यय)

लेकिन जब बड़े अनुप्रयोगों को कोडित करते हैं, तो केवल ब्रेसिज़ के साथ कुछ पंक्तियों की अनुमति सस्ती होती है, जो 'समूहीकरण' की भावना को देखते हुए यह देता है।

आप जो भी शैली चुनते हैं, वह सुसंगत हो ताकि कोड के संबंधित टुकड़ों में कई शैलियों को संसाधित करने के लिए आपके स्वयं के मस्तिष्क के लिए एक उपरि न बने । विभिन्न परिदृश्यों में (ऊपर की तरह) मैं कहूंगा कि विभिन्न शैलियों का उपयोग करना ठीक है, उच्च स्तर पर 'संदर्भ को स्विच' करना आसान है।

— dbza
स्रोत
6
दूसरी ओर, नई लाइन पर ब्रेस एक एएनएसआई मानक है, केएंडआर नहीं है। लेकिन मानकों के बारे में सुंदरता यह है कि बहुत सारे अलग-अलग हैं (देखें अनसाइक्लोपीडिया ।wikia.com/wiki/AAAAAAAAA ! अनसाइक्लोपीडिया पर)।
— Quandary
"कम लाइनें हैं" मेरे पास टेराबाइट्स ऑफ़ स्पेस और बहुत सारे पिक्सेल हैं। मुझे अधिक लाइनों के उपयोग की परवाह क्यों करनी चाहिए?
— 12431234123412341234123
1
@ 12431234123412341234123: मुझे लगता है कि उनका मतलब है क्योंकि कुछ लोग कोड-समीक्षा के लिए कोड प्रिंट करते हैं। और प्रत्येक बिलकुल जरूरी नहीं कि नई लाइन कागज बर्बाद हो, या बड़े पैमाने पर व्यर्थ का एक किमी for है। हालाँकि, यदि आप इसे प्रिंट नहीं करते हैं (मैं निश्चित रूप से नहीं) तो ANSI K & R से बहुत बेहतर है। इसके अलावा, जो कोई भी प्रिंट करने का इरादा रखता है, उसे शायद एक स्वचालित कोड फ़ॉर्मेटर का उपयोग करना चाहिए - इसलिए यह टूलिंग का प्रश्न होना चाहिए, कोडन शैली का नहीं।
— क्वांडरी
247

आपको कभी भी 3 विधि नहीं करनी चाहिए।

ब्रेसिज़ पर कंजूसी करने से आप पहली बार कुछ कीस्ट्रोक्स बचा सकते हैं, लेकिन अगला कोडर जो साथ आता है, ब्लॉक को नोट किए बिना आपके क्लॉज को कुछ और जोड़ता है, लापता ब्रेसिज़ बहुत दर्द के लिए होने वाला है।

अन्य लोगों के लिए अपना कोड लिखें।

— rhettg
स्रोत
113
काश, मुझे पता होता कि कहाँ थोड़ी बहुत ज्ञान की उत्पत्ति हुई। लोग हैं, जो इसके बारे में के रूप में व्यर्थ है के रूप में आप यह कर सकते हैं ... पढ़ने के लिए परेशान नहीं करेगा के लिए अपने कोड लिखने क्योंकि
— Shog9
69
जब वह कुछ जोड़ता है तो दूसरा प्रोग्रामर अपने ब्रेसिज़ को जोड़ सकता है। वह मूर्ख नहीं है, और एक कोडिंग सम्मेलन में जो इस तरह से सरल सामान के लिए ब्रेसिज़ को प्रोत्साहित करता है, वह देखने के लिए जान जाएगा।
— केन ब्लूम
25
वैकल्पिक ब्रेसिज़ वैकल्पिक नहीं हैं। कुछ बदतर डिजाइन निर्णय हैं जो C में किए गए थे और इसके वंशजों को दिए गए थे। यह उस भाषा में रहता है जैसे हाल ही में C # मुझे गुस्सा दिलाता है।
— एडम क्रॉसलैंड 15
28
इससे कोई फर्क नहीं पड़ता कि आप कितने स्मार्ट हैं या सिंगल लाइन लाईट क्यूरीज़ के आसपास कोडिंग स्टैंडर्ड में कितना उलझा हुआ है: यदि आप किसी समस्या या बग को हल करना चाह रहे हैं, तो आप शायद यह याद करेंगे कि कर्ल छोड़ दिए गए थे। और कुल 2 सेकंड के काम के लिए, क्या वास्तव में स्पष्ट होना इतना बुरा है?
— जॉर्डन
11
# 3 शैली का एक फायदा है कि आप सभी गायब हैं: आपको एक बार में अपनी स्क्रीन पर अधिक कोड मिलते हैं।
— लोरेन Pechtel
203

एक लंबे समय के लिए मैंने तर्क दिया कि वे समान मूल्य के थे, या बराबर के बहुत करीब थे कि सही विकल्प बनाकर संभावित लाभ दूर, इसके बारे में बहस करने की लागत से बहुत नीचे था ।

होने के नाते लगातार महत्वपूर्ण है , हालांकि। तो मैंने कहा कि चलो एक सिक्का फ्लिप करें और लेखन कोड पर जाएं।

मैंने देखा है कि प्रोग्रामर पहले इस तरह बदलाव का विरोध करते हैं। इससे छुटकारा मिले! मैंने अपने करियर में कई बार स्विच किया है। मैं अपने PowerShell की तुलना में अपने C # में विभिन्न शैलियों का उपयोग करता हूं।

कुछ साल पहले मैं एक टीम (~ 20 डेवलपर्स) पर काम कर रहा था जिसने इनपुट के लिए पूछने का फैसला किया, और फिर एक निर्णय लिया, और फिर सभी कोड आधार पर लागू किया। हमारे पास निर्णय लेने के लिए 1 सप्ताह होगा।

बहुत सारे कराहना और आँख मलना। बहुत सारे "मुझे अपना रास्ता पसंद है, क्योंकि यह बेहतर है" लेकिन कोई पदार्थ नहीं।

जैसा कि हम प्रश्न के बारीक बिंदुओं का अध्ययन कर रहे थे, किसी ने पूछा कि इस मुद्दे को ब्रेस-ऑन-ही-लाइन शैली में कैसे निपटा जाए:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

ध्यान दें कि यह तुरंत स्पष्ट नहीं है कि पैरामीटर सूची कहां समाप्त होती है, और शरीर शुरू होता है। से तुलना:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

हमने इस बारे में कुछ पढ़ा कि दुनिया भर के लोगों ने इस समस्या से कैसे निपटा, और खुली ब्रेस के बाद एक रिक्त लाइन को जोड़ने का पैटर्न पाया:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

यदि आप एक दृश्य विराम बनाने जा रहे हैं, तो आप इसे ब्रेस के साथ भी कर सकते हैं। तब आपके दृश्य विराम भी सुसंगत हो जाते हैं।

संपादित करें : K & R का उपयोग करते समय 'अतिरिक्त रिक्त लाइन' समाधान के लिए दो विकल्प:

1 / फ़ंक्शन का तर्क फ़ंक्शन बॉडी से अलग तरीके से इंगित करता है

2 / फ़ंक्शन नाम के रूप में एक ही लाइन पर पहला तर्क रखो और उस पहले तर्क के लिए नई लाइनों पर आगे तर्क संरेखित करें

उदाहरण:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/ संपादित करें

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

— Jay Bazuzi
स्रोत
33
FYI करें, मैं एक उचित व्यक्ति की तरह लग सकता है, लेकिन मैं वास्तव में एक नट हूं। सरल, सिंगल-लाइन ब्लॉक के लिए, मैं न तो ब्रेसिज़ और न ही नईलाइन्स का उपयोग करूँगा, जिससे 'इफ (फू) बार ()' सभी एक लाइन बन जाएगी। मैं अपने कोड को सरल बनाने का प्रयास करता हूं कि यह कोई समस्या न हो।
— जे बाजुज़ी
38
ठीक यही पोस्ट करने के लिए यहां आया हूं। एक ही लाइन पर शुरुआती ब्रेस रखने वाले लोगों के टन इसे एक रिक्त रेखा (विशेष रूप से कक्षाओं और विधियों की शुरुआत में) के साथ पालन करते हैं क्योंकि अन्यथा, शरीर से वर्ग / विधि शीर्षलेख को अलग करना मुश्किल है। ठीक है, अगर आप किसी भी तरह से एक अतिरिक्त लाइन का उपयोग करने जा रहे हैं, तो आप ब्रेस को वहां रख सकते हैं और इंडेंटेशन के अतिरिक्त लाभ को आसानी से देख सकते हैं।
— येवगेनी ब्रिकमैन
27
मैंने रिक्त पंक्ति नहीं देखी है - जब वे किसी अन्य पंक्ति पर भटकते हैं तो मैं MyFunction () के मापदंडों के दोहरे-संकेत से परिचित हूं।
— आर्मंड
34
इस तरह से कई लाइनों के मापदंडों को तोड़ना पागलपन है।
— फोसको
10
"फ़ंक्शन पैरामीटर" तर्क एक लाल हेरिंग है। जाहिर है कि दलीलें दोगुनी होनी चाहिए। कोई समस्या नहीं है जो भी निम्नलिखित कोड से इसे अलग करने के लिए।
— डेविड ओंगारो
99

कार्डिनल नियम हैं:

  1. प्रोजेक्ट के मौजूदा कोडिंग मानक का पालन करें।
  2. यदि कोई कोडिंग मानक नहीं है और आप किसी और के स्वामित्व वाले मौजूदा कोड-बेस का संपादन कर रहे हैं - तो मौजूदा कोड की शैली के अनुरूप हो, चाहे आप इसे कितना भी पसंद / नापसंद करते हों।
  3. यदि आप एक ग्रीन-फील्ड प्रोजेक्ट पर काम कर रहे हैं - टीम के अन्य सदस्यों के साथ चर्चा करें, और एक औपचारिक या अनौपचारिक कोडिंग मानक पर आम सहमति के लिए आएँ।
  4. यदि आप एकमात्र डेवलपर के रूप में एक ग्रीन-फील्ड प्रोजेक्ट पर काम कर रहे हैं - अपना खुद का दिमाग बनाएं, और फिर बेरहमी से सुसंगत रहें।

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

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

— स्टीफन सी
स्रोत
10
यह उत्तर अधिक मतों का हकदार है।
— 23
1
स्थिरता की कुंजी है
— मीडियाविंस
70

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

मुझे कोई पूरी वजह नहीं दिखती है कि पूरी लाइन बर्बाद करने के लिए सिर्फ एक ब्रैकेट के लिए जब / पहले / जब निर्माण हो तो नेत्रहीन एक ब्लॉक की शुरुआत का संकेत देता है।

उस ने कहा, मेरा मानना ​​है कि क्लोजिंग ब्रैकेट अपनी लाइन में होना चाहिए क्योंकि हमें एक ब्लॉक के अंत और इसकी इंडेंटेशन संरचना को एक दृश्य तरीके से इंगित करने के लिए कुछ चाहिए।

— ईप्सिलॉनवेक्टर को दर्शाता है
स्रोत
12
नहीं ... मैं कह रहा हूं कि कोड की मात्रा को कम करें जो आपके स्क्रीन पर कुछ ऐसा कर सकता है जो कोड की स्पष्टता को नहीं जोड़ता है?
— एप्सिलॉनवेक्टर
6
जब मैं कोडिंग शुरू कर रहा था तो मुझे अपनी लाइन पर प्रत्येक ब्रेस पसंद आया, अब मैं पहली विधि पसंद करता हूं
— निमशिम्पस्की
57
शोध का एक विशाल निकाय है, जो सभी शुरुआती स्टीम एज (वेनबर्ग, "कंप्यूटर प्रोग्रामिंग का मनोविज्ञान") पर वापस जा रहा है, जो दर्शाता है कि प्रोग्रामर की समझ DRAMATICALLY से गिरती है जब कोड की मात्रा को देखा जाना चाहिए से अधिक है एक समय में देखा जा सकता है (यानी, एक स्क्रीनफुल, एक प्रिंटर पेज)। यह घटना एक मूल्यवान संसाधन के रूप में ऊर्ध्वाधर स्थान को देखने के लिए मजबूत रूप से तर्क देती है, न कि इसे गंभीर रूप से बर्बाद करने के लिए, और इस तरह पहली विधि को प्राथमिकता दी जाती है।
— जॉन आर। स्ट्रॉह्म
10
LOL @ "ENTIRE लाइन बर्बाद कर रहा है"। हे भगवान! नहीं कि!! = पी
— निक स्प्रीट्जर
6
@ जूलियो कॉलेज में मैंने पद्धति 1 का जोरदार तरीके से पालन किया, और पढ़ने की विधि 2 पर टिक नहीं सका। एक ऐसी कंपनी में काम करने के बाद, जो C # का उपयोग करती है, जहां मानक 2 विधि है, मैं इसे बस इतना ही पसंद आया हूं। मैं अब पढ़ सकता हूं या उपयोग कर सकता हूं; मुझे कोई परेशान नहीं करता। जिन लोगों को एक या दूसरे से दृढ़ता से प्रतिकूल प्रतिक्रिया होती है, वे आमतौर पर किसी ऐसी चीज से बहुत अधिक प्रभावित होते हैं जिससे वे अपरिचित होते हैं।
— KChaloux
46

मैं पसंद करता हूं 

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

ऊपर

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

क्योंकि you.postAnswer();पहली नज़र में लाइन पढ़ना और खोजना बहुत आसान है। दूसरे तरीके से, यह इसके ऊपर की रेखा के साथ मिश्रित हो जाता है ( you.hasAnswer()) मेरी आँखों को इसे पढ़ने के लिए अधिक ध्यान केंद्रित करना पड़ता है।

— जद इसाक्स
स्रोत
7
यह तब तक सच है जब तक आपका कार्यक्रम आपकी स्क्रीन की ऊंचाई से अधिक नहीं हो जाता। ;)
— वेबर
13
@ weberc2 मुझे लगता है कि जब आपका प्रोग्राम स्क्रीन की ऊँचाई से अधिक हो जाता है, तो दो लाइनें कम होने से बहुत बदलाव नहीं होगा।
— मागेक
13
10 साल पहले, मैं स्क्रीन स्पेस के बारे में सहमत होता। आज, मैं एक 1920 * 1200 स्क्रीन का उपयोग करता हूं। यह एक बहुत सारे कोड को फिट करता है, मेरे दिमाग से अधिक एक बार में प्रक्रिया कर सकता है। पहली विधि मुझे वापस खींचने की अनुमति देती है और इसे पढ़ने के बिना अलग-अलग गुंजाइश को खोलने / बंद करने की अनुमति देती है।
— लाइटस्ट्रीकर
3
मैं कभी भी थाह नहीं लगा सकता कि मैंने इस पद्धति को क्यों पसंद किया लेकिन यह बिल्कुल इसी के लिए है।
— दक्खन मैककेन
2
@ माजेक यह बेल्ड है, लेकिन यह 2 लाइन नहीं है, यह हर स्कोप के लिए 2 लाइन है। वह ओ (एन) है, ओ (1) नहीं। मैं वास्तव में इसके बारे में दृढ़ता से महसूस नहीं करता; यह अधिक महत्वपूर्ण है कि आप एक ऐसी शैली चुनें जो लंबे पैरामीटर सूचियों को पठनीय बनाती है।
— वेबर 2
38

मैं पहली विधि पसंद करता हूं। ब्रेसिज़ पूरी तरह से अलग लाइन के लायक नहीं हैं।

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

भाषाएँ (पायथन, हास्केल, रूबी) हैं जो बिना ब्रेसिज़ के बिल्कुल ठीक हैं। यह केवल पुष्टि करता है कि ब्रेसिज़ कचरा हैं, और जब भी संभव हो उनके लिए एक पंक्ति के लायक नहीं होना चाहिए:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}
— P मुंडा
स्रोत
7
मैं हास्केल या रूबी के बारे में नहीं जानता, लेकिन पायथन व्हॉट्सएप संवेदनशील है, यही वजह है कि इसे ब्लॉक को निरूपित करने के लिए ब्रेसिज़ या अन्य सीमांकक की आवश्यकता नहीं है। ब्रेसिज़ सिंटैक्टिकल शोर नहीं हैं; वे एक वास्तविक उद्देश्य की सेवा करते हैं।
— रॉबर्ट हार्वे
14
@ रोबर्ट, सी में आपको व्हॉट्सएप और ब्रेसेस दोनों करने होंगे । अजगर में आपको केवल व्हाट्सएप करना चाहिए। कौनसा अच्छा है?
— पी शेव्ड
5
@Pavel, C में आपको व्हाइटपेस नहीं करना है।
— केन ब्लूम
7
व्हॉट्सएप के बिना @KenBloom C प्रोग्राम पढ़ना असंभव है। तो आपको उन्हें वैसे भी करना होगा।
— पी शेव्ड
6
भले ही ब्रेसिज़ एक अच्छा विचार हो या न हो, लेकिन भाषाओं का एकमात्र अस्तित्व जो उनका उपयोग नहीं करता है, उनके खिलाफ एक तर्क की तरह प्रतीत नहीं होता है। यह केवल यह बताता है कि उनके बिना भाषा का होना संभव है, न कि यह एक अच्छी या खराब भाषा की डिजाइन।
— जेसन
37

अजगर का प्रयोग करें और तर्क को पूरी तरह से दरकिनार कर दें।

— मार्क रैनसम
स्रोत
17
+1SyntaxError: not a chance
— सेठ
6
यह परियोजनाओं के विशाल, विशाल बहुमत के लिए बस एक विकल्प नहीं है। इसके अलावा, इंडेंटेशन-फॉर-ग्रुपिंग में यह समस्याओं का हिस्सा है।
— ब्रायन ओकली
@ ब्रायन, मुझे पता है कि यह बहुत व्यावहारिक नहीं है। मुझे लगा कि यह केवल एक टिप्पणी से कहीं ज्यादा मजबूत होने की जरूरत है। और मैं कभी भी इंडेंटेशन के कारण होने वाली समस्याओं में नहीं भागता, जो आप का मतलब है, शायद इसलिए कि मैं टैब और स्पेस को मिक्स नहीं करता।
— मार्क रैनसम
Go का उपयोग करें और तर्क को पूरी तरह से दरकिनार करें (प्लस स्टैटिक टाइपिंग, स्पीड और एक संकलक!) :)
— weberc2
4
फिर स्पेस बार को एक बार दबाएं और संकलक / दुभाषिया को आप पर हंसते हुए देखें। अधिकांश लट भाषाओं में ऐसा नहीं होगा।
— फराप
27

घुंघराले ब्रेसिज़ की स्थिति होनी चाहिए

मेटा डेटा

प्रोग्रामर द्वारा IDE में कॉन्फ़िगर करने योग्य। इस तरह, लेखक की परवाह किए बिना सभी कोड में उन pesky ब्रेसिज़, समान दिखते हैं।

— जोनाथन
स्रोत
7
पूर्णतया सहमत। यह प्रस्तुति है और डेटा नहीं है।
— पेत्रुजा
मुद्दा यह है कि यदि आप सभी को अपना स्वयं का सेट करने देते हैं, तो चीजें बहुत जल्दी खराब हो जाती हैं क्योंकि कमिट किया जाता है।
— एंडी
1
@ और: यह बिलकुल सही बात है, आईडीई कैसे बदलेगी, यह केवल आईडीई में ही बदल जाएगा! वास्तविक स्रोत को छुआ नहीं जाएगा। संस्करण नियंत्रण के लिए, आप हुक जोड़ सकते हैं जो घुंघराले ब्रेसिज़ के लिए जो भी सेटिंग है वह एक सामान्य स्थिति में थी, ताकि हर कोई उसी तरह से कोड की जांच करे।
— क्लेर
@klaar मेरे द्वारा उपयोग की जाने वाली प्रत्येक आधुनिक आईडीई टैब को रिक्त स्थान में बदल देगी और ब्रेसिज़ को अपनी लाइन या "ओपनिंग" लाइन के अंत में ले जाएगी; मुझे यकीन नहीं है कि आपको लगता है कि इन मामलों में स्रोत को छुआ नहीं गया है, और यही मेरी टिप्पणी का कारण है। यह आमतौर पर डेवलपर्स सेटिंग्स के आधार पर आईडीई द्वारा बदल दिया जाता है, जिसका मतलब है कि एक कमिट के दौरान मुझे बहुत सारे बदलाव देखने को मिलेंगे, जो कि शोर हैं क्योंकि ब्रेसिज़ अपनी लाइन में चले गए, इस प्रकार किसी ने किया बदलाव को छिपाया।
— एंडी
@ और: क्या आपके द्वारा बताई गई शोर की समस्या को रोकने के लिए, व्हाट्सएप और ब्रेसेस के बारे में उन विसंगतियों को व्हाट्सएप और ब्रेसिज़ में परिवर्तित करने की संभावना नहीं है? किसी भी तरह से, एक उचित संस्करण प्रणाली को व्हाट्सएप या अन्य निरर्थक चीजों की तरह क्षुद्र चीजों को पार करना चाहिए ।
— क्लेर
19

निर्भर करता है।

यदि मैं जावास्क्रिप्ट या jQuery में कोडिंग कर रहा हूं, तो मैं पहले फॉर्म का उपयोग करता हूं:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
});

लेकिन अगर मैं C # में कोडिंग कर रहा हूं, तो मैं दूसरे फॉर्म का उपयोग करता हूं, क्योंकि यह C # करने के लिए विहित तरीका है।

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
}

ध्यान दें कि आपका उदाहरण लिखा जा सकता है

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

C # में।

— रॉबर्ट हार्वे
स्रोत
1
इसे बहुत सी भाषाओं में लिखा जा सकता है, क्योंकि ब्लॉक-स्टेटमेंट एक स्टेटमेंट है। जोड़ा जा रहा है! :-)
— तमारा विजसमैन
2
"फ्रेमवर्क डिज़ाइन गाइडलाइन्स" के अनुसार "कैनोनिकल तरीका" एक ही लाइन (यानी पहला फ़ॉर्म) पर शुरुआती ब्रेस को रखना है। बस 'कह रहे हैं ...
— Uwe Honekamp
3
@ यूवे: शायद। लेकिन Microsoft ने अपने सभी MSDN C # उदाहरणों के लिए "गठबंधन किए गए ब्रेसिज़" दृष्टिकोण को अपनाया, और यह विजुअल स्टूडियो में बेक किया गया है, इसलिए ...
— रॉबर्ट हार्वे
@ यूवे: यह सीविना की किताब है और इसे बहुत नाम दिया गया है क्योंकि यह उससे कहीं अधिक है। MSDN पर FDG का इस बारे में कुछ नहीं कहना है। मुझे यह भी आश्चर्य है कि, फ्रेमवर्क डिज़ाइन दिशानिर्देश C # कोडिंग अभ्यास के बारे में कुछ क्यों कहेगा ?
— आर। मार्टिनो फर्नांडिस
3
आपको वास्तव में, जावास्क्रिप्ट में एक ही लाइन पर घुंघराले ब्रेसिज़ रखना चाहिए। यदि कर्ली ब्रेसिज़ अपनी लाइन पर हैं, तो आप त्रुटियां पैदा कर सकते हैं। उदाहरण के लिए, एनकोसिया.com/
— जोसेफ हेन्सन
18

मैं पहली पसंद करता हूं क्योंकि मेरे लिए इस उदाहरण में गलती देखना कठिन है।

if (value > maximum);
{
    dosomething();
}

इस उदाहरण में है

if (value > maximum); {
    dosomething();
}

; {सिर्फ एक लाइन के साथ समाप्त होने से मेरे लिए और अधिक गलत लग रहा है ;तो मैं अधिक यह देखे जाने की संभावना है।

— बीएमबी
स्रोत
11
आप एक अच्छा तर्क देते हैं, लेकिन व्यक्तिगत रूप से, यह केवल मेरे 5 साल की प्रोग्रामिंग में एक बार हुआ है। मैं यह पता नहीं लगा सका कि यह क्यों नहीं चल रहा है, इसे एसओ पर पोस्ट किया और किसी ने जल्दी से मुझे सेमी-कॉलन बताया। हालांकि, हर बार उस 1 कम लाइन का उपयोग करने के लिए गाढ़ा किया जाता है, मुझे पढ़ना मुश्किल लगता है।
— जद इसाक्स
6
"; {" एक तरह का झुलसा हुआ गदराया हुआ चेहरा या शायद मूंछों वाला व्यक्ति दिखता है।
— ग्लेनट्रॉन
+1 जवाब में महान उदाहरण: बहुत सूक्ष्म गलती, आसानी से अनदेखी। यह दिखाते हुए लेआउट पर भी उत्तेजक।
— थेरोबोक्नो
10
निश्चित रूप से कोई भी सभ्य आईडीई खाली नियंत्रण कथन को चिह्नित करेगा और कोई भी सभ्य संकलक चेतावनी जारी करेगा।
— डंक
@ डंक आपके तर्क में एकमात्र दोष (जिसे मैं दृढ़ता से सहमत हूं) यह है कि इतने सारे लोग इन दिनों व्याख्या की गई भाषाओं (जावास्क्रिप्ट, पीएचपी, एट अल) का उपयोग कर रहे हैं कि बहुत सारे "प्रोग्रामर" एक डबल से एक कंपाइलर नहीं जान पाएंगे। लाटे।
— क्रेग
15

मुझे 1 का मामूली रूप पसंद है)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

क्यों?

  • मुझे लगता है कि हमेशा अपनी लाइन पर ब्रेस लगाने से पठनीयता घट जाती है। मैं अपनी स्क्रीन पर केवल एक निश्चित स्रोत कोड फिट कर सकता हूं। ब्रैकेट शैली 2) बहुत सारे नेस्टेड छोरों और सशर्त लंबे दर्द के साथ हीर्व एल्गोरिदम बनाती है।

  • हालाँकि, मैं elseएक नई लाइन शुरू करना चाहता हूँ क्योंकि ifऔर elseएक साथ, नेत्रहीन हैं। यदि सामने एक ब्रैकेट है else, तो यह पता लगाना बहुत मुश्किल है कि क्या संबंधित है।

  • 3) खुद को अयोग्य घोषित करता है। हम सभी जानते हैं कि अगर आप कोष्ठक छोड़ते हैं और इसके बारे में भूल जाते हैं तो क्या बुरा हो सकता है।

— अलेक्जेंडर गेसलर को पुनर्जीवित करता है
स्रोत
1
मैंने यह देखा है कि मैं कहाँ काम करता हूँ। यह दिलचस्प है।
— आलमो जुएल
1
मुझे यह शैली भी बेहतर लगती है, क्योंकि यह मुझे elseजरूरत पड़ने पर लाइन के ऊपर टिप्पणी करने की अनुमति देता है , और / और अगर ब्लॉक को कम करने के लिए चीजों को देखने के लिए ब्लॉक और ब्लॉक के बीच एक खाली लाइन डाल देता है। ब्रैकेट शैली # 2 शर्तों से कार्यों को दूर करने के अलावा और कुछ नहीं करती है। उस के साथ कहा, मेरे पसंदीदा निश्चित रूप से अजगर की कोई ब्रैकेट शैली है :)
— Sayap
4
यदि स्क्रीन पर कोड लाइनों की संख्या को अधिकतम करना महत्वपूर्ण है, तो बस नए सिरे से पूरी तरह से दूर करें। आप एक स्क्रीन पर बहुत सारी लाइनें प्राप्त कर पाएंगे। मैं कुछ भी नहीं करने के लिए पसंद करते हैं, जो मुझे रोकते हैं और पढ़ते समय सोचते हैं, अर्थात। अधिक पठनीय की मेरी परिभाषा। ब्रेसिज़ के साथ मेरा मन उन्हें अनदेखा करता है। ब्रेसिज़ के बिना मेरे दिमाग को नियंत्रण ब्लॉकों को रोकना और संरेखित करना है। एक लंबा विराम नहीं, लेकिन एक विराम कम-से-कम।
— डंक
1
हाँ, यदि और कोई एक साथ हैं, लेकिन ऐसा करना {और} और जैसा कि} एक अलग लाइन पर है, {एक अलग लाइन पर होना चाहिए, भी। "मैं केवल अपनी स्क्रीन पर स्रोत कोड की एक निश्चित राशि फिट कर सकता हूं" और यही कारण है कि 3) "खुद को अयोग्य घोषित कर रहा है" बिल्कुल भी कोई विकल्प नहीं है। 3 के साथ काम करने के एक दशक के बाद) मैं कोड की एक नई लाइन जोड़ते समय कोष्ठक जोड़ना नहीं भूलता, कभी भी, और न ही मैं कभी किसी को जानता हूं। अगर मुझे उन लोगों के लिए कोड समायोजित करना है, जो ठीक से नहीं पढ़ सकते हैं, तो यह कहां समाप्त होता है? कुछ विशेष भाषाओं के उपयोग को रोकना, क्योंकि कुछ कोड पाठक उन्हें समझ नहीं सकते हैं?
— कैसरलुडी
10

मैंने कहीं पढ़ा कि किसी किताब के लेखक चाहते थे कि उनका कोड इस तरह तैयार हो:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

लेकिन उनके प्रकाशक से अंतरिक्ष की कमी का मतलब था कि उन्हें इसका उपयोग करना था:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

अब मुझे नहीं पता कि यह सच है (जैसा कि मैं इसे और नहीं जान सकता), लेकिन बाद की शैली किताबों में बहुत प्रचलित है।

व्यक्तिगत स्तर पर मैं एक अलग लाइन पर कोष्ठक को पसंद करता हूं:

a) वे एक नया दायरा इंगित करते हैं
b) जब आपको मिसमैच मिला है, तो यह बताना आसान है (हालांकि यह IDE में एक समस्या से कम है जो आपके लिए त्रुटियों को उजागर करता है)।

— ChrisF
स्रोत
... दूसरा विकल्प आपके दोनों बिंदुओं की सुविधा भी देता है (केवल इंडेंटेशन के साथ ब्रेस / इंडेंटेशन कॉम्बो के उद्देश्य की सेवा)। :)
— weberc2
10

आह, वन ट्रू ब्रेस स्टाइल ।

यह एक पवित्र मार्ग के लिए सब कुछ neded है - यहां तक ​​कि एक नबी (रिचर्ड "मेरा रास्ता या राजमार्ग" स्टैलमैन)।

आदमी इतनी सारी चीजों के बारे में गलत था, लेकिन ब्रेसिज़ की बात आते ही जीएनयू हाजिर है।

[अद्यतन] मैंने प्रकाश देखा है, और अब अल्लमन की पूजा करते हैं

— रेव्ह Mawg
स्रोत
9
मुझे ग्नू शैली की बात नहीं दिखती, इसके अलावा यह लिस्प कोड है। थोड़ा लाभ के लिए बहुत काम की तरह लगता है।
— रॉबर्ट हार्वे
मुझे कोई नहीं जानता कि कौन GNU शैली का उपयोग करता है। पूरे रास्ते में 1 टी.बी.एस.
— जे क्यू कतार
आप प्रति ब्लॉक दो इंडेंटेशन स्तरों की तुलना में कोई भी बदतर नहीं कर सकते हैं, लिस्प शैली को छोड़कर, निश्चित रूप से, जो बिना कहे चला जाता है।
— ergosys
4
ब्रेस शैलियों पर लिंक के लिए +1। यह दर्शाता है कि आपकी शैली जो भी हो, कई महान लोग आपसे असहमत हैं।
— फ्लोरियन एफ
@RobertHarvey कोई अतिरिक्त काम नहीं है, अगर यह है, तो आप कोड लिखने के लिए सही उपकरण का उपयोग नहीं करते हैं या इसे सही तरीके से कॉन्फ़िगर नहीं करते हैं। लाभ बहुत अधिक पठनीय कोड है, आप ब्रैकेट में प्रत्येक त्रुटि को बहुत तेजी से देखते हैं और आप आसानी से कोड को अनदेखा करते हुए केवल कोड पढ़ सकते हैं।
— 12431234123412341234123
9

दूसरा उदाहरण, मैं पठनीयता पर बहुत बड़ा हूं। मैं देख नहीं सकता अगर किसी भी अन्य तरह से ब्लॉक = (

— ब्रायन हैरिंगटन
स्रोत
1
अनुसंधान इंगित करता है कि एक कोड आधार स्क्रीन की ऊंचाई से अधिक हो जाने पर कॉम्पैक्ट कोड पढ़ना आसान है।
— weberc2
5
@ weberc2, क्या आप उन शोध पत्र को DOI प्रदान कर सकते हैं?
— ग्रेज़गोरेज़ एडम कोवल्स्की
9

सरल उत्तर: डिबग करना क्या आसान है?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

किस मामले में आपने पहले समस्या का निदान किया?

मैं व्यक्तिगत प्राथमिकताओं के लिए बहुत परवाह नहीं करता हूं (व्हॉट्समिथ और अल सहित कई अन्य शैलियों हैं।) और मुझे बहुत परवाह नहीं है ... जब तक यह कोड को पढ़ने की मेरी क्षमता को बाधित नहीं करता है और इसे डीबग करता है।

"बेकार स्थान" तर्क के रूप में, मैं इसे नहीं खरीदता: मैं प्रोग्राम को स्पष्ट करने के लिए वैसे भी तार्किक समूहों के बीच रिक्त लाइनों को जोड़ देता हूं ...

— मैथ्यू एम।
स्रोत
1
वे दोनों डिबग करना जितना आसान है, मुख्यतः चूंकि यह कोड का एक छोटा ब्लॉक है। इंडेंटेशन वास्तविक कोड ब्लॉक की कल्पना करना आसान बना रहा है।
— Htbaa
@ हतबा: वास्तव में :) तो परेशान क्यों हो?
— मथिउ एम।
@MatthieuM। पहला ब्लॉक मेरे लिए ज्यादा मायने रखता है, क्योंकि फंक्शन सिग्नेचर, फॉर-स्टेटमेंट और इफ-स्टेटमेंट के बीच जो नईलाइन्स (दूसरे ब्लॉक में) हैं, उनका मानना ​​है कि वे असंबंधित हैं, लेकिन स्पष्ट रूप से वे नहीं हैं। रिक्त लाइनें कोड के असंबंधित बिट्स को अलग करने के लिए हैं; कोड जो कोड की अन्य लाइनों के करीब है, इसका मतलब है कि वे वास्तव में संबंधित हैं। यह सब बेशक 'इमो' है, लेकिन मुझे आश्चर्य है कि आपकी बात क्या थी। संपादित करें: कोई भी उचित आईडीई किसी भी ब्रेस के गुम होने की सूचना देगा और आपको अपने कोड की व्याख्या करने में त्रुटियों का एक टुकड़ा देगा।
— क्लेर
7

ऐसा नहीं है कि किसी को भी नोटिस होगा, लेकिन यही कारण है कि ब्रेसिज़ एक ही लाइन के होते हैं जैसे कि सशर्त (बहुत लंबी स्थिति को छोड़कर, लेकिन यह एक किनारे का मामला है):

सी में, यह एक वैध निर्माण है:

जबकि (सही);
{
    चार सी;
    getchar (); // इनपुट की प्रतीक्षा करें
}

शीघ्र! यह कोड क्या करता है? यदि आपने उत्तर दिया "अनंत लूप इनपुट के लिए पूछ रहा है", तो आप गलत हैं! यह इनपुट के लिए भी नहीं मिलता है। यह पकड़ा जाता है while(true)। उस अर्धविराम को ध्यान से देखें। यह पैटर्न वास्तव में अधिक सामान्य है कि ऐसा लगता है जैसे यह होना चाहिए; सी के लिए आपको एक ब्लॉक की शुरुआत में अपने चर घोषित करने की आवश्यकता होती है, यही वजह है कि एक नया शुरू किया गया था।

कोड की एक पंक्ति एक विचार है। ब्रेस सशर्त या लूप युक्त विचार का एक हिस्सा है। इसलिए, वे एक ही पंक्ति के हैं।

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

मुझे पहली विधि पसंद है। यह नाटो आईएमओ लगता है, और यह अधिक कॉम्पैक्ट है, जो मुझे पसंद है।

संपादित करें: आह, एक तीसरा। मुझे यह पसंद है कि जब भी संभव हो, तो यह सबसे छोटा / नट हो।

— उल्लालुल्लो को दर्शाता है
स्रोत
5

आप इसे लिख सकते हैं:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

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

— अनवरत वृद्धि # अनियंत्रित विस्तार
स्रोत
उस तरह इस्तेमाल किया जाना चाहिए , postAnswer()और doSomething()टर्नरी ऑपरेटर के लिए मूल्य वापस करना चाहिए, जो अक्सर ऐसा नहीं होता है: वे बहुत अच्छी तरह से शून्य (कोई मूल्य नहीं) लौटा सकते हैं। और यह भी (कम से कम c # में) का परिणाम ?:कुछ चर को सौंपा जाना चाहिए
— एएसएच
4

यहां लगभग सभी प्रतिक्रियाएं "आप जो भी करते हैं, उस पर कुछ भिन्नताएं कह रहे हैं, या तो एक या दो के साथ रहें"।

इसलिए मैंने एक पल के लिए इसके बारे में सोचा, और मानना ​​पड़ा कि मैं इसे उतना महत्वपूर्ण नहीं देखता। क्या कोई मुझे ईमानदारी से बता सकता है कि निम्नलिखित का पालन करना कठिन है?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

मुझे किसी और के बारे में निश्चित नहीं है ... लेकिन मुझे मानसिक रूप से शैलियों के बीच आगे-पीछे स्विच करने में बिल्कुल शून्य समस्याएं हैं। मुझे यह पता लगाने में कुछ समय लगा कि कोड ने क्या किया है, लेकिन यह मेरे लिए सिर्फ सी-सिंटेक्स जैसे यादृच्छिक रूप से टाइप करने का परिणाम है। :)

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

एफडब्ल्यूआईडब्ल्यू, काम पर हमारी कोडिंग शैली थोड़ा अधिक संरचित रूप 1 और संशोधित रूप 3 का उपयोग करती है। (C ++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

मुझे उत्सुकता है अगर जो लोग फॉर्म 2 को दृढ़ता से पसंद करते हैं, उन्हें फॉर्म 1 का यह संस्करण बेहतर लगेगा, सिर्फ इसलिए कि खाली लाइन एक मजबूत दृश्य पृथक्करण देती है।

— jkerian
स्रोत
4
जैसा कि आपका उदाहरण दिखाता है, इंडेंटेशन पठनीय कोड के लिए ब्रेसिज़ की तुलना में बहुत महत्वपूर्ण है। वास्तव में, कुछ भाषाएं बयानों को घोंसले बनाने का एकमात्र तरीका बनाती हैं!
1
ठीक है, मैं ईमानदारी से आपको असंगत उदाहरण पढ़ने के लिए कठिन लगता हूं। वास्तव में कठिन नहीं है, लेकिन अगर यह सुसंगत था तो उससे भी कठिन।
— आलमो जुएल
मैं अल्मो से सहमत हूं। यह "क्या यह वास्तव में कठिन है" का मामला नहीं है। यह "यह निश्चित रूप से कठिन है" का मामला है, भले ही कठिन न हो। तो क्यों चीजों को कठिन बनाते हैं? "टॉय" उदाहरण में लोग निश्चित रूप से बहुत कम अंतर देते हैं। मेरे अनुभव में, जब मुझे किसी और से गंदा कोड विरासत में मिला था और उन्होंने विधि 1 का उपयोग किया था, तो अक्सर आगे बढ़ने के लिए और तर्क 2 का अनुसरण करने में सक्षम होने के लिए इसे विधि 2 में बदलना आवश्यक हो जाता है। इस तथ्य के कारण कि यह अक्सर आवश्यक हो जाता है; यह स्वचालित रूप से इस सवाल का जवाब देता है कि कौन सी विधि बेहतर है और समझने में आसान है।
— डंक
@ डंक: मैं इस तरह के अप्रासंगिक विवरणों की अदला-बदली करके कोड को बेहतर नहीं बना सकता।
— जकरियन
@ जकरियन-जाहिर तौर पर आपको दूसरों से ज्यादा कोड विरासत में नहीं मिला है, जिनके पास या तो प्रोजेक्ट या कंपनी है। मैं कुछ वर्षों के अनुभव के साथ किसी के द्वारा उस स्थिति में नहीं थाह सकता। लेकिन फिर, हर किसी के काम की स्थिति अलग है। इसके अलावा, यदि आपको "औपचारिक" कोड समीक्षा करनी है, तो प्रारूपण में काफी अंतर होता है। स्वाभाविक रूप से कोड को पढ़ने में सक्षम होना बहुत महत्वपूर्ण है। यकीन है कि मैं रुक सकता हूं और ब्रेसिज़ का मिलान करने के लिए सोच सकता हूं, लेकिन यह प्रक्रिया को धीमा कर देता है। एक तरह से ठहराव की आवश्यकता नहीं है, दूसरे करते हैं। इसलिए मैं नहीं देखता कि किसी अन्य विकल्प की सिफारिश क्यों की जा सकती है।
— डंक
4

मुझे आश्चर्य है कि यह अभी तक नहीं उठाया गया है। मैं दूसरा दृष्टिकोण पसंद करता हूं क्योंकि यह आपको ब्लॉक को अधिक आसानी से चुनने की अनुमति देता है।

जब ब्रेसिज़ एक ही कॉलम पर और अपनी लाइन पर शुरू और समाप्त होते हैं, तो आप मार्जिन से या कॉलम पर कर्सर के साथ चुन सकते हैं। 0. यह आमतौर पर माउस चयन या कीबोर्ड चयन के साथ कम कीस्ट्रोक्स के साथ एक अधिक उदार क्षेत्र में होता है।

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

— टिम ओ'नील
स्रोत
मेरे जैसे पुराने टाइमर ब्लॉक का चयन करने के लिए तीन कीस्ट्रोक्स का उपयोग करते हैं, जहां कोई लानत नहीं है।
— ergosys
2

मुझे व्यक्तिगत रूप से दूसरा तरीका पसंद है।

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

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);
— AndrejaKo
स्रोत
8
बुरा, बुरा, मेरा मतलब है भयानक, भयानक उदाहरण। समस्या ब्रेसिज़ नहीं है! यह पागल इंडेंटेशन है!
— आर। मार्टिनो फर्नांडिस
@ मर्तिन्हो फर्नांडीस ने मुझे लगा कि ब्रेसिज़ और इंडेंटेशन साथ-साथ चलते हैं ...
— आंद्रेजाको
2
जरूरी नहीं ... उपरोक्त पर उचित इंडेंटेशन करें और फिर ब्रेस-स्टाइल्स को बेतरतीब ढंग से स्विच करें, आप पाएंगे कि यह समझ में आता है।
— जकरियन
वास्तव में, इस बारे में सोचने से इस सवाल का अपना जवाब प्रेरित हुआ।
— जकरियन
"उनके द्वारा किए गए कार्यक्रम में 95% बग बेमेल से आए थे" - केवल व्याख्या की गई भाषाओं में, संकलित नहीं।
— मगग
2

मेरी व्यक्तिगत प्राथमिकता पहली विधि के लिए है, शायद इसलिए कि मैंने पहली बार PHP सीखी थी।

सिंगल-लाइन ifस्टेटमेंट के लिए, मैं उपयोग करूंगा

if (you.hasAnswer()) you.postAnswer();

यदि यह नहीं है, you.postAnswer();लेकिन बहुत लंबा है, जैसे कि you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);मैं शायद पहले प्रकार पर लौटूंगा:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

मैं कभी भी लाइन-ब्रेक का उपयोग नहीं करूंगा, और यदि कोई elseकथन है तो मैं इस पद्धति का उपयोग कभी नहीं करूंगा ।

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

एक सैद्धांतिक संभावना है, लेकिन मैं कभी भी उपयोग नहीं करूंगा। इसे चालू करना होगा

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}
— ट्रिग
स्रोत
2

उन्हें नहीं करना चाहिए; मेरे लिए पहला तरीका।

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

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

इसके अलावा, जैसा कि पहले ही कहा गया है, यह स्क्रीन में अधिक कोड को फिट करने की अनुमति देता है, जो अन्यथा थोड़ा उल्टा है।

— Joanis
स्रोत
2

यह मंच / भाषा / सम्मेलनों पर निर्भर करता है

जावा में: 

void someMethod() { 
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

C # में

void someMethod() 
{ 
     if (you.hasAnswer()) 
     {
         you.postAnswer();
     } 
     else 
     {
       you.doSomething();
     }
}

सी में:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

मुझे नफरत है जब जावा लोग सी # कोड में अपनी शैली का उपयोग करते हैं और इसके विपरीत।

— रिवील किया
स्रोत
3
सी स्टाइल ने मुझे हमेशा परेशान किया। निरतंरता बनाए रखें!
— ईसाई मान
1

मैं केवल इतना कह सकता हूं कि यदि आप विधि # 3 के प्रशंसक हैं, तो आपको पृथ्वी के प्रत्येक IDE कोड-फ़ॉर्मेटर द्वारा सताया जाने वाला है।

— फिल कोहेन
स्रोत
1

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

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

परंतु; सभी की सबसे महत्वपूर्ण बात है संगति। एक या दूसरे का उपयोग करें - दोनों कभी नहीं!

— gablin
स्रोत
0

जब मैं पहली बार 12 साल की प्रोग्रामिंग सीख रहा था, तो मैंने अगली पंक्ति में ब्रेसेस लगाए क्योंकि Microsoft कोडिंग ट्यूटोरियल इस तरह हैं। मैंने उस समय 4-स्पेस टीएबीएस के साथ भी इंडेंट किया था।

कुछ वर्षों के बाद, मैंने जावा और जावास्क्रिप्ट सीखा, और अधिक ब्रेसिज़-ऑन-समान लाइन कोड देखा, इसलिए मैंने बदल दिया। मैंने भी 2-स्पेस SPACES के साथ इंडेंट करना शुरू कर दिया।

— मिंग-तांग
स्रोत
5
+1, -1। आप टैब के साथ इंडेंट क्यों नहीं करेंगे क्योंकि कोई भी संपादक टैब की लंबाई को आपकी मनमानी लंबाई को समायोजित कर सकता है? अन्यथा, आप बहुत से ऐसे लोगों का नेतृत्व करते हैं जो आपके कोड को शाप देने के लिए 8 पर सच्चे संकेत पसंद करते हैं।
— जे क्यू कतार
0

एक 4 वां विकल्प है जो ब्रेसिज़ को संरेखित करता है, लेकिन अंतरिक्ष को बर्बाद नहीं करता है:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

एकमात्र समस्या यह है कि ज्यादातर आईडीई के ऑटोफॉर्माटर्स इस पर चोक करते हैं।

— AShelly
स्रोत
9
... जैसा कि अधिकांश प्रोग्रामर करते हैं जो इस पर चर्चा करेंगे।
— जे क्यू कतार
4
जो भयावह लगता है। यदि आप शीर्ष पर एक पंक्ति सम्मिलित करना चाहते हैं, या शीर्ष पंक्ति को निकालना चाहते हैं, तो अतिरिक्त प्रयास के बारे में सोचें। आप बस लाइन को हटा नहीं सकते हैं और आगे बढ़ सकते हैं, आपको घुंघराले ब्रेस को फिर से सम्मिलित करना याद रखना चाहिए।
— ब्रायन ओकले
यह बहुत बढ़िया है! :) पहले स्टाइल से बेहतर!
— नवफाल
जाहिर है इसका एक नाम भी है। होरिस्टमैन सीलिएक का उल्लेख विकिपीडिया में किया गया है । मैंने इस तरह एक कोडबेस के साथ काम किया है, यह वास्तव में उपयोग करने के लिए बुरा नहीं है।
— एएसएचली
-1

यह सब आप पर तब तक निर्भर करता है जब तक आप उस परियोजना पर काम नहीं कर रहे हैं जहाँ कुछ कोडिंग की कमी या कुछ मानकों को परियोजना प्रबंधक द्वारा निर्धारित किया गया है कि कोडिंग करते समय उस परियोजना पर काम करने वाले सभी प्रोग्रामर को पालन करना होगा।

मैं व्यक्तिगत रूप से 1 विधि को पसंद करूंगा।

इसके अलावा, मुझे वह नहीं मिला, जो आप 3 तरीके से दिखाना चाहते हैं?

क्या यह गलत तरीका नहीं है? उदाहरण के लिए एक स्थिति पर विचार करें।

if (you.hasAnswer())
  you.postAnswer();
else
  you.doSomething();

अब क्या अगर किसी में कुछ और बयान जोड़ना चाहता है , तो ब्लॉक?

उस स्थिति में यदि आप तीसरी विधि का उपयोग करते हैं तो संकलक सिंटैक्स त्रुटि को फेंक देगा।

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();
— चनक पाठक
स्रोत
2
इससे भी बुरा यह होगा कि अगर कोई साथ आए और किया जाए: अगर (you.hasAnswer ()) you.postAnswer (); और आप। you.doSomethingElse (); - यह सूक्ष्म बग के लिए एक नुस्खा है जिसे आंख आसानी से फिसल सकती है और संकलक या तो बाहर निकलने में मदद नहीं करेगा
— FinnNk
@ फ़िनके: बिल्कुल!
— १
2
यदि कोई अन्य कथन जोड़ना चाहता है, तो वे स्वयं ब्रेस में डाल सकते हैं। अपने नमक के लायक कोई भी प्रोग्रामर वास्तव में यह पता लगाने में सक्षम होना चाहिए।
— रॉबर्ट हार्वे
मैं कहना चाहता था कि उसका तीसरा तरीका गलत है।
— चन्नी पाठक
3
@ रॉबर्ट हार्वे, मैंने बहुत अनुभवी कॉडर्स को मौजूदा कोड को संशोधित करते समय ब्रेसिज़ को मिस करने के लिए देखा है। मुझे लगता है कि समस्या यह है कि इंडेंटेशन ब्रेसिज़ की तुलना में अर्थ के लिए एक बहुत मजबूत सुराग है (विशेषकर चूंकि कई ब्रेस स्टाइल हैं), इसलिए अगर आप उम्मीद करते हैं कि इंडेंटेशन जैसा दिखता है तो लापता ब्रेस की अनदेखी करना काफी आसान है।
— एएसपी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.