घुंघराले ब्रेसिज़ को छोड़ना एक बुरा अभ्यास क्यों माना जाता है? [बन्द है]

177

हर कोई मुझे इस तरह कोड लिखने के लिए क्यों कहता है यह एक बुरा अभ्यास है?

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

घुंघराले ब्रेसिज़ को छोड़ने के लिए मेरा सबसे बड़ा तर्क यह है कि यह कभी-कभी उनके साथ दो बार हो सकता है। उदाहरण के लिए, यहां C # में लेबल के लिए चमक प्रभाव को चित्रित करने के लिए कुछ कोड दिए गए हैं।

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

आप usingsएक लाख बार इंडेंट किए बिना एक साथ चेनिंग का अतिरिक्त लाभ प्राप्त कर सकते हैं ।

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

घुंघराले ब्रेसिज़ के लिए सबसे आम तर्क मेन्टेंस प्रोग्रामिंग के इर्द-गिर्द घूमता है, और समस्याएँ जो मूल और कथन के बीच कोड डालने से होती हैं।

if (foo)
    Bar();
    Biz();

प्रशन:

  1. क्या अधिक कॉम्पैक्ट सिंटैक्स का उपयोग करना गलत है जो भाषा प्रदान करती है? जो लोग इन भाषाओं को डिज़ाइन करते हैं, वे स्मार्ट हैं, मैं कल्पना नहीं कर सकता कि वे एक ऐसी सुविधा डालेंगे जिसका उपयोग करना हमेशा खराब होता है।
  2. क्या हमें या हमें कोड नहीं लिखना चाहिए ताकि सबसे कम आम भाजक समझ सकें और इसके साथ काम करने में कोई समस्या न हो?
  3. क्या कोई और तर्क है जो मुझे याद आ रहा है?
java  c#  c++  c  coding-style 
— बॉब
स्रोत
6
मैं आपसे सहमत हुँ। उन्हें छोड़ दें। अवधि।
— आंद्रेई रोनेया
67
WHO CARES ABUT HOW MANY LINES SOMETHING IS IT IS is in 2010। मॉनिटर्स विस्तृत और सस्ते और उच्च रेस हैं! मेरा मॉनिटर 2048 एक्स 1152 है और मुझे उनमें से दो हैं! पठनीयता अधिक महत्वपूर्ण है कि 2 ऊर्ध्वाधर लाइनों को सहेजना जब आप आसानी से सूक्ष्म त्रुटियों को पेश कर सकते हैं जो कि खोजना मुश्किल है।
51
मॉनिटर विस्तृत और सस्ते हैं, लेकिन वे लंबे और सस्ते नहीं हैं । ऊर्ध्वाधर स्थान क्षैतिज स्थान की तुलना में अधिक दुर्लभ है।
— एडम कहते हैं - मोनिका को बहाल करो
32
@AdamRuth उन्हें बग़ल में घुमाएँ :)
— Zachary Yates
16
तो आप Apple की तरह खराब नहीं होते जैसे कि 2014 की फरवरी में मिलने वाले SSL बग के साथ LOL।
— learnvst

जवाबों:

183

वास्तव में, केवल एक बार जो वास्तव में कभी-कभी मेरे साथ होता है जब मैं डिबगिंग कर रहा था, और बार () टिप्पणी करता था:

if(foo)
  // bar();
doSomethingElse();

इसके अलावा, मैं उपयोग करते हैं:

if(foo) bar();

जो उपरोक्त मामले का ख्याल रखता है।

EDIT प्रश्न को स्पष्ट करने के लिए धन्यवाद, मैं सहमत हूं, हमें सबसे कम सामान्य भाजक को कोड नहीं लिखना चाहिए।

— ज़ाचरी येट्स को दर्शाता है
स्रोत
31
यह निश्चित रूप से है, लेकिन मुझे लगता है कि अनुरक्षकों के लिए सबसे बड़ी समस्या यह है कि वे एक दूसरी पंक्ति जोड़ेंगे, और यह महसूस नहीं करेंगे कि यह सशर्त बयान का हिस्सा नहीं है, भले ही यह वास्तव में ऐसा लगता है कि ऐसा होना चाहिए।
— danieltalsky
23
मुझे एक लाइनर शैली पसंद नहीं है क्योंकि मैं हमेशा नीचे लूप बॉडी की तलाश में जाता हूं।
— नोसरेडना
18
मुझे एक-लाइनर शैली उपयोगी से अधिक परेशान लगती है क्योंकि (विशेष रूप से गहरी घोंसले के शिकार - ऊग) कथन को आसानी से फैलाया जा सकता है और भ्रम हो सकता है। मैं लगभग अनन्य रूप से ऐसे एकल-कथन का उपयोग करता हूं यदि इनपुट सत्यापन (प्रारंभिक रिटर्न) या लूप नियंत्रण (उदाहरण के लिए फाइलसिस्टम वॉक में अप्रासंगिक फ़ाइल नामों को अनदेखा करना), हालांकि, जहां रिक्त लाइनें मुख्य कोड से उन्हें स्थापित करने में मदद करती हैं।
— एलन प्लम
1
एक-पंक्ति शैली भी परीक्षण कवरेज से बार () को छुपाती है। यह तब भी कवर किया जाएगा जब तक कि फू हमेशा झूठी हो।
— बोहुमिल जंडा
1
यह कहने का एक और तरीका है, "स्रोत में घुंघराले ब्रेसिज़ शामिल थे, मैंने डिबगिंग करते समय समय बर्बाद नहीं किया होगा।" - ब्रेसिज़ जोड़ना सामान्य रूप से सरल है, और अगले व्यक्ति के लिए नुकसान छोड़ने से बचा जाता है। के खिलाफ एकमात्र तर्क "पठनीयता" है, जो बहुत ही कठिन है, यह देखते हुए कि यह एक ऐसा मामला है जहां कुछ निहित है अगर आप उन्हें छोड़ देते हैं।
— एंड्रयू थेकेन
156

पढ़ने की गति ...

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

if (condition)
{
    DoSomething();
}

DoSomethingElse();

मेरे द्वारा पढ़े जाने से थोड़ा तेज़:

if (condition) DoSomething();

DoSomethingElse();

मैं इसे थोड़ा धीमा पढ़ता हूँ अगर यह इस तरह दिखता है:

if (condition) DoSomething();
DoSomethingElse();

मैंने पहले की तुलना में इसे काफी धीमा पढ़ा:

if (condition) 
    DoSomething();
DoSomethingElse();

मैं किसी भी मामले में मदद नहीं कर सकता लेकिन आश्चर्य है कि अगर लेखक का इरादा हो तो इसे पढ़ें:

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

पहले से ही सामान्य रूप से कवर किया गया है, लेकिन जब यह नीचे पढ़ने की बात आती है , तो मैं यह सुनिश्चित करने के लिए काफी समय से देख रहा हूं कि लेखक क्या चाहता है। मैं भी पुष्टि करने के लिए मूल लेखक का शिकार कर सकता हूं।

if (condition) 
    DoSomething();
    DoSomethingElse();
— क्रैशकोड्स को दर्शाता है
स्रोत
29
समस्या तब हल हो जाती है, जब आपके 4 वें नमूने में, आप सिर्फ एक खाली लाइन डालते हैं, अगर कथन के बाद इसे DoSomethingElse () से अलग किया जाए, तो मैं जो करता हूं और पठनीयता व्यावहारिक रूप से 1 नमूना (यदि बेहतर नहीं है; -पी) के साथ ही है; एक और बात यह है कि 2 या 3 के समूहों में लाइनें लगाने से पठनीयता में मदद मिलती है, आप बस कोड को बहुत तेजी से स्कैन करते हैं।
— पायोत्र ओविसक
6
शायद यह इसलिए है क्योंकि मैं पाइथन के लिए उपयोग किया जाता हूं, लेकिन पहली घुंघराले ब्रेस को उसी लाइन पर रख रहा हूं जैसे कि यदि स्टेटमेंट मुझे पढ़ने की अनुमति देता है + तो इसे और भी जल्दी समझ लें।
— पोंकडूडल
16
ब्रेसेलेस शैली के साथ समस्या यह आपको अपनी कीमती एकाग्रता को यह सोचने में बर्बाद कर देती है कि ब्लॉक में अधिक महत्वपूर्ण चीजों के बजाय ब्रेसिज़ हैं या नहीं। यह अकेले सबसे सरल संभव सम्मेलन का उपयोग करने के लिए एक अच्छा पर्याप्त कारण है, जो हमेशा ब्रेसिज़ होता है।
— नैट सीके
2
ब्रेस स्वभाव से स्पष्ट हैं। मैं उसके साथ रहूँगा, धन्यवाद।
— TheptimusPrimus
2
आखिरी मामले में, मूल लेखक का शिकार करें और उसे छोड़ दें ...;)
— प्रति लुंडबर्ग
55

यदि यह कुछ छोटा है, तो इसे इस तरह लिखें:

if(foo()) bar();

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

— एडम जास्कविज़
स्रोत
हाँ, मैं भी यही करता हूँ। यह आपको ब्रेसिज़ जोड़ने के लिए मजबूर करता है यदि आप एक और लाइन जोड़ते हैं, और यह देखने के लिए बहुत स्पष्ट है कि बार () वास्तव में अगर का हिस्सा है, तो खराब चीजें तब होंगी जब आप इसे टिप्पणी करेंगे।
— :
10
हालांकि बहुत डिबगर-फ्रेंडली नहीं है। आप "बार" भाग पर एक ब्रेकपॉइंट कैसे सेट करते हैं?
— निमन्जा ट्रिफ़ुनोविक
9
@ नेमंजा: बस अपने कर्सर को बार () पर रखें; और F9 मारा। VS2005 और VS2008 दोनों इंट्रा-लाइन ब्रेकप्वाइंट को संभालते हैं, यदि वे अलग-अलग "स्टेटमेंट" हैं।
— गांगेय
4
GalanticCowboy: आपके द्वारा ज्ञात से अधिक वातावरण हैं। :-)
20
ज़रूर, लेकिन चूंकि संदर्भ C # है, इसलिए उपयोगकर्ताओं के एक महत्वपूर्ण हिस्से को कवर करना चाहिए ...
— GalacticCowboy
47

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

हमेशा ब्रेसिज़ का उपयोग करने का एक और अच्छा कारण है, इसके अलावा अगर कोई दूसरा बयान जोड़ रहा है तो, ऐसा कुछ हो सकता है:

if(a)
   if(b)
     c();
else
   d();

क्या आपने देखा कि वास्तव में अन्य खंड "अगर (बी)" है? आपने शायद किया था, लेकिन क्या आप इस गोचरा से परिचित होने के लिए किसी पर भरोसा करेंगे?

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

— FredV
स्रोत
12
यह उन दो मामलों में से एक है जहां मैं ब्रेसिज़ का उपयोग करता हूं। नहीं तो नहीं।
— आंद्रेई R Andrenea
3
इसके बजाय यह लिखा जाना चाहिए जैसे (a && b) ... पहली जगह पर मेथिंक।
— अलेक्जेंडर.बिस्कॉप
8
@ अलेक्जेंडर.बिस्कॉप: निश्चित रूप से नहीं, क्योंकि इससे दूसरे ब्लॉक ( !a || !bया तो !a) या बिना ( a && !b) जोड़े हुए ब्रेस की तुलना में एक अलग अर्थ ( ) ब्लॉक हो जाता है।
— बेन वोइग्ट
1
@ बॉन वायगेट: सच! इसके लिए फेल ;-) एक साल में आधा और दो बाद में, किसी को मेरे द्वारा दिए गए बयान का एहसास गलत है ... लगता है कि मैंने विस्तार पर पर्याप्त ध्यान नहीं दिया, मुख्य रूप से क्योंकि मेरी टिप्पणी के पीछे का उद्देश्य इंगित करने की तुलना में एक अलग था अगर-खण्ड है कि तकनीकी रूप से सही परिवर्तन। मेरा मतलब था कि नेस्टेड इनलाइन अगर स्टेटमेंट में आमतौर पर पठनीयता कम हो जाती है (और कंट्रोल फ्लो की ट्रेसबिलिटी) काफी इमो हो जाती है और इसलिए इसे एक स्टेटमेंट (या पूरी तरह से दरकिनार) में जोड़ा जाना चाहिए। चीयर्स
— अलेक्जेंडर.बिस्कॉप
3
@ अलेक्जेंडर.बिस्कॉप: एक ही समय में, डिबगिंग नेस्टेड के साथ आसान है यदि प्रत्येक सरल परिस्थितियों के साथ हो, क्योंकि आप प्रत्येक पर सिंगल स्टेप कर सकते हैं।
— बेन वोइग्ट
35

यह हमेशा एक बुरा अभ्यास नहीं माना जाता है। मोनो परियोजना कोडिंग दिशानिर्देश घुंघराले ब्रेसिज़ का उपयोग नहीं करने का सुझाव अगर यह आवश्यक नहीं है। के लिए एक ही जीएनयू मानक कोडिंग । मुझे लगता है कि कोडिंग मानकों के साथ यह हमेशा व्यक्तिगत स्वाद की बात है।

— मैनुअल सेरोन
स्रोत
2
पूरी गाइडलाइन पढ़ने के बाद मोनो कोड को देखना मुझे काफी विदेशी लगता है ।
— नृत्य 2
35

लाइनें सस्ती हैं। प्रोसेसर शक्ति सस्ती है। डेवलपर का समय बहुत महंगा है।

एक सामान्य नियम के रूप में, जब तक मैं कुछ बिल्कुल संसाधन / गति महत्वपूर्ण अनुप्रयोग विकसित नहीं कर रहा हूं, मैं हमेशा कोड लिखने के पक्ष में गलत होगा

(ए) किसी भी अन्य डेवलपर के लिए आसान है कि मैं क्या कर रहा हूं

(b) कोड के विशिष्ट भागों पर टिप्पणी करें जिनकी उसे आवश्यकता हो सकती है

(c) कुछ गलत होने पर डिबग करना आसान

(d) भविष्य में होने की जरूरत है (यानी कोड जोड़ना / हटाना) अगर संशोधित करना आसान है

कोड की गति या अकादमिक लालित्य एक व्यावसायिक दृष्टिकोण से इन कारकों के लिए माध्यमिक है। यह कहने के लिए नहीं है कि मैं क्लंकी या बदसूरत कोड लिखने के लिए तैयार हूं, लेकिन यह मेरी प्राथमिकता का क्रम है।

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

— Jayden
स्रोत
9
(ए) के बारे में आपका अंतिम कथन एक राय है कि यहां अन्य पोस्टर सहित बड़ी संख्या में देव बहस करेंगे।
— केली एस। फ्रेंच
34

मुझे स्पष्टता पसंद है कि घुंघराले ब्रेस प्रदान करता है। तुम्हें पता है कि वास्तव में क्या मतलब है और यह अनुमान लगाने की ज़रूरत नहीं है कि किसी ने बस नासमझ और उन्हें छोड़ दिया (और बग को पेश किया)। केवल एक बार जब मैं उन्हें छोड़ता हूं, जब मैं एक ही लाइन पर इफ और एक्शन डालता हूं। मैं ऐसा बहुत बार भी नहीं करता। मैं वास्तव में अपनी लाइन पर घुंघराले ब्रेस लगाकर शुरू की गई व्हाट्सएप को पसंद करता हूं, हालांकि K & R C- जैसी प्रोग्रामिंग के वर्षों से, ब्रेस के साथ लाइन को समाप्त करना एक अभ्यास है जिसे दूर करने के लिए मुझे काम करना होगा अगर IDE इसे लागू नहीं करता है मुझे।

if (condition) action();  // ok by me

if (condition) // normal/standard for me
{
   action();
}
— tvanfosson
स्रोत
23

मुझे लगता है कि यह उस परियोजना के लिए दिशानिर्देशों की बात है जिसे आप और व्यक्तिगत स्वाद पर काम कर रहे हैं।

मैं आमतौर पर उन्हें छोड़ देता हूं जब उनकी आवश्यकता नहीं होती है, जैसे कुछ मामलों को छोड़कर:

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

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

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}
— Maghis
स्रोत
15

ऐसे उदाहरणों में से एक जहां यह आपको काट सकता है C / C ++ मैक्रोज़ के पुराने दिनों में वापस। मुझे पता है कि यह एक सी # प्रश्न है, लेकिन अक्सर कोडिंग मानक बिना कारण बताए कि मानक पहले स्थान पर क्यों बनाए गए थे।

यदि आप अपने मैक्रोज़ बनाते समय बहुत सावधान नहीं हैं, तो आप {} का उपयोग न करने वाले कथनों के साथ समस्याएँ पैदा कर सकते हैं।

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

अब, मुझे गलत मत समझो, मैं यह नहीं कह रहा हूं कि आपको हमेशा C {C ++ में इस समस्या से बचने के लिए {} करना चाहिए, लेकिन मुझे इसके कारण कुछ बहुत ही अजीब बग से निपटना पड़ा है।

— Torlack
स्रोत
2
यदि केवल सभी कोड ही घोषित किए जाते हैं ... आह
— नाथन स्ट्रॉन्ग
15

मैं उसी तरह सोचने के लिए उपयोग करता हूं।

एक दिन तक (हमेशा ऐसा क्यों होता है कि "एक दिन" जो आपके जीवन को हमेशा के लिए बदल देता है?) हम 24 से - 36 घंटे सीधे नींद डिबगिंग उत्पादन कोड के बिना बिताते हैं केवल यह पता लगाने के लिए कि किसी ने खोज / प्रतिस्थापन परिवर्तन के साथ संयुक्त ब्रेसिज़ नहीं लगाए। ।

यह कुछ इस तरह था।

 if( debugEnabled ) 
      println( "About to save 1 day of work to some very important place.");
 saveDayData();

उसके बाद क्या था 

 if( debugEnabled ) 
 //     println( "About to save 1 day of work to some very important place.");
 saveDayData();

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

फिर भी जब एप्लिकेशन डिबग ध्वज का उत्पादन करने के लिए चला गया था और महत्वपूर्ण "saveDayData" को कभी नहीं बुलाया गया था।

संपादित करें

अब केवल वही स्थान है जहाँ मैं ब्रेसिज़ का उपयोग नहीं करता / करती हूँ अगर / निर्माण में कोशिश करें।

if( object != null ) try { 
     object.close();
} catch( .....

एक सुपरस्टार डेवलपर को देखने के बाद।

— रिवील किया
स्रोत
3
मुझे समझ नहीं आ रहा है। आपके पास एक चर है जो डिबगिंग (डिबग एनेबल्ड) को नियंत्रित करता है और आप अभी भी डिबगिंग को अक्षम करने के लिए टिप्पणियों का उपयोग करते हैं ??? आपने केवल डिबग अक्षम को झूठे पर सेट क्यों नहीं किया?
— इगोर पोपोव
यह वास्तव में परिदृश्य नहीं है, लेकिन आप एक अच्छा बिंदु बनाते हैं। मूर्खतापूर्ण बातें (जैसे डिबग को गलत नहीं करना) सूक्ष्म और बेवकूफ बग बनाते हैं जो "स्पष्ट" बग की तुलना में कठिन हैं। ब्रेसिज़ का उपयोग नहीं करने से इस मामले में बहुत मदद नहीं मिली।
— OscarRyz
1
@igor कैसे के बारे में क्योंकि वे सिर्फ लॉगिंग की एक लाइन को हटाना चाहते थे, लॉगिंग की सभी लाइनों को नहीं?
— gman
14

कुंद होने के लिए मैं इसे देखता हूं:

अच्छे प्रोग्रामर कार्यक्रम रक्षात्मक रूप से, खराब प्रोग्रामर नहीं करते हैं।

चूंकि ऊपर कई उदाहरण हैं और ब्रेसिज़ को भूलने से संबंधित कीड़े के साथ मेरे अपने समान अनुभव हैं तो मैंने हमेशा अलग तरीके से सीखे।

कुछ भी सुरक्षा पर व्यक्तिगत शैली का चयन कर रहा है और यह स्पष्ट रूप से खराब प्रोग्रामिंग है।

जोएल ने गलत कोड लुक बनाने में भी इसका उल्लेख किया है

एक बार जब आप लापता ब्रेस की वजह से बग से थोड़ा जुड़ जाते हैं तो आप सीखते हैं कि लापता ब्रेसिज़ गलत दिखते हैं क्योंकि आप जानते हैं कि यह एक और बग होने की संभावित जगह है।

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

मैं काफी खुश हूं:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

निजी तौर पर, मैं यह नहीं देखता कि क्यों

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

कोई और अधिक पठनीय है।

हां, लाइनें मुफ्त हैं, लेकिन मुझे पृष्ठों और कोड के पन्नों के माध्यम से स्क्रॉल क्यों करना चाहिए जब यह आधा आकार हो सकता है?

यदि पठनीयता या स्थिरता में अंतर है, तो निश्चित रूप से, ब्रेसिज़ को अंदर रखें ... लेकिन इस मामले में मुझे कोई कारण नहीं दिखता है।

इसके अलावा, मैं हमेशा नेस्टेड के लिए ब्रेसिज़ लगाऊंगा, अगर मेरे पास नेस्टेड है, जहां

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

बनाम

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

बहुत भ्रामक है, इसलिए मैं हमेशा इसे लिखता हूं:

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

जब भी संभव हो, मैं टर्नरी ऑपरेटरों का उपयोग करता हूं, लेकिन मैं कभी भी उन्हें घोंसला नहीं देता ।

— Ozzah
स्रोत
बस यह लगभग मेरे कोड में हो रहा है :) लगा कि मुझे चारों ओर एक नज़र होगी, और लो और निहारना ... यह पहले से ही बाहर है :)
— Noctis
10

मैं मानता हूं कि "यदि आप कोड लिखने के लिए आपको भुगतान करने के लिए किसी को पाने के लिए पर्याप्त स्मार्ट हैं, तो आपको कोड के प्रवाह को देखने के लिए केवल इंडेंटेशन पर भरोसा नहीं करने के लिए पर्याप्त स्मार्ट होना चाहिए।"

हालाँकि ... गलतियाँ की जा सकती हैं, और यह एक डीबग करने का दर्द है ... खासकर यदि आप किसी और के कोड को देख रहे हैं।

— chills42
स्रोत
10

मेरा दर्शन है अगर यह कोड को अधिक पठनीय बनाता है, तो इसे क्यों नहीं?

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

आप तर्क दे सकते हैं कि कोडर होने के लिए स्मार्ट होने वाले लोग उन ब्रैकेट्स से बचने के लिए पर्याप्त स्मार्ट बनने जा रहे हैं जो कि ब्रैकेटलेस स्टेटमेंट्स को स्टेम करते हैं। लेकिन क्या आप ईमानदारी से कह सकते हैं कि आप किसी वर्तनी त्रुटि के रूप में सरल रूप में किसी चीज से कभी नहीं फंस गए हैं? बड़ी परियोजनाओं को देखते हुए इस तरह की Minutia भारी पड़ सकती है।

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

हमेशा अपवाद होते हैं, लेकिन मैं ब्रेसिज़ को केवल तब छोड़ने के लिए तर्क दूंगा जब यह किसी एक रूप में हो:

if(x == y)
   for(/* loop */)
   {
      //200 lines
   }

//rampion's example:
for(/* loop */)
{
   for(/* loop */)
      for(/* loop */)
      {
         //several lines
      }
}

अन्यथा, मुझे इससे कोई समस्या नहीं है।

— टॉम रिटर को दर्शाता है
स्रोत
4
खराब उदाहरण। उन दोनों मामलों में, मैं उस लूप के लिए 200 लाइन को अपने तरीके से, या अधिमानतः कई तरीकों से फैक्टर करूँगा।
— एडम जास्कविज़ 16
2
सच है, लेकिन ऐसा होता है। इसके अलावा, किसी भी समय पाठक की स्क्रीन के मुकाबले एक ब्लॉक लंबा होता है, आपके पास यह मुद्दा होगा। और आप अपने कोड रीडर की स्क्रीन ऊंचाई को नियंत्रित नहीं कर सकते। वे केवल हर तरफ एक दो लाइनें देख सकते हैं।
— १६
2
होता ही है। इसका मतलब यह नहीं है कि ऐसा होना चाहिए।
— एडम जस्क्यूविज़
3
@AdamJaskiewicz राइट होता ही है। हम क्या बारे में सोचना है होता है, न कि जो की तुलना में चाहिए होता है। अगर हम खुद को प्रतिबंधित कर सकते हैं तो क्या होना चाहिए हमें बग के बारे में चिंता करने की आवश्यकता नहीं होगी।
— बेस्का
10

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

मैंने देखा है

if (...)
    foo();
    bar();

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

बेशक यदि आप "पंक्ति के अंत में ब्रेस" का उपयोग करते हैं, तो यह अतिरिक्त लाइनों को कम कर देता है, लेकिन मैं व्यक्तिगत रूप से वैसे भी उस शैली को पसंद नहीं करता। (मैं इसे काम पर उपयोग करता हूं, और मैंने इसे अपनी अपेक्षा से कम अप्रिय पाया है, लेकिन यह अभी भी थोड़ा अप्रिय है।)

— जॉन स्कीट
स्रोत
मैं हमेशा इस मामले में तर्क देता हूं कि वास्तविक शैली की तुलना में संगतता अधिक महत्वपूर्ण है, हमें केवल usings के मामले में अपवाद क्यों बनाना चाहिए?
— बॉब
@ याकूब: अच्छी बात है, और मैं इसे कभी-कभार ही करता हूँ। मैं यह बहाना नहीं करना चाहूंगा कि मेरे पास वास्तविक कारण हैं :) वास्तव में, एक उचित कारण है - इस तरह के usings (और केवल usings) घोंसले बनाना काफी स्पष्ट है, और आप अभी भी एक ब्लॉक के साथ समाप्त होते हैं । मैं तुरंत खतरे को नहीं देख सकता।
— जॉन स्कीट
यह कहना नहीं है कि निश्चित रूप से कोई खतरा नहीं है ।
— जॉन स्कीट
1
इस बग का सबसे अच्छा समाधान: पायथन का उपयोग करें। (
— किडिंग
10

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

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

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

उस ने कहा, दुनिया में कुछ चीजें बदल गई हैं, जो "एकल-पंक्ति ब्लॉकों पर ब्रेसिज़ का उपयोग करते हैं" नियम आज कम प्रासंगिक है जब मूसा ने इसे हमारे सामने लाया:

  • कुछ लोकप्रिय भाषाएं कंप्यूटर को इंडेंटेशन पढ़कर समस्या को दूर कर देती हैं, ठीक उसी तरह जैसे प्रोग्रामर करता है (जैसे कि पायथन)।

  • मेरा संपादक मेरे लिए स्वतः ही प्रारूपित हो जाता है, इसलिए मुझे इंडेंटेशन द्वारा गुमराह होने की संभावना बहुत कम हो जाती है।

  • TDD का मतलब है कि अगर मैं बग का परिचय देता हूं क्योंकि मैं सिंगल-लाइन ब्लॉक से भ्रमित हो जाता हूं, तो मुझे बग को जल्दी से खोजने की बहुत अधिक संभावना है।

  • रिफैक्टरिंग और भाषा की अभिव्यक्ति का मतलब है कि मेरे ब्लॉक बहुत कम हैं, और सिंगल-लाइन ब्लॉक उपयोग किए जाने की तुलना में बहुत अधिक बार होते हैं। Hypothetically, ExtractMethod के एक निर्दयी आवेदन के साथ, मैं संभवतः अपने पूरे कार्यक्रम में केवल एकल-पंक्ति ब्लॉक कर सकता था। (मुझे आश्चर्य है कि ऐसा क्या लगेगा?)

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

if (condition) Foo();   // normal, everyday code

if (condition) 
{
    // something non-trivial hapening; pay attention!
    Foo();
    Bar();
}

मैं अपने कोडिंग कन्वेंशन को "सिंगल-लाइन ब्लॉक में कभी ब्रेसिज़ नहीं हो सकता" या "यदि आप शर्त के रूप में एक ही लाइन पर ब्लॉक रख सकते हैं, और यह सब 80 वर्णों के भीतर फिट बैठता है," ब्रेसिज़ को छोड़ दें ”। हम देखेंगे।

— रे बाज़ूज़ी
स्रोत
एक पूर्व जावा प्रोग्रामर के रूप में, मुझे स्वचालित स्वरूपण के साथ समस्या का वास्तविक उत्तर होने पर पूरी तरह से सहमत होना होगा। आपको अपने संपादक को स्वचालित रूप से ब्रेसिज़ जोड़ने की ज़रूरत नहीं है - अकेले ऑटो-इंडेंटिंग से अस्पष्टताओं से बचने में बहुत मदद मिल सकती है। बेशक अब जब मैंने पायथन पर स्विच किया है, तो मुझे पहली बार अपने कोड को ठीक से प्रारूपित करने की आदत हो गई है।
— एलन प्लम
मैं ब्रेसिज़ के बारे में ऐसा ही महसूस करता हूं। यह सब जटिलता के बारे में है। आदर्श रूप में हमारे पास केवल एक लाइन ब्लॉक होगा। यही मैं पठनीयता कहता हूं, अनावश्यक ब्रेसिज़ नहीं।
— इगोर पोपोव
9

तीन सम्मेलनों में से:

if(addCurleyBraces()) bugFreeSofware.hooray();

तथा:

if(addCurleyBraces())
    bugFreeSofware.hooray();

और (जो एक उद्घाटन और समापन ब्रेस का उपयोग करके किसी भी इंडेंटेशन शैली का प्रतिनिधित्व करते हैं):

if(addCurleyBraces()) {
    bugFreeSofware.hooray();
}

मैं पिछले एक को पसंद करता हूं:

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

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

लाइनें (लगभग) मुफ्त हैं, आपके कोड में लाइनों की संख्या को कम करना एक उद्देश्य नहीं होना चाहिए।

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

— पॉल मिशेल को दर्शाता है
स्रोत
8

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

कुछ लोग कह सकते हैं कि यह वरीयता का मामला है, लेकिन मुझे लगता है कि अगर यह आंतरिक रूप से सुसंगत है, तो मुझे एक प्रोग्राम का तार्किक प्रवाह बहुत आसान लगता है, और मुझे विश्वास नहीं होता कि यह इस तरह से एक आईएफ स्टेटमेंट लिखने के लिए सुसंगत है;

if(x < y)
    x = y;
else
    y = x;

और इस तरह एक और;

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

मैं सिर्फ एक सामान्य शैली चुनना चाहता हूं और इसके साथ रहना चाहता हूं :)

— क्रिस्टोफर मैकऐटकी
स्रोत
7

मुख्य मुद्दों में से एक तब होता है जब आपके पास नियंत्रण लाइन (और for, ifआपके पास क्या है) और क़ानून के अंत से अलग होने के साथ-साथ एक-लाइनर्स और गैर-एक लाइनर्स के क्षेत्र होते हैं ।

उदाहरण के लिए:

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}
— rampion
स्रोत
4
वैसे भी आपके पास लूप के लिए कोड के कुछ पृष्ठ क्यों हैं?
— एडम जास्कविज़ 16
b / c मैं असंवेदनशील क्लोड हूं, और मैं फंक्शन कॉल्स के "कॉस्ट" से छुटकारा पा रहा हूं। :)
— १६
4
कोड के पृष्ठों की जोड़ी आमतौर पर एक अलग फ़ंक्शन में होनी चाहिए।
— जोनाथन लेफ़लर
1
मुझे माफ करना, मेरा मतलब है कि मैं इस तरह के एक क्लॉड की भूमिका निभा रहा था। हालांकि, मेरा मानना ​​है कि छोटे क्षेत्रों के लिए भी यही समस्या हो सकती है, जब छोटे व्यूपोर्ट के माध्यम से देखा जा सकता है। और यह कोडर के नियंत्रण के बाहर है।
— रैंपियन
7

मैं "घुंघराले ब्रेसिज़ एक MUST!" का बहुत बड़ा समर्थक हुआ करता था, लेकिन यूनिट टेस्टिंग को अपनाने के बाद से, मुझे लगता है कि मेरी यूनिट के टेस्ट जैसे परिदृश्यों से ब्रेस्लेस स्टेटमेंट की रक्षा करते हैं:

if (foo)
    snafu();
    bar();

अच्छी इकाई परीक्षणों के साथ, मैं आसानी से पठनीयता में सुधार के लिए सरल बयानों के लिए घुंघराले ब्रेसिज़ को छोड़ सकता हूं (हाँ, यह व्यक्तिपरक हो सकता है)।

वैकल्पिक रूप से, ऊपर की तरह कुछ के लिए, मैं इनलाइन की तरह दिखने की संभावना है:

if (foo) snafu();

इस तरह, डेवलपर को शर्त में बार () जोड़ने की जरूरत है, घुंघराले ब्रेसिज़ की कमी को पहचानने और उन्हें जोड़ने के लिए अधिक उपयुक्त होगा।

— Liggy
स्रोत
2
आपने कहा "मुझे इसकी आवश्यकता नहीं है" तो इसे उपयोग करने का एक कारण दिया: पठनीयता!
— tvanfosson
4
मुझे लगता है कि खोजने के लिए एक यूनिट टेस्ट पर भरोसा नहीं करेगा। शायद, यूनिट टेस्ट नं!
— क्रिस्टन
2
@ क्रिस्टन - यूनिट टेस्ट का विचार विधि के व्यवहार को मुखर करना है। यदि व्यवहार बदलता है (जैसा कि ऊपर वर्णित है) इकाई परीक्षण विफल हो जाएगा। मुझे इसमें समस्या नहीं दिख रही है।
— लिग्गी
लेकिन यूटी में जाने से पहले जो स्पष्ट रूप से तय किया जाना चाहिए उसे लेने के लिए यूनिट टेस्ट पर भरोसा क्यों करें?
— एंड्रयू
7

कुछ व्यक्तिगत निर्णय का उपयोग करें।

if (foo)
  bar();

अपने आप ठीक है। जब तक आप वास्तव में मोरों के बारे में चिंतित न हों, तब तक कुछ इस तरह से रखें:

if (foo)
  bar();
  baz();

यदि आप मोरों के बारे में चिंतित नहीं हैं, तो आप ठीक हैं (मैं नहीं हूं - अगर उन्हें मूल कोड सिंटैक्स सही नहीं मिल सकता है, तो यह उनकी समस्याओं का कम से कम>> है)

बदले में, यह बहुत अधिक पठनीय है।

बाकी का समय:

if (foo) {
  bar();
  baz();
}

जब तक मुझे याद है मेरा पसंदीदा रहा है। इसके अतिरिक्त:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

मेरे लिये कार्य करता है।

वर्टिकल स्पेस अपने आप में बहुत प्रासंगिक नहीं है, पठनीयता है। अपने आप एक लाइन पर खुलने वाला ब्रेस सिर्फ एक सिंटैक्टिक तत्व के लिए बातचीत को रोक देता है, जब तक कि आपकी आंख अगली पंक्ति में नहीं जाती। मुझे पसंद नहीं है।

— लल्ली
स्रोत
पहली बार जब मैं पहली शैली पसंद करता हूं, जब मुझे तुरंत वापस लौटना पड़ता है या कुछ गलत होने की स्थिति में कोई त्रुटि होती है। की तरह if (parameter == null) return null;।
— नवफाल
7

ठीक है, यह एक पुराना सवाल है जिसका जवाब मौत को दिया गया है। मुझे कुछ जोड़ना है।

पहले मुझे सिर्फ ब्रिक्स का उपयोग करना है। जब तक आप असेंबली नहीं लिख रहे हैं, वे केवल आपकी प्राथमिकता सूची में पठनीयता और पठनीयता (अपने लिए और दूसरों के लिए!) की मदद कर सकते हैं। अपठनीय कोड हमेशा, हमेशा बग की ओर जाता है। यदि आप पाते हैं कि ब्रेसिज़ आपके कोड को बहुत अधिक स्थान लेते हैं, तो आपके तरीके संभवतः बहुत लंबे हैं। यदि आप इसे सही तरीके से कर रहे हैं तो अधिकांश या सभी विधि एक स्क्रीन ऊंचाई के भीतर फिट होनी चाहिए, और ढूँढें (F3) आपका मित्र है।

अब मेरे अलावा के लिए: इस के साथ एक समस्या है:

if (foo) bar();

एक ब्रेकपॉइंट सेट करने का प्रयास करें जो केवल हिट होगा यदि बार () चलने वाला है। आप कोड के दूसरे भाग में कर्सर रखकर C # में ऐसा कर सकते हैं, लेकिन यह स्पष्ट नहीं है और थोड़ा दर्द होता है। C ++ में आप ऐसा बिल्कुल नहीं कर सकते। C ++ कोड पर काम करने वाले हमारे सबसे वरिष्ठ डेवलपर्स में से एक को दो कारणों से 'if' स्टेटमेंट को तोड़ने पर जोर देता है। और मैं उससे सहमत हूं।

तो ऐसा करें:

if (foo)
{
    bar(); //It is easy to put a breakpoint here, and that is useful.
}
— स्कीपेक का पता चलता है
स्रोत
2
बार पर राइट क्लिक करें और इंसर्ट ब्रेकपॉइंट चुनें ... मुश्किल बिल्कुल नहीं। अपने औजारों को जानें।
— बॉब
संकेतक बार पर राइट क्लिक करने से कुछ नहीं होता है; क्या आपका मतलब है कि पाठ पर राइट क्लिक करें? वैसे भी, यदि आप चाहते हैं कि ब्रेक पॉइंट तभी हिट हो, जब "अगर" कथन सत्य है, और "बार ()" अपनी लाइन पर है, तो आप कर्सर को उस लाइन में कहीं भी रख सकते हैं और F9 दबा सकते हैं, या बाएँ क्लिक करें सूचक मार्जिन। यदि, हालांकि, सभी कोड एक ही लाइन पर हैं, तो आपको कर्सर को "बार ()" पर रखना होगा या F9 दबाने से पहले ठीक क्लिक करना होगा, और इंडिकेटर मार्जिन पर क्लिक करने से काम नहीं होगा (स्थानों को तोड़ने का स्थान) अगर')। यह "कठिन" नहीं है, लेकिन जब कोड दो लाइनों पर होता है तो उसे कम एकाग्रता की आवश्यकता होती है।
— पत्थर
ओह, हा हा, "बार" पर राइट क्लिक करें। आप पाठ का मतलब था। पकड़ लिया। ज़रूर, या सिर्फ F9 दबाएं ...
— पत्थर
>> आपको कर्सर को "बार ()" पर राइट करना होगा या F9 दबाने से पहले राइट क्लिक करना होगा, (मेरा मतलब है कि कर्सर को F9 या राइट क्लिक करने से पहले वहां रखें)
— Stone
7

बहुत सी जगह लेने से ब्रेसिज़ के साथ कोड रखने के लिए, मैं कोड कम्प्लीट बुक में सुझाई गई तकनीक का उपयोग करता हूँ :

if (...) {
    foo();
    bar();
}
else {
    ...
}
— नेथन प्रथार को प्रकट किया
स्रोत
मुझे पता नहीं क्यों इसे नीचे गिरा दिया गया था यह हर ब्रैकेट जोड़ी के लिए एक पंक्ति बचाता है मैं इसे हर समय उपयोग करता हूं
— एरिक
2
यह K & R शैली के रूप में अधिक लोकप्रिय है। कर्निघन और रिची द्वारा पुस्तक द सी प्रोग्रामिंग लैंग्वेज पर आधारित: en.wikipedia.org/wiki/The_C_Programming_Language_(book) । और यह आपको नीचे नहीं होना चाहिए।
— jmucchiello
धन्यवाद! मुझे लगा कि यह सिर्फ व्यक्तिगत स्वाद था। मुझे यह वाक्यविन्यास खुद को परेशान करने वाला लगता था, लेकिन मैंने इसे कोड कंप्लीट पढ़ने के बाद अपनाया, और अब वास्तव में इसका आनंद लेता हूं।
— नाथन प्रात:
मैं इस एक सोच के ऊपर सभी जवाब पढ़ रहा था "किसी ने अभी तक यह सुझाव क्यों नहीं दिया ???" यह समापन ब्रैकेट को उस ब्लॉक के साथ संरेखित करता है जो इसे बंद कर रहा है, वह है "अगर" या "जबकि", आदि, व्यर्थ "{" नहीं। +1।
— निकफ
यदि खुले ब्रेसिज़ को हमेशा खुद के द्वारा लाइनों पर रखा जाता है, तो ifएक एकल इंडेंटेड लाइन द्वारा पीछा किया जाता है , जिसे किसी भी ब्रेसिज़ की आवश्यकता के बिना एक बयान को नियंत्रित करने के रूप में नेत्रहीन मान्यता दी जा सकती है। ओपन-ब्रेस-बाय-स्टाइल इस प्रकार व्हॉट्सएप को उस स्थिति में बचाता है जहां एक ifस्टेटमेंट कुछ ऐसी चीज़ों को नियंत्रित करता है जो शब्दार्थ रूप से एक क्रिया है (केवल एक एकल चरण में होने वाले चरणों के अनुक्रम से अलग)। उदाहरण के लिए, if (someCondition)/ `नई SomeException (...) को फेंक दें।
— सुपरकैट
6

मान लीजिए कि आपके पास कुछ कोड हैं:

if (foo)
    bar();

और फिर कोई और साथ आता है और जोड़ता है:

if (foo)
    snafu();
    bar();

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

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

ब्रेसिंग छोड़ने के लिए लाइनों को कम करना वास्तव में एक अच्छा तर्क नहीं है। यदि आपकी विधि बहुत बड़ी है, तो इसे संभवतः छोटे टुकड़ों में या फिर से पुनर्गठित किया जाना चाहिए। ऐसा करने से कोई संदेह नहीं होगा कि केवल ब्रेसिज़ निकालने से अधिक पठनीयता बढ़ जाएगी।

— इमारत का बंद
स्रोत
5

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

यदि आप कई घोंसले के शिकार करना शुरू करते हैं, तो यह आसान है कि यदि आप कई घोंसले बनाना शुरू करते हैं, अगर / और इसी तरह, लेकिन मुझे लगता है कि अधिकांश प्रोग्रामर को यह बताने में सक्षम होना चाहिए कि रेखा कहां खींचनी चाहिए।

मैं इसे if ( foo == 0 )बनाम के तर्क की तरह देखता हूं if ( 0 == foo )। उत्तरार्द्ध नए प्रोग्रामर के लिए बग्स को रोक सकता है (और शायद कभी-कभी दिग्गजों के लिए भी), जबकि पूर्व को कोड को बनाए रखने के दौरान जल्दी से पढ़ना और समझना आसान होता है।

— मार्क चारबोन्यू
स्रोत
4

ज्यादातर बार यह एक कोडिंग मानक के रूप में निगला जाता है, चाहे वह किसी कंपनी या FOSS प्रोजेक्ट के लिए हो।

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

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

— joshperry
स्रोत
अजगर के बारे में टिप्पणी के लिए +1। मुझे हमेशा आश्चर्य होता है कि भाषाओं के बीच लगातार स्विच करने पर मैं "बेवकूफ" कैसे हो सकता हूं।
— केना डे
3

अधिक सुरक्षित के किनारे पर - बस एक और बग आपको संभावित रूप से ठीक नहीं करना होगा।

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

यदि मेरे पास एक-लाइनर है, तो मैं आमतौर पर इसे निम्नानुसार प्रारूपित करता हूं:

if( some_condition ) { do_some_operation; }

यदि रेखा बहुत बोझिल है तो निम्नलिखित का उपयोग करें:

if( some_condition )
{
    do_some_operation;
}
— जॉर्डन Parmer
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.