दिलचस्प पोस्ट
कंसोल.लॉग को प्रत्येक फ़ंक्शन पर स्वचालित रूप से जोड़ना जब कोई टैब क्रोम में निष्क्रिय होता है तो मैं सेट इन्टरवॉल भी कैसे काम कर सकता हूं? "पूर्णांक आकार = 10" क्या एक निरंतर अभिव्यक्ति उत्पन्न होती है? 'यदि' में 'चयन' कथन – स्तंभ मूल्यों के आधार पर आउटपुट मान चुनें जब फ्लेक्सबॉक्स आइटम कॉलम मोड में लपेटते हैं, कंटेनर इसकी चौड़ाई नहीं बढ़ता जावास्क्रिप्ट लिंक, "#" या "जावास्क्रिप्ट: शून्य (0)" के लिए कौन सी "href" मान का उपयोग करना चाहिए? कोड के एक पाइप ब्लॉक के अंदर क्यों विलंब का विस्तार विफल हो जाता है? मैं जावा में स्विंगवॉकर का उपयोग कैसे करूं? SQLite पैरामीटर प्रतिस्थापन समस्या बंद वर्कबुक से मूल्य प्राप्त करने के लिए ExecuteExcel4Macro मैं एंड्रॉइड में स्क्रीन साइज़ प्रोग्राम को कैसे प्राप्त करूं? MySQL पर निष्पादित अंतिम क्वेरी कैसे दिखाएं? जावा में, निजी, सार्वजनिक, सुरक्षित और निजी पैकेज के बीच अंतर .live () बनाम .बिंद () -didSelectRowAtIndexPath: नहीं बुलाया जा रहा है

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

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

if (foo) Bar(); //or for(int i = 0 i < count; i++) Bar(i); 

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

 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. क्या कोई अन्य तर्क है कि मुझे याद आ रही है?

वेब के समाधान से एकत्रित समाधान "घुंघराले ब्रेसिज़ को छोड़ने के लिए इसे खराब अभ्यास क्यों माना जाता है?"

दरअसल, एकमात्र समय है जो कभी सचमुच मुझे थोड़ा सा था जब मैं डिबगिंग कर रहा था, और बार () की टिप्पणी की थी:

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

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

 if(foo) bar(); 

जो उपरोक्त मामले की देखभाल करता है

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

पढ़ने की गति …

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

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

मैंने पढ़ा की तुलना में थोड़ा तेज:

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

मैं इसे थोड़ा धीमा पढ़ा अगर ऐसा लगता है:

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

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

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

बीजेपी मैं मदद नहीं कर सकता लेकिन इसे फिर से सिर्फ मामले में और आश्चर्य है कि अगर लेखक का इरादा है:

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

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

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

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

 if(foo()) bar(); 

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

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

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

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

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

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

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

 if (condition) action(); // ok by me if (condition) // normal/standard for me { action(); } 

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

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

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

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

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

(सी) अगर कुछ गलत हो जाता है तो डीबग करना आसान है

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

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

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

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

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

 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 } 

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

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

 #define BADLY_MADE_MACRO(x) function1(x); function2(x); if (myCondition) BADLY_MADE_MACRO(myValue) 

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

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

एक दिन तक (हमेशा ऐसा क्यों होता है कि "एक दिन" जो आपकी ज़िंदगी हमेशा के लिए बदलता है?) हम 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 एमबी के लॉग्स पैदा कर रही थी और हमें इसे रोकने के लिए कहा गया। डिबग फ्लैग पर्याप्त नहीं था, इसलिए खोज और प्रतिस्थापित किया गया था, क्रम में।

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

संपादित करें

अब केवल एक ऐसी जगह है जहां मैं ब्रेसिज़ का उपयोग नहीं करता / रही है अगर / कोशिश

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

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

मैं बहुत खुश हूँ:

 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(); } 

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

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

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

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

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

योएल ने यह भी गलत कोड बनाने में उल्लिखित किया था गलत देखो

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

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

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

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

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

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

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

 if(x == y) for(/* loop */) { //200 lines } //rampion's example: for(/* loop */) { for(/* loop */) for(/* loop */) { //several lines } } 

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

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

मैंने देखा है

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

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

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

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

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

तथा:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 if (foo) bar(); 

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

ऐसा करें:

 if (foo) { bar(); //It is easy to put a breakpoint here, and that is useful. } 

One of the main issues is when you have regions of one-liners and non-one liners, along with separation from the control statment ( for , if , what have you) and the end of the statment.

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

 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 } 

I used to be a huge supporter of "curly braces are a MUST!", but since adopting unit testing, I find that my unit tests protect braceless statements from the scenarios like:

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

With good unit tests, I can confidently omit curly braces for simple statements to improve readability (yes, that can be subjective).

Alternatively, for something like the above, I would likely inline that to look like:

 if (foo) snafu(); 

That way, the developer who needs to add bar() to the condition, would be more apt to recognize the lack of curly braces, and add them.

I'm a strong believer in writing tidy and concise code, but I would always use curly braces. I find that they are a convenient way of quickly seeing the scope in which a particular line of code exists. There is no ambiguity, it's just explicitly set out in front of you.

Some may say it is a case of preference, but I find the logical flow of a program much easier to follow if it is internally consistent, and I don't believe that it is consistent to write one IF statement like this;

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

And another like this;

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

I prefer to just pick one general style and stick with it 🙂

Use some personal judgement.

 if (foo) bar(); 

is fine by itself. Unless you're really worried about morons putting in something like this later:

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

If you're not worried about morons, you're fine (I'm not — if they can't get basic code syntax right, this is the least of their problems)>

In exchange, it's a lot more readable.

The rest of the time:

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

Which has been my favorite as long as I can remember. Additionally:

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

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

Vertical space by itself isn't terribly relevant, readability is. The opening brace on a line by itself just stops the conversation for a syntactic element, until your eye moves down to the next line. Not what I like.

Let's say you have some code:

 if (foo) bar(); 

and then someone else comes along and adds:

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

According to the way it's written, bar(); is now executed unconditionally. By including the curly braces, you prevent this kind of accidental error. Code should be written in such a way as to make such mistakes difficult or impossible to make. If I was doing a code review and saw the missing braces, especially spread across multiple lines, I would create a defect. In cases where it is justified, keep it on one line so that the chance of making such an error is again kept to a minimum.

Reducing lines is not really a good argument for dropping braces. If your method is too big, it should probably be refactored into smaller pieces or restructured. Doing that will no doubt increase readability more than simply taking out braces.

I always omit them when appropriate, such as in your first example. Clean, concise code I can see and understand by glancing at is easier to maintain, debug and understand than code I have to scroll through and read line by line. I think most programmers will agree with this.

It is easy for it to get out of hand if you start doing multiple nesting, if/else clauses and so on, but I think most programmers should be able to tell where to draw the line.

I see it kind of like the argument for if ( foo == 0 ) vs if ( 0 == foo ) . The latter may prevent bugs for new programmers (and maybe even occasionally for veterans), while the former is easier to quickly read and understand when you're maintaining code.

in order to keep the code with braces from taking up lots of space, I use the technique recommended in the book Code Complete :

 if (...) { foo(); bar(); } else { ... } 

Most times it is ingrained as a coding standard, whether for a company or an FOSS project.

Ultimately someone else will need to grok your code and it is a major time drain for each developer to have to figure out the specific style of the section of code they are working on.

Also, imagine that someone is going between Python and a Cish language more than once a day… In Python indenting is part of the block symantics of the language and it would be quite easy to make a mistake like the one you quote.

Err on the side of more secure – just one more bug you potentially won't have to fix.

I personally feel more secure if all of my blocks are wrapped in curlys. Even for one-liners, these are simple notations that easily prevent mistakes. It makes the code more readable in the sense that you clearly see what is in the block as not to confuse the body of the block with the following statements outside of the block.

If I have a one-liner, I typically format it as follows:

 if( some_condition ) { do_some_operation; } 

If the line is just too cumbersome then use the following:

 if( some_condition ) { do_some_operation; }