यदि एक या लाइन के लिए लूप (यानी {}) का उपयोग करने का उद्देश्य क्या है?

321

मैं अपने C ++ लेक्चरर के कुछ व्याख्यान नोट्स पढ़ रहा हूं और उन्होंने निम्नलिखित लिखा है:

  1. इंडेंटेशन // ओके का प्रयोग करें
  2. ऑपरेटर की पूर्वता पर कभी भी भरोसा न करें - हमेशा कोष्ठक का उपयोग करें // ठीक है
  3. हमेशा एक {} ब्लॉक का उपयोग करें - यहां तक ​​कि एक भी लाइन के लिए // ठीक नहीं , क्यों ???
  4. तुलना के बाईं ओर कास्ट ऑब्जेक्ट / ओके
  5. उन चर के लिए अहस्ताक्षरित का उपयोग करें जो> = 0 // अच्छी चाल हैं
  6. हटाने के बाद NULL को पॉइंटर सेट करें - डबल डिलीट प्रोटेक्शन // खराब नहीं

तीसरी तकनीक मेरे लिए स्पष्ट नहीं है: एक लाइन को एक में रखकर मुझे क्या लाभ होगा { ... }?

उदाहरण के लिए, यह अजीब कोड लें:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

और इसे बदलें: 

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

1 संस्करण का उपयोग करने का क्या लाभ है?

c++  c  coding-style  curly-braces  defensive-programming 
— जन
स्रोत
256
पठनीयता और स्थिरता। यह तुरंत स्पष्ट नहीं है कि 'j ++' किस स्टेटमेंट के अंतर्गत आता है, और यह कि अगर वह स्टेटमेंट से संबद्ध नहीं होगा, तो कोड जोड़ना।
— वन और पेड़ 8
27
मुझे हमेशा कुछ कारणों के लिए इन पंक्तियों के लिए घुंघराले ब्रेसिज़ {} का उपयोग करने के लिए कहा गया था। यह पढ़ने के लिए कोड को स्पष्ट करता है। इसके अलावा छह महीने के समय में किसी और को आपके कोड को संपादित करने की आवश्यकता हो सकती है इसलिए स्पष्टता महत्वपूर्ण है और ब्रेसिज़ के साथ एक त्रुटि होने की संभावना कम है। वहाँ इसके बारे में अधिक सही ढंग से कुछ भी नहीं है, यह अधिक अच्छा व्यवहार की बात है। ध्यान रखें कि एक परियोजना में कुछ नए आदमी के माध्यम से हजारों और हजारों लाइनें हो सकती हैं!
— रॉसक
30
मैं 6 से सहमत नहीं हूं, क्योंकि यह एक डबल विलोपन और संभावित रूप से तर्क त्रुटियों को छिपाएगा।
— लुचियन ग्रिगोर
28
# 5 मुश्किल हो सकता है - इस पाश पर विचार करें for (unsigned i = 100; i >= 0; --i):।
— आर्ची
36
Btw, (i % 2 == 0)विरोधाभास (2)। आप ऑपरेटर पूर्वता पर भरोसा कर रहे हैं, और इसका अर्थ ((i % 2) == 0)इसके बजाय निश्चित रूप से है (i % (2 == 0))। मैं नियम 2 को "एक मान्य भावना के रूप में वर्गीकृत करूंगा लेकिन 'हमेशा गलत है"।
— स्टीव जेसप 10

जवाबों:

509

iजब हम वृद्धि करते हैं तो संशोधित करने का प्रयास करते हैं j:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

अरे नहीं! पायथन से आ रहा है, यह ठीक लग रहा है, लेकिन वास्तव में यह नहीं है, क्योंकि यह इसके बराबर है:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

बेशक, यह एक मूर्खतापूर्ण गलती है, लेकिन एक जिसे एक अनुभवी प्रोग्रामर भी बना सकता है।

एक और बहुत अच्छा कारण ta.speot.is के जवाब में बताया गया है ।

एक तीसरा जो मैं सोच सकता हूं कि यह नेस्टेड है if:

if (cond1)
   if (cond2) 
      doSomething();

अब, मान लें कि आप doSomethingElse()कब cond1नहीं मिलना चाहते हैं (नई सुविधा)। इसलिए:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

जो स्पष्ट रूप से गलत है, क्योंकि elseआंतरिक के साथ सहयोगी if।

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

1 संस्करण का उपयोग करने का क्या लाभ है?

जिसका मैंने वर्णन किया है। कुछ फायदे हैं। लेकिन, IMO, "हमेशा" नियम हमेशा लागू नहीं होते हैं। इसलिए मैं पूरी तरह से समर्थन नहीं करता

हमेशा एक {} ब्लॉक का उपयोग करें - यहां तक ​​कि एक भी लाइन के लिए // ठीक नहीं, क्यों ???

मैं यह नहीं कह रहा हूं कि हमेशा एक {}ब्लॉक का उपयोग करें । यदि यह एक सरल पर्याप्त स्थिति और व्यवहार है, तो नहीं। यदि आपको संदेह है कि कोई व्यक्ति बाद में आ सकता है और कार्यक्षमता जोड़ने के लिए अपना कोड बदल सकता है, तो करें।

— लुचियन ग्रिगोर
स्रोत
5
@Science_Fiction: सच है, लेकिन अगर आप i++ पहले जोड़ते हैं j++, तो दोनों चर अभी भी गुंजाइश में होंगे जब उनका उपयोग किया जाएगा।
— माइक सेमोर
26
यह बहुत ही उचित लगता है, लेकिन इस तथ्य की उपेक्षा करता है कि संपादक इंडेंटेशन करता है, आप नहीं, और यह इस तरह से इंडेंट करेगा i++;जो तुरंत दिखाता है कि यह लूप का हिस्सा नहीं है। (अतीत में, यह एक उचित तर्क हो सकता है, और मैंने इस तरह की समस्याओं को देखा है। लगभग 20 साल पहले। तब से नहीं।)
— जेम्स कान्जे
43
@ नाम: यह एक "तथ्य" नहीं है, हालांकि, यह आपके वर्कफ़्लो है। और बहुत सारे लोगों के वर्कफ़्लो, लेकिन सभी के नहीं। मैं यह नहीं लगता कि जरूरी बजाय एक WYSIWYG संपादक (vi / Emacs / दृश्य स्टूडियो) कि लागू करता है फ़ॉर्मेटिंग नियम के उत्पादन में इलाज सेल्सियस के लिए एक त्रुटि ++ एक सादा पाठ फ़ाइल के रूप में स्रोत,। तो यह नियम आपकी जरूरत के अलावा संपादक-अज्ञेयवादी है, लेकिन इससे परे नहीं कि लोग वास्तव में C ++ को संपादित करने के लिए क्या उपयोग करते हैं। 4. "रक्षात्मक"।
— स्टीव जेसोप
31
@JamesKanze क्या आप वास्तव में इस धारणा पर भरोसा कर रहे हैं कि हर कोई हमेशा शक्तिशाली आईडीई में काम करता है? आखिरी सीआई लिखा नैनो में था। यहां तक ​​कि यह भी कि, पहली चीज जो मैं एक IDE में बंद करता हूं, वह है ऑटो-इंडेंटेशन - क्योंकि IDE मेरे गैर-रेखीय वर्कफ़्लो के रास्ते में आ जाता है, अधूरी जानकारी के आधार पर मेरी 'गलतियों' को ठीक करने की कोशिश करता है। । IDE हर प्रोग्रामर के प्राकृतिक प्रवाह को ऑटो-इंडेंट करने में बहुत अच्छे नहीं हैं। ऐसे प्रोग्रामर जो इस तरह की सुविधाओं का उपयोग करते हैं, वे अपनी शैली को अपनी IDE में मर्ज करते हैं, जो कि ठीक है यदि आप केवल एक IDE का उपयोग करते हैं, लेकिन यदि आप कई काम करते हैं तो notsomuch।
— रशियो
10
"यह एक मूर्खतापूर्ण गलती है, लेकिन एक जिसे एक अनुभवी प्रोग्रामर भी बना सकता है।" - जैसे मैंने अपने जवाब में कहा, मुझे विश्वास नहीं होता। मुझे लगता है कि यह एक पूरी तरह से वंचित मामला है जो वास्तविकता में कोई समस्या पैदा नहीं करता है।
— कोनराड रुडोल्फ
324

यह टिप्पणी करता है, तो आप का उपयोग नहीं करते के साथ गलती से परिवर्तन नियंत्रण प्रवाह करने के लिए बहुत आसान है {और }। उदाहरण के लिए:

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

यदि आप do_something_else()एकल पंक्ति टिप्पणी करते हैं, तो आप इसे समाप्त करेंगे:

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

यह संकलन करता है, लेकिन must_always_do_this()हमेशा बुलाया नहीं जाता है।

हमारे पास हमारे कोड बेस में यह मुद्दा था, जहां कोई रिलीज से पहले बहुत तेज़ी से कुछ कार्यक्षमता अक्षम करने के लिए गया था। सौभाग्य से हमने इसे कोड समीक्षा में पकड़ लिया।

— ta.speot.is
स्रोत
3
ओह बॉय !! यह परिभाषित व्यवहार है जो must_always_do_this();अगर आप टिप्पणी करते हैं तो निष्पादित होगा // do_something_else ();
— Mr.Anubis 10
1
@ Supr, जैसा कि पहले लिखा गया था, वह कह रहा है कि यदि आप ब्रेसिज़ का उपयोग करते हैं, तो सही प्रवाह को तोड़ना मुश्किल है, और फिर एक उदाहरण देता है कि कोड को ठीक से ब्रेक किए बिना कितना आसान है
— SeanC
20
मैं दूसरे दिन ही इसमें भाग गया। if(debug) \n //print(info);। मूल रूप से एक पूरी लाइब्रेरी निकाल ली।
— केविन
4
Fortunately we caught it in code review.आउच! इतना गलत लगता है। Fortunately we caught it in unit tests.ज्यादा बेहतर होगा!
— बिग
4
@ B @овиЈ लेकिन क्या होगा अगर कोड एक यूनिट टेस्ट में था? मन चकरा जाता है। (बस मजाक कर रहे हैं, यह एक विरासत ऐप है। कोई इकाई परीक्षण नहीं हैं।)
— ta.speot.is
59

मुझे लेक्चरर की काबिलियत पर संदेह है। उनकी बातों को ध्यान में रखते हुए:

  1. ठीक
  2. क्या कोई वास्तव में लिखेगा (या पढ़ना चाहता है) (b*b) - ((4*a)*c) ? कुछ मिसालें स्पष्ट हैं (या होनी चाहिए), और अतिरिक्त कोष्ठक सिर्फ भ्रम में जोड़ते हैं। (दूसरी ओर, आप _should_ कम स्पष्ट मामलों में कोष्ठक का उपयोग करते हैं, भले ही आपको पता हो कि उनकी आवश्यकता नहीं है।)
  3. की तरह। सशर्त और छोरों को प्रारूपित करने के लिए दो व्यापक प्रसार सम्मेलन हैं: 
    अगर (cond) {
    कोड;
}
    तथा: 
    अगर (कोंड)
{
    कोड;
}
    पहले में, मैं उससे सहमत था। उद्घाटन {ऐसा दिखाई नहीं दे रहा है, इसलिए यह मान लेना सबसे अच्छा है कि यह हमेशा रहता है। दूसरे में, हालांकि, मैंने (और अधिकांश लोगों ने मेरे साथ काम किया है) को एक बयान के लिए ब्रेसिज़ को छोड़ने के साथ कोई समस्या नहीं है। (बशर्ते, कि इंडेंटेशन व्यवस्थित है और आप इस शैली का लगातार उपयोग करते हैं। (बहुत अच्छे प्रोग्रामर, बहुत पठनीय कोड लिख रहे हैं, पहले तरीके को फॉर्मेट करते समय भी ब्रेसिज़ को छोड़ देते हैं।)
  4. सं । if ( NULL == ptr )पठनीयता में बाधा डालने के लिए जैसी चीजें बदसूरत हैं। सहजता से तुलना लिखिए। (जो कई मामलों में सही पर निरंतर होता है।) उनकी 4 बुरी सलाह है; कुछ भी जो कोड को अप्राकृतिक बनाता है वह इसे कम पठनीय बनाता है।
  5. सं । कुछ भी हो लेकिन intविशेष मामलों के लिए आरक्षित है। अनुभवी सी और सी ++ प्रोग्रामर के लिए, unsignedसिग्नल बिट ऑपरेटरों का उपयोग । C ++ में एक वास्तविक कार्डिनल प्रकार (या कोई अन्य प्रभावी उपप्रकार प्रकार) नहीं है; unsignedप्रचार नियमों के कारण, संख्यात्मक मानों के लिए काम नहीं करता है। संख्यात्मक मान, जिस पर कोई अंकगणितीय संक्रियाएं समझ में नहीं आतीं, जैसे सीरियल नंबर, संभवतः हो सकते हैं unsigned। हालांकि, मैं इसके खिलाफ तर्क दूंगा, क्योंकि यह गलत संदेश भेजता है: बिटवाइज़ ऑपरेशंस का कोई मतलब नहीं है। मूल नियम यह है कि अभिन्न प्रकार हैं int, _unless_ दूसरे प्रकार का उपयोग करने का एक महत्वपूर्ण कारण है।
  6. सं । ऐसा करना व्यवस्थित रूप से भ्रामक है, और वास्तव में किसी भी चीज़ से रक्षा नहीं करता है। सख्त OO कोड में, delete this;अक्सर सबसे लगातार मामले (और आप सेट नहीं कर सकता है thisके लिए NULL), और नहीं तो, सबसे deleteताकि आप बाद में वैसे भी सूचक उपयोग नहीं कर सकते, विनाशकर्ता में हैं। और यह NULLकिसी भी अन्य संकेत के आसपास कुछ भी नहीं करने के लिए इसे स्थापित करने के आसपास चल रहा है। NULLसुरक्षा की झूठी भावना देने के लिए सूचक को व्यवस्थित रूप से सेट करना , और वास्तव में आपको कुछ भी खरीदना नहीं है।

किसी भी विशिष्ट संदर्भ में कोड को देखें। Stroustrup आपके द्वारा दिए गए प्रत्येक नियम का उल्लंघन करता है, उदाहरण के लिए।

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

— जेम्स कंज
स्रोत
13
संख्या 4 बदसूरत हो सकती है लेकिन इसके लिए एक उद्देश्य है। यह रोकने की कोशिश कर रहा है अगर (ptr = NULL)। मुझे नहीं लगता कि मैंने कभी उपयोग किया है delete this, क्या मैंने देखा है यह अधिक सामान्य है? मुझे लगता है कि उपयोग करने के बाद NULL के लिए एक पॉइंटर सेट करने की सोच नहीं है, लेकिन YMMV करने के लिए एक चीज़ का बुरा है। हो सकता है कि यह सिर्फ मैं ही हूं, लेकिन उनके ज्यादातर दिशा-निर्देश मुझे बुरे नहीं लगते।
— फेयरड्रैगन
16
@ वायर्ड्रगन: अधिकांश कंपाइलर इस बारे में चेतावनी देंगे if (ptr = NULL)जब तक कि आप इसे नहीं लिखते if ((ptr = NULL))। जेम्स कंज़ से सहमत होना होगा कि NULLपहले होने की कुरूपता मेरे लिए एक निश्चित सं।
— सिंह
34
@JamesKanze: मुझे यह कहना होगा कि मैंने यहाँ जो कुछ भी कहा है, उससे मैं असहमत हूँ - हालाँकि मैं उनकी सराहना करता हूँ और उन तक पहुँचने के लिए आपके तर्कों का सम्मान करता हूँ। अनुभवी सी और सी ++ प्रोग्रामर के लिए, अहस्ताक्षरित सिग्नल बिट ऑपरेटरों का उपयोग। - मैं बिल्कुल सहमत नहीं हूं: बिट ऑपरेटरों का उपयोग बिट ऑपरेटरों के उपयोग का संकेत देता है। मेरे लिए, प्रोग्रामर की ओर से unsignedएक आकांक्षा का उपयोग इंगित करता है कि चर को केवल सकारात्मक संख्याओं का प्रतिनिधित्व करना चाहिए। हस्ताक्षरित संख्याओं के साथ मिश्रण आमतौर पर एक संकलक चेतावनी का कारण होगा जो संभवतः व्याख्याता का इरादा था।
— घटक 10
18
अनुभवी C और C ++ प्रोग्रामर के लिए, अहस्ताक्षरित सिग्नल बिट ऑपरेटरों का उपयोग या नहीं। size_t, किसी को?
— ta.speot.is
16
@ जेम्स कंज, उद्देश्य पर विचार करें। आप एक अनुभवी प्रोग्रामर द्वारा निर्मित कोड की तुलना अनुदेशात्मक उदाहरणों से कर रहे हैं। ये नियम व्याख्याता द्वारा प्रदान किए जाते हैं क्योंकि वे अपने छात्रों द्वारा की जाने वाली गलतियों के प्रकार हैं। अनुभव के साथ, छात्र इन निरपेक्षताओं को आराम या अवहेलना कर सकते हैं।
— जोशुआ शेन लिबरमैन
46

अन्य सभी उत्तर आपके व्याख्याता के नियम 3 का बचाव करते हैं।

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

"घटक 10" का जवाब वास्तव में एकमात्र अनुमान योग्य मामले को उजागर करता है जहां यह वास्तव में त्रुटि पैदा कर सकता है। लेकिन दूसरी ओर, नियमित अभिव्यक्ति के माध्यम से कोड की जगह हमेशा किसी भी तरह से भारी देखभाल का वारंट करती है।

अब आइए पदक के दूसरे पक्ष को देखें: क्या हमेशा घुंघराले कोष्ठक का उपयोग करने का नुकसान है? अन्य उत्तर बस इस बिंदु को अनदेखा करते हैं। लेकिन वहाँ है एक नुकसान: यह ऊर्ध्वाधर स्क्रीन स्थान का एक बहुत लेता है, और यह बदले में अपने कोड अपठनीय हो सकता है क्योंकि यह मतलब है कि आप आवश्यकता से अधिक स्क्रॉल करना पड़ता है।

शुरुआत में बहुत सारे गार्ड क्लॉस के साथ एक फ़ंक्शन पर विचार करें (और हाँ, निम्नलिखित खराब C ++ कोड है लेकिन अन्य भाषाओं में यह काफी सामान्य स्थिति होगी):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

यह भयानक कोड है, और मैं दृढ़ता से तर्क देता हूं कि निम्नलिखित बहुत अधिक पठनीय है:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

इसी तरह, छोटे नेस्टेड छोरों को घुंघराले कोष्ठक को छोड़ने से लाभ होता है:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

तुलना करना:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

पहला कोड संक्षिप्त है; दूसरा कोड फूला हुआ है।

और हां, पिछली लाइन पर शुरुआती ब्रेस लगाकर इसे कुछ हद तक कम किया जा सकता है । लेकिन वह फिर भी बिना किसी कर्ली कोष्ठक के कोड से कम पठनीय होगा ।

संक्षेप में: अनावश्यक कोड न लिखें जो स्क्रीन स्पेस लेता है।

— कोनराड रुडोल्फ
स्रोत
26
यदि आप अनावश्यक रूप से स्क्रीन स्पेस लेने वाले कोड लिखने में विश्वास नहीं करते हैं, तो आपके पास अपनी लाइन पर शुरुआती ब्रेस लगाने का कोई व्यवसाय नहीं है । मैं शायद अब GNU के पवित्र प्रतिशोध से बतख और दौड़ने जा रहा हूं, लेकिन गंभीरता से - या तो आप चाहते हैं कि आपका कोड लंबवत कॉम्पैक्ट हो, या आप नहीं। और यदि आप करते हैं, तो अपने कोड को कम से कम कॉम्पैक्ट बनाने के लिए पूरी तरह से डिज़ाइन किए गए काम न करें। लेकिन जैसा कि आप कहते हैं, यह तय है कि, आप अभी भी निरर्थक ब्रेसिज़ को हटाना चाहते हैं। या शायद सिर्फ if (a == nullptr) { throw null_ptr_error("a"); }एक पंक्ति के रूप में लिखें ।
— स्टीव जेसोप
6
@Steve तथ्य की बात के रूप में, मैं है पिछले लाइन पर उद्घाटन ब्रेस शब्दों में कहें, बहुत कारण है कि आप ने कहा के लिए। मैंने अन्य शैली का उपयोग यहां किया ताकि यह स्पष्ट हो सके कि अंतर कितना चरम हो सकता है।
— कोनराड रुडोल्फ
9
+1 मैं पूरी तरह से सहमत हूं कि आपका पहला उदाहरण ब्रेसिज़ के बिना पढ़ना बहुत आसान है। दूसरे उदाहरण में, मेरी व्यक्तिगत कोडिंग शैली बाहरी फॉर-लूप पर ब्रेसिज़ का उपयोग करना है और आंतरिक पर नहीं। मैं @SteveJessop के बारे में असहमत हूं कि वह एक अतिवादी है या दूसरा लंबवत कॉम्पैक्ट कोड के बारे में। मैं ऊर्ध्वाधर स्थान को कम करने के लिए एक-लाइनर्स के साथ अतिरिक्त ब्रेसिज़ को छोड़ देता हूं, लेकिन मैं अपनी शुरुआती ब्रेसिज़ को एक नई लाइन पर नहीं डालता हूं क्योंकि मुझे गुंजाइश देखने में आसानी होती है जब ब्रेसिज़ लाइन में खड़े होते हैं। लक्ष्य पठनीयता है, और कभी-कभी इसका मतलब है कि अधिक ऊर्ध्वाधर स्थान का उपयोग करना, अन्य बार इसका मतलब कम उपयोग करना है।
— Travesty3
22
"मैंने वास्तविक जीवन में इस समस्या का सामना कभी नहीं किया है": भाग्यशाली आप। इस तरह की चीजें सिर्फ आपको जलाती नहीं हैं, वे आपको 90% थर्ड डिग्री बर्न देती हैं (और यह प्रबंधन की कुछ परतें हैं जो देर शाम को ठीक करने की मांग करती हैं)।
— रिचर्ड
9
@ रिचर्ड मैं बस खरीद नहीं है। जैसा कि मैंने चैट में समझाया है, भले ही यह त्रुटि कभी भी हो (जो मुझे असंभव लगती है) यह ठीक करने के लिए तुच्छ है एक बार जब आप स्टैक ट्रेस को देखते हैं क्योंकि यह स्पष्ट है कि त्रुटि कोड को देखकर कहां है। आपका अतिरंजित दावा पूरी तरह से निराधार है।
— कोनराड रुडोल्फ
40

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

सबसे अधिक समस्याग्रस्त उदाहरण मुझे मिला है, यह है:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

इसलिए जब मैं साथ आता हूं और एक तत्कालीन कथन जोड़ना चाहता हूं, तो मैं आसानी से इसे समाप्त कर सकता हूं यदि मैं सावधान नहीं हूं:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

यह देखते हुए कि ब्रेसिज़ को जोड़ने के लिए ~ 1 सेकंड का समय लगता है और कम से कम कुछ मिनटों के डिबगिंग में आपको बचा सकता है, आप कभी भी कम अस्पष्टता विकल्प के साथ क्यों नहीं जाएंगे? मेरे लिए झूठी अर्थव्यवस्था की तरह लगता है।

— जाम
स्रोत
16
क्या इस उदाहरण में समस्या बाउंड्री के बजाय अनुचित इंडेंटेशन और बहुत लंबी लाइनों में नहीं है?
— होन्ज़ा ब्रेबेक
7
हां, लेकिन निम्नलिखित डिजाइन / कोडिंग दिशानिर्देश जो केवल 'सुरक्षित' हैं, यह मानते हुए कि लोग अन्य दिशानिर्देशों का भी पालन कर रहे हैं (जैसे कि बहुत लंबी लाइनें न होना) परेशानी के लिए पूछ रहे हैं। यदि ब्रेसिज़ शुरू से था, तो इस स्थिति में एक गलत इफ़-ब्लॉक के साथ समाप्त करना असंभव होगा।
— जाम
16
ब्रेसिज़ को कैसे जोड़ा जाएगा ( if(really long...editor){ do_foo;}इस मामले से बचने में आपकी मदद करना? समस्या की तरह अभी भी वही होगा। व्यक्तिगत रूप से मैं आवश्यक नहीं होने पर ब्रेसिज़ से बचना पसंद करता हूं, हालांकि उन्हें लिखने के लिए आवश्यक समय के साथ कुछ नहीं करना है लेकिन कम पठनीयता कोड में दो अतिरिक्त लाइनों के कारण।
— ग्रिजली
1
अच्छी बात - मैं यह मान रहा था कि ब्रेसिज़ का उपयोग करने के परिणामस्वरूप उन्हें एक समझदार जगह पर रखा जाएगा, लेकिन निश्चित रूप से किसी ने चीजों को मुश्किल बनाने के लिए निर्धारित किया है जो उन्हें आपके उदाहरण के रूप में इन-लाइन डाल सकता है। मुझे लगता है कि ज्यादातर लोग, हालांकि नहीं होगा।
— जाम
2
फ़ाइल को स्पर्श करते समय पहली और आखिरी बात मैं ऑटो-फॉर्मेट बटन से टकराती हूँ। यह इनमें से अधिकांश मुद्दों को समाप्त करता है।
— जोनाथन एलन
20

मेरा 2 सी:

इंडेंटेशन का उपयोग करें

जाहिर है

ऑपरेटर की पूर्वता पर कभी भी भरोसा न करें - हमेशा कोष्ठक का उपयोग करें

मैं "कभी नहीं और" हमेशा "शब्दों का उपयोग नहीं करूंगा, लेकिन सामान्य तौर पर मैं इस नियम को उपयोगी देखता हूं। कुछ भाषाओं में (लिस्प, स्मॉलटाक) यह एक गैर-मुद्दा है।

हमेशा {} ब्लॉक का उपयोग करें - यहां तक ​​कि एक पंक्ति के लिए भी

मैं ऐसा कभी नहीं करता और कभी भी एक ही समस्या नहीं थी, लेकिन मैं यह देख सकता हूं कि यह छात्रों के लिए कैसे अच्छा हो सकता है। यदि वे पहले पायथन का अध्ययन करते थे।

तुलना के बाईं ओर कास्ट ऑब्जेक्ट

योदा की स्थिति? कृपया नहीं। इससे पठनीयता को ठेस पहुंचती है। जब आप अपना कोड संकलित करते हैं तो अधिकतम चेतावनी स्तर का उपयोग करें।

उन चर के लिए अहस्ताक्षरित का उपयोग करें जो> = 0 हैं

ठीक। काफी मज़ेदार, मैंने स्ट्रॉस्ट्रुप की असहमतियों को सुना है।

हटाने के बाद NULL को पॉइंटर सेट करें - डबल डिलीट प्रोटेक्शन

बुरी सलाह! कभी भी एक पॉइंटर नहीं होता है जो एक हटाई गई या गैर-मौजूदा वस्तु की ओर इशारा करता है।

— निमंजा ट्रिफ़ुनोविक
स्रोत
5
+1 केवल अंतिम बिंदु के लिए। एक कच्चे पॉइंटर की वैसे भी कोई व्यवसायिक स्मृति नहीं होती है।
— कोनराड रुडोल्फ
2
अहस्ताक्षरित का उपयोग करने के संबंध में: न केवल स्ट्रॉस्ट्रुप, बल्कि के एंड आर (सी में), हर्ब सटर और (मुझे लगता है) स्कॉट मेयर्स। वास्तव में, मैंने किसी को भी कभी नहीं सुना है जो अहस्ताक्षरित का उपयोग करने के लिए सी ++ के नियमों को वास्तव में समझता है।
— बजे जेम्स कान्जे
2
@JamesKanze वास्तव में, उसी अवसर पर मैंने स्ट्रॉस्ट्रुप की राय (2008 में बोस्टन सम्मेलन) सुनी, हर्ब सटर वहां था और मौके पर बज़्ने से असहमत था।
— Nemanja Trifunovic
3
बस " unsignedटूट गया है" को पूरा करने के लिए , समस्याओं में से एक यह है कि जब C ++ समान आकार के हस्ताक्षरित और अहस्ताक्षरित प्रकारों की तुलना करता है, तो यह तुलना करने से पहले अहस्ताक्षरित को धर्मान्तरित करता है । जिसके परिणामस्वरूप मूल्य में परिवर्तन होता है। हस्ताक्षर करने के लिए परिवर्तित करना बहुत बेहतर नहीं होगा; तुलना वास्तव में होनी चाहिए "जैसे कि" दोनों मान एक बड़े प्रकार में परिवर्तित हो गए जो सभी प्रकारों में सभी मूल्यों का प्रतिनिधित्व कर सकते हैं।
— जेम्स कंज
1
@SteveJessop मुझे लगता है कि आपको इसे वापस लौटने वाले फ़ंक्शन के संदर्भ में लेना होगा unsigned। मुझे यकीन है कि उसे :-) exp(double)से अधिक मूल्य वापस करने में कोई समस्या नहीं है MAX_INT। लेकिन एक बार फिर, वास्तविक समस्या निहितार्थ रूपांतरण है। int i = exp( 1e6 );पूरी तरह से वैध है C ++। स्ट्रॉस्ट्रुप ने वास्तव में एक बिंदु पर नुकसानदायक निहित रूपांतरणों का वर्णन किया, लेकिन समिति ने दिलचस्पी नहीं दिखाई। (एक दिलचस्प सवाल: unsigned-> intहानिपूर्ण माना जाएगा। मैं दोनों पर विचार करूंगा unsigned-> intऔर int-> unsignedहानिपूर्ण। जो unsignedठीक करने के लिए एक लंबा रास्ता तय करेगा
— जेम्स कांज़े
18

यह अधिक सहज और आसानी से समझने योग्य है। यह आशय स्पष्ट करता है।

और यह सुनिश्चित करता है कि कोड को नहीं तोड़ता है जब एक नया उपयोगकर्ता अनजाने में चूक सकते {, }जबकि एक नया कोड बयान जोड़ने।

— आलोक बचाओ
स्रोत
Makes the intent clear+1, यह संभवतः सबसे संक्षिप्त और सटीक कारण है।
— Qix - मोनासा 18
13

ऊपर दिए गए बहुत ही समझदार सुझावों को जोड़ने के लिए, एक उदाहरण जिसका मैंने सामना किया, जबकि कुछ कोड जहां यह महत्वपूर्ण हो जाता है, को निम्न प्रकार से प्रस्तुत किया गया: मैं एक एपीआई से दूसरे में बदलने के लिए एक बहुत बड़े कोडबेस को बदल रहा था। पहले API में Company Id सेट करने के लिए एक कॉल था:

setCompIds( const std::string& compId, const std::string& compSubId );

जबकि प्रतिस्थापन को दो कॉल की आवश्यकता थी:

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

मैंने इसे नियमित अभिव्यक्ति का उपयोग करके बदलने के बारे में निर्धारित किया जो बहुत सफल रहा। हमने astyle के माध्यम से कोड भी पारित किया , जिसने वास्तव में इसे बहुत अधिक पठनीय बना दिया। फिर, समीक्षा प्रक्रिया के माध्यम से, मुझे पता चला कि कुछ सशर्त परिस्थितियों में यह इसे बदल रहा था:

if ( condition )
   setCompIds( compId, compSubId );

इसके लिए:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

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

मुझे लगता है कि अस्टाइल के पास अब विकल्प है --add-bracketsजो आपको ब्रैकेट्स जोड़ने की अनुमति देता है जहां कोई नहीं है और मैं दृढ़ता से यह सलाह देता हूं कि यदि आप कभी भी खुद को उसी स्थिति में नहीं पाते हैं जैसा कि मैं था।

— घटक १०
स्रोत
5
मैंने एक बार कुछ दस्तावेज देखे थे जिनमें अद्भुत संयोग "Microsoftligent" था। हां, वैश्विक खोज और प्रतिस्थापन के साथ महत्वपूर्ण गलतियाँ करना संभव है। इसका मतलब यह है कि वैश्विक खोज और प्रतिस्थापन का उपयोग समझदारी से किया जाना चाहिए, न कि सूक्ष्म रूप से।
— पीट बेकर
4
मुझे पता है कि यह प्रदर्शन करने के लिए मेरा पोस्टमार्टम नहीं है, लेकिन यदि आप स्रोत कोड पर टेक्स्ट रिप्लेसमेंट करने जा रहे हैं, तो आपको इसे उसी नियम के अनुसार करना चाहिए, जिस तरह के टेक्स्ट रिप्लेसमेंट के लिए आप इसका इस्तेमाल करते हैं, जो कि अच्छी तरह से एस्टैब्लिज्ड है। भाषा में: मैक्रोज़। आपको मैक्रो नहीं लिखना चाहिए #define FOO() func1(); \ func2(); (बैकस्लैश के बाद लाइनब्रेक के साथ), वही खोज और प्रतिस्थापित करने के लिए जाता है। उस ने कहा, मैंने "हमेशा ब्रेसिज़ का उपयोग करें" को स्टाइल नियम के रूप में देखा है क्योंकि यह आपको अपने सभी मल्टी-स्टेटमेंट ड्रोन को लपेटने से बचाता है do .. while(0)। लेकिन मैं असहमत हूं।
— स्टीव जेसप
2
Btw, कि "अच्छी तरह से स्थापित" इस अर्थ में कि जापानी गाँठ अच्छी तरह से स्थापित है: मैं यह नहीं कह रहा हूँ कि हमें मैक्रोज़ और पाठ-प्रतिस्थापन का उपयोग करने के लिए हमारे रास्ते से बाहर जाना चाहिए, लेकिन मैं कह रहा हूँ कि जब हम ऐसा करते हैं बात, हमें इसे एक ऐसे तरीके से करना चाहिए जो काम करने के बजाय कुछ ऐसा करे जो केवल तभी काम करता है जब किसी विशेष शैली का नियम पूरी तरह से पूरे कोड बेस पर लगाया गया था :-)
— स्टीव जेसप
1
@SteveJessop एक ब्रेसिज़ और एक बेल्ट के लिए भी बहस कर सकता है। यदि आपको इस तरह के मैक्रोज़ (और हमने C ++ से पहले और inline) का उपयोग करना है, तो आपको संभवतः उनके लिए एक फ़ंक्शन के रूप में अधिक से अधिक काम करना चाहिए, do { ... } while(0)यदि आवश्यक हो तो चाल का उपयोग करना (और बहुत सारे अतिरिक्त कोष्ठक। लेकिन फिर भी) अगर आप घर की शैली के अनुसार हर जगह ब्रेसिज़ का उपयोग करने से रोकते हैं, तो (FWIW: मैंने अलग-अलग घर शैलियों के साथ उन जगहों पर काम किया है, जो यहां चर्चा की गई सभी शैलियों को कवर करती हैं। मुझे कभी कोई गंभीर समस्या नहीं मिली।)
— बजे जेम्स कान्जे
1
और मुझे लगता है, जितने अधिक शैलियों में आपने अधिक सावधानी से काम किया है, आप कोड पढ़ते हैं और संपादित करते हैं। इसलिए यदि आपके पास प्राथमिकता है तो पढ़ना आसान है, फिर भी आप सफलतापूर्वक दूसरों को पढ़ेंगे। मैंने एक ऐसी कंपनी में काम किया, जहां अलग-अलग टीमों द्वारा अलग-अलग "हाउस स्टाइल" में अलग-अलग कंपोनेंट लिखे गए थे, और लंच रूम में इसके बारे में शिकायत करने का सही हल है कि कोई बड़ा असर न पड़े, ग्लोबल स्टाइल बनाने की कोशिश न करें :-)
— स्टीव जेसोप
8

मैं {}कुछ मामलों को छोड़कर हर जगह उपयोग कर रहा हूं जहां यह स्पष्ट है। एकल पंक्ति मामलों में से एक है:

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner

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

अन्य उदाहरण में C # का उपयोग सांख्यिकीय के साथ

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

जो के बराबर है 

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}
— लुकाज़ मदोन
स्रोत
1
बस में अल्पविराम का उपयोग usingबयान और आप की जरूरत नहीं है के लिए :)
— Ry-
1
@ मिनिटेक जो यहां काम नहीं करता है - आप केवल कॉमा का उपयोग कर सकते हैं जब प्रकार समान होते हैं, असमान प्रकार के लिए नहीं। लुकास का ऐसा करने का तरीका विहित तरीका है, आईडीई यहां तक ​​कि इसे अलग तरीके से प्रारूपित करता है (दूसरे के स्वत: इंडेंटेशन की कमी पर ध्यान दें using)।
— कोनराड रुडोल्फ
8

सबसे सटीक उदाहरण मैं सोच सकता हूं:

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

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

अब, उस ने कहा, मैं विशेष रूप से इस "हमेशा ब्रैकेट का उपयोग करें" नियम से सहमत नहीं हूँ। यह कोड को बहुत अधिक शोर करता है, इसके माध्यम से पढ़ने की क्षमता को कम करता है। यदि कथन है:

if(someCondition)
   DoSomething();

... तो ऐसे ही लिखा जाना चाहिए। बयान "हमेशा कोष्ठक का उपयोग करें" ऐसा लगता है जैसे "हमेशा कोष्ठक के साथ गणितीय संचालन को घेरते हैं"। यह एक बहुत ही सरल कथन a * b + c / dको चालू करेगा ((a * b) + (c / d)), जिसमें एक करीबी-पार्न (कई कोडर का बैन) गायब होने की संभावना का परिचय होगा, और किस लिए? संचालन का क्रम अच्छी तरह से जाना जाता है और अच्छी तरह से लागू किया जाता है, इसलिए कोष्ठक बेमानी हैं। a * (b+c) / dउदाहरण के लिए : आमतौर पर लागू किए जाने वाले संचालन के एक अलग क्रम को लागू करने के लिए आप केवल कोष्ठकों का उपयोग करेंगे । ब्लॉक ब्रेसिज़ समान हैं; उन्हें परिभाषित करने के लिए उनका उपयोग करें कि आप उन मामलों में क्या करना चाहते हैं जहां यह डिफ़ॉल्ट से अलग है, और "स्पष्ट" (व्यक्तिपरक नहीं है, लेकिन आमतौर पर बहुत सामान्य ज्ञान है)।

— Keiths
स्रोत
3
@AlexBrown ... जो बिल्कुल मेरी बात थी। ओपी में कहा गया नियम "हमेशा ब्रैकेट्स का उपयोग करें, यहां तक ​​कि एकल लाइनों के लिए भी", जो मैं बताए गए कारण से असहमत हूं। ब्रैकेट बहुत पहले कोड उदाहरण के साथ मदद करेगा , क्योंकि यह कोड उस तरह से व्यवहार नहीं करेगा जैसे यह इंडेंट है; आपको दूसरे के बजाय elseपहले के साथ युग्मित करने के लिए कोष्ठक का उपयोग करना होगा if। कृपया नीचे को हटा दें।
— कीथ
5

उत्तरों के माध्यम से किसी को भी स्पष्ट रूप से यह नहीं बताया गया कि मैं किस तरह का अभ्यास करता हूं, आपके कोड की कहानी बता रहा हूं:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

हो जाता है:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

लाना j++पर एक ही पंक्ति के रूप में अगर किसी और को यह संकेत दे देना चाहिए, "मैं ही कभी वेतन वृद्धि को यह ब्लॉक चाहते हैं j" । कॉर्सेथिस में से केवल तभी सार्थक है जब रेखा यथासंभव सरल हो, क्योंकि यहां एक ब्रेकपॉइंट डालना, पेरी उल्लेख के रूप में, बहुत उपयोगी नहीं है।

वास्तव में मैं सिर्फ ट्विटर स्टॉर्म एपीआई के उस भाग में चला गया हूँ, जिसमें जावा में कोड का यह 'सॉर्ट' है, यहाँ रिल्वेंट स्निपेट को निष्पादित कोड बनाते हैं, इस स्लाइडशो के पेज 43 पर :

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

लूप ब्लॉक के लिए इसमें दो चीजें हैं, इसलिए मैं उस कोड को इनलाइन नहीं करूंगा। Ie कभी नहीं :

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

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

यदि आप वास्तव में किसी और को टेलीग्राफ करना चाहते हैं, तो यह एक लाइन है केवल नौकरी एक टर्नरी ऑपरेटर या ?:फॉर्म का उपयोग करें :

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

लेकिन यह कोड-गोल्फ पर क्रिया कर रहा है, और मुझे लगता है कि महान अभ्यास नहीं है (यह मेरे लिए स्पष्ट नहीं है कि मुझे j ++ को एक तरफ रखना चाहिए :या नहीं)। NB मैंने C ++ से पहले एक टर्नरी ऑपरेटर नहीं चलाया है, मुझे नहीं पता कि यह काम करता है, लेकिन यह मौजूद है ।

संक्षेप में:

कल्पना कीजिए कि आपका पाठक (यानी कोड को मेनटेन करने वाला व्यक्ति) आपकी कहानी (कोड) की व्याख्या कैसे करता है। जितना हो सके उनके लिए इसे स्पष्ट करें। यदि आप जानते हैं कि नौसिखिए कोडर / छात्र इसे बनाए रखते हैं, तो संभवत: {}जितना संभव हो उतना छोड़ दें , ताकि वे भ्रमित न हों।

— Pureferret
स्रोत
1
(१) कथन को एक ही पंक्ति पर रखने से यह कम पठनीय बनता है, अधिक नहीं। विशेष रूप से सरल सोचता है कि वेतन वृद्धि आसानी से अनदेखी की जाती है। क्या उन्हें एक नई लाइन पर डाल दिया। (२) बेशक आप अपने forपाश को एक ही पंक्ति में रख सकते हैं , यह काम क्यों नहीं करना चाहिए? यह उसी कारण से काम करता है कि आप ब्रेसिज़ को छोड़ सकते हैं; सीलाइन में newline महत्वपूर्ण नहीं है। (3) आपका सशर्त ऑपरेटर उदाहरण, भयानक होने के अलावा, अमान्य है C ++।
— कोनराड रुडोल्फ
@KonradRudolph धन्यवाद, मैं C ++ पर थोड़ा कठोर हूँ। मैंने कभी नहीं कहा (1) अधिक पठनीय था, लेकिन यह है कि कोड के उस टुकड़े था संकेत दिया मतलब ऑनलाइन एक पंक्ति किया जाना है। (२) मेरी टिप्पणी अधिक थी कि मैं इसे पढ़ नहीं पा रहा था और यह जानता था कि यह काम कर रहा है, चाहे वह बिल्कुल भी या जैसा भी हो; यह इस कारण के लिए नहीं करने का एक उदाहरण है। (३) धन्यवाद, मैंने लंबे समय में C ++ नहीं लिखा है। अब ठीक कर दूंगा।
— शुद्ध
2
इसके अलावा एक लाइन में एक से अधिक एक्सप्रेशन डालने से कोड को डीबग करना कठिन हो जाता है। आप उस लाइन में 2 एक्सप्रेशन पर ब्रेकपॉइंट कैसे लगाते हैं?
— पेरक
5

क्योंकि जब आपके पास दो बयान होते हैं {}, तो किसी मुद्दे को याद करना आसान होता है। मान लेते हैं कि कोड इस तरह दिखता है।

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

यह ठीक लग रहा है। इसके साथ समस्या को याद करना वास्तव में आसान है, खासकर जब फ़ंक्शन युक्त कोड बड़ा होता है। मुद्दा यह है कि goto failबिना शर्त दौड़ा जाता है। आप आसानी से कल्पना कर सकते हैं कि यह कितना निराशाजनक है (आप पूछते हैं कि अंतिम hash_updateहमेशा विफल क्यों होता है, आखिरकार hash_updateफ़ंक्शन में सब कुछ ठीक दिखता है )।

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

if (something) goto fail;

लेकिन निम्नलिखित एक नहीं।

if (something)
    goto fail;
— कोनराड बोरोस्की
स्रोत
बिल्कुल सही। बस (पूरी तरह से अनावश्यक) न्यूलाइन + इंडेंट न डालें, और आप इस मुद्दे को पूरी तरह से दरकिनार कर दें कि हर कोई हमेशा लाने के लिए इतनी जल्दी है।
— अलेक्जेंडर - मोनिका
4

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

— द्रोण
स्रोत
4

wrt 6: यह सुरक्षित है क्योंकि अशक्त सूचक को हटाना एक नो-ऑप है। इसलिए यदि आप गलती से दो बार उस रास्ते से गुजरते हैं, तो आप स्मृति भ्रष्टाचार को स्मृति मुक्त नहीं कर पाएंगे, जो या तो मुफ्त है या किसी और चीज के लिए आवंटित किया गया है।

यह स्थिर फ़ाइल स्कोप ऑब्जेक्ट्स और सिंगलेट्स के साथ एक समस्या है जो बहुत स्पष्ट जीवनकाल नहीं है और नष्ट होने के बाद फिर से प्राप्त करने के लिए जाना जाता है।

ज्यादातर मामलों में, आप auto_ptrs का उपयोग करके इसके लिए आवश्यकता से बच सकते हैं

— टॉम टान्नर
स्रोत
6
यदि आप दो बार उस रास्ते से गुजरते हैं, तो आपको एक प्रोग्रामिंग त्रुटि मिली है। इस त्रुटि को कम हानिकारक बनाने के लिए एक पॉइंटर को शून्य पर सेट करना अंतर्निहित समस्या को हल नहीं करता है।
— पीट बेकर
1
सहमत हुए, लेकिन मैंने इससे पहले सिफारिश की है, और मेरा मानना ​​है कि यह कुछ पेशेवर प्रोग्रामिंग मानकों में है। मैं इस पर अधिक टिप्पणी कर रहा था कि पोस्टर के प्रोफेसर इसके साथ क्यों आए थे, इसके बजाय जब यह किसी भी अच्छा था
— टॉम टर्नर
2
पीट बेकर ने जो कहा उसके बाद: यह अंतर्निहित समस्या को हल नहीं करता है, लेकिन यह इसे मुखौटा कर सकता है। (ऐसे मामले हैं जहां आप NULLइसे हटाने के बाद एक पॉइंटर सेट करेंगे । यदि NULLउन परिस्थितियों में पॉइंटर के लिए एक सही मान है। जैसे सूचक एक कैश्ड मान को NULLइंगित करता है , और एक अमान्य कैश इंगित करता है। लेकिन जब आप किसी को सेटिंग में देखते हैं। एक NULLविध्वंसक में अंतिम पंक्ति के रूप में एक सूचक , आपको आश्चर्य होता है कि क्या वह C ++ जानता है।)
— जेम्स कांज़े
4

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

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

मुझ से लिपट जाता है। यह लूप के लिए और यदि स्टेटमेंट को अलग-अलग क्रियाओं में अलग करता है, जब वास्तव में आपका इरादा एक क्रिया है: 2. पूर्णांकों के विभाजनों को 2 से गिनने के लिए। अधिक अभिव्यंजक भाषा में, इसे कुछ इस तरह लिखा जा सकता है:

j = [1..100].filter(_%2 == 0).Count

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

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}
— MikeFHay
स्रोत
7
मुझे पसंद है कि हर कोई उपेक्षा for (int i = 0; i < 100; i += 2);के लिए तर्क को जारी रखने की खातिर कैसे प्रबंधित करता है? ;-) शायद एक पूरी तरह से एक अलग लड़ाई हो सकती है, iएक निश्चित संपत्ति के साथ एक निश्चित सीमा में "तर्क को व्यक्त करने के लिए" सबसे अच्छा "कैसे" हो सकता है C ++ में एक लूप के बिना, मानक एल्गोरिदम के कुछ दुःस्वप्न संयोजन का उपयोग करके, filter_iteratorऔर / या counting_iterator।
— स्टीव जेसोप
1
इसके अलावा, अगर हमारे पास ऐसा था, तो हम इस बात से असहमत हो सकते हैं कि कैसे बड़े पैमाने पर एकल बयान को प्रेरित किया जाए।
— स्टीव जेसोप
2
@ हालांकि, यह सिर्फ एक उदाहरण है। पैटर्न के बहुत सारे वैध उपयोग हैं। जाहिर है अगर आप संख्याओं को 1 से 100 तक गिनना चाहते हैं जो कि 2 से विभाज्य हैं, तो आपको बस 100/2 करना होगा।
— माइकफा
2
यकीन है, मुझे पता है, इसीलिए मैंने " iएक निश्चित संपत्ति के साथ एक निश्चित सीमा में प्रत्येक के लिए" सार किया । यह सिर्फ इतना है कि आमतौर पर एसओ पर, लोगों को दिए गए उदाहरण के लिए एक पूरी तरह से अलग दृष्टिकोण के पक्ष में वास्तविक प्रश्न की अनदेखी करने के लिए बहुत जल्दी है। लेकिन इंडेंट करना महत्वपूर्ण है , इसलिए हम ;-)
— स्टीव जेसप
4

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

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong
— काला बाघ
स्रोत
5
दूसरा विकल्प एक संकलन त्रुटि उत्पन्न करेगा, क्योंकि ए elseके साथ संबद्ध नहीं है if।
— लुचियन ग्रिगोर
इनलाइन के साथ एक दृश्यमान समस्या यह नहीं है कि डिफ़ॉल्ट रूप से अधिकांश आईडीई अपनी ऑटोफ़ॉर्मैट उपयोगिता का उपयोग करते समय इसे इंडेंट शैली में बदलते हैं।
— होनज़ा ब्रेबेक ३०'१२
@ होंजा: यह एक बहुप्रचारित राजनीतिक मुद्दा है, हालांकि। यदि हम एक कोड बेस पर सह-संचालन कर रहे हैं, या तो हमें हर अंतिम विवरण के लिए एक ही इंडेंटिंग शैली का उपयोग करना होगा, या हम दोनों को मौजूदा कोड "केवल इसलिए" के लिए ऑटोफ़ॉर्मैट नहीं करने के लिए सहमत होना होगा। यदि पूर्व में तब सहमत शैली अभी भी इसमें शामिल हो सकती है, लेकिन आपको इसका सम्मान करने के लिए या तो ऑटोफ़ॉर्मैट का उपयोग नहीं करने के लिए अपनी आईडीई को कॉन्फ़िगर करना होगा। इस बात से सहमत होना कि सामान्य प्रारूप "जो कुछ भी मेरा आईडीई ऑटोफ़ॉर्मेट्स है" वह सब बहुत अच्छी तरह से है अगर हम सभी एक ही आईडीई का उपयोग हमेशा के लिए करते हैं, तो बहुत अच्छा नहीं।
— स्टीव जेसप
3

यदि आप एक संकलक हैं, तो इससे कोई फर्क नहीं पड़ता। दोनों एक ही हैं।

लेकिन प्रोग्रामर के लिए, पहले वाला अधिक स्पष्ट, पढ़ने में आसान और कम त्रुटि वाला है।

— पीपी
स्रोत
2
{वैसे भी यह लाइन पर खुलने के अलावा अन्य है ।
— रोब
3

घुंघराले ब्रेसिज़ जोड़ने का एक और उदाहरण। एक बार जब मैं बग खोज रहा था और मुझे ऐसा कोड मिला:

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

यदि आप विधि लाइन-दर-पंक्ति पढ़ते हैं, तो आप देखेंगे कि विधि में एक शर्त है जो अगर यह सच नहीं है तो वापस आती है। लेकिन वास्तव में यह 100 अन्य साधारण घटना संचालकों की तरह दिखता है जो कुछ स्थितियों के आधार पर कुछ चर निर्धारित करते हैं। और एक दिन फास्ट कोडर आता है और विधि के अंत में अतिरिक्त चर सेटिंग स्टेटमेंट जोड़ता है:

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

एक परिणाम के रूप में SetAnotherVariableUnconditionnaly जब SomeConditionIsMet () में निष्पादित किया जाता है, लेकिन तेज़ आदमी ने इसे नोटिस नहीं किया, क्योंकि सभी लाइनें लगभग समान हैं और यहां तक ​​कि जब वापसी की स्थिति खड़ी इंडेंट है तो यह ध्यान देने योग्य नहीं है।

यदि सशर्त वापसी इस तरह से स्वरूपित है:

if (!SomeConditionIsMet())
{
    return;
}

यह बहुत ध्यान देने योग्य है और फास्ट कोडर इसे एक नज़र में मिलेगा।

— Artemix
स्रोत
यदि आपका तेज़ कोडर returnकिसी चीज़ को जोड़ने से पहले किसी फ़ंक्शन के शरीर के भीतर एक वाक्यविन्यास-हाइलाइट स्टेटमेंट को स्पॉट करने के लिए परेशान नहीं किया जा सकता है, तो आपको तेज़ कोडर को अपने कोड के पास नहीं जाने देना चाहिए। आप ऐसे व्यक्ति को ब्रेसिज़ सहित अपने कोड के आसपास ट्रोल करने से नहीं रोकेंगे।
— विस्फ़ोटक
@cmaster वह अब हमारे साथ काम नहीं करता है। वैसे भी, वाक्य रचना हाइलाइटिंग अच्छा है, लेकिन याद रखें कि ऐसे व्यक्ति हैं जो स्पष्ट रूप से नहीं देखते हैं (मैंने पिछले साल एक नेत्रहीन प्रोग्रामर की पोस्ट भी देखी थी)।
— आर्टेमिक्स
2

मैं पहले एक को स्पष्ट मानता हूं फिर दूसरा। यह निर्देश बंद करने, छोटे कोड के साथ की भावना ठीक जब कोड जटिल हो जाता है देता है {...}एक बहुत मदद करता है, भले ही यह है endifयाbegin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;
— RollRoll
स्रोत
1

जब आपने इसे पूरा कर लिया है तो पॉइंटर को NULL पर सेट करना सबसे अच्छा है।

यहाँ एक उदाहरण है क्यों:

क्लास ए निम्नलिखित करता है:

  1. मेमोरी का एक ब्लॉक आवंटित करता है
  2. फिर कुछ समय बाद, यह मेमोरी के इस ब्लॉक को हटा देता है लेकिन NULL को पॉइंटर सेट नहीं करता है

क्लास बी निम्नलिखित करता है

  1. मेमोरी आवंटित करता है (और इस उदाहरण में ऐसा होता है कि उसी मेमोरी ब्लॉक को दिया जाए जिसे क्लास ए द्वारा हटा दिया गया था।

इस बिंदु पर क्लास ए और क्लास बी दोनों ही पॉइंटर्स एक ही मेमोरी ब्लॉक की ओर इशारा करते हैं, जहां तक ​​क्लास ए का संबंध है मेमोरी का यह ब्लॉक मौजूद नहीं है क्योंकि यह इसके साथ समाप्त हो गया है।

निम्नलिखित समस्या पर विचार करें:

क्या होगा यदि कक्षा A में कोई तर्क त्रुटि थी, जिसके परिणामस्वरूप यह याद में लिखा गया कि अब कक्षा B से संबंधित है?

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

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

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

अगर आप दूसरी बार NULL होने पर लॉजिक डिलीट के साथ लॉजिक एरर से चिंतित हैं, तो इसके लिए assert जोड़ें।

इसके अलावा: यदि आप वोट देने जा रहे हैं, तो कृपया समझाएं।

— जॉन
स्रोत
2
यदि कोई तर्क त्रुटि थी, तो इसे ठीक किया जाना चाहिए, बल्कि इसे मास्क करना चाहिए।
— अपराह्न ४:१२
@ बरमार, ओपी कहते हैं ... 6. डिलीट के बाद NULL को पॉइंटर सेट करें - डबल डिलीट प्रोटेक्शन // खराब नहीं। कुछ लोगों ने इसे नल को सेट नहीं करने पर जवाब दिया है और मैं कह रहा हूं कि इसे NULL पर क्यों सेट किया जाए, 6. NULL सेट करने का मेरा जवाब 6 में फिट नहीं होता है?
— जॉन
1
@ स्पिन, और आप पहली बार में इन तर्क त्रुटियों को खोजने का प्रस्ताव कैसे करते हैं? एक बार जब आप मेमोरी को डिलीट करने के बाद पॉल्‍टर वैरिएबल को NULL पर सेट करते हैं। NULL पॉइंटर को संदर्भित करने का कोई भी प्रयास उस डिबगर पर क्रैश हो जाएगा जिस पर आपका अवैध प्रयास किया गया था। आप वापस ट्रेस कर सकते हैं और देख सकते हैं कि तर्क त्रुटि कहां थी और समस्या को ठीक करें। यदि आपने मेमोरी को डिलीट करने के बाद पॉइंटर वैरिएबल को सेट नहीं किया है, तो यूएनएवेयर लॉजिक त्रुटियों के कारण इस डिलीटेड मेमोरी को लिखने का आपका अवैध प्रयास सफल हो सकता है और इसलिए उस बिंदु पर क्रैश नहीं होता है। यह इसे मास्क नहीं कर रहा है।
— जॉन
1

हमेशा कर्ली ब्रेसिज़ रखना बहुत ही सरल और मजबूत नियम है। हालाँकि बहुत सारे ब्रेसिज़ होने पर कोड असभ्य लग सकता है। यदि नियम घुंघराले ब्रेसिज़ को छोड़ने की अनुमति देते हैं तो अधिक विस्तृत शैली के नियम और अधिक परिष्कृत उपकरण होने चाहिए। अन्यथा यह आसानी से अराजक और भ्रमित करने वाला (सुरुचिपूर्ण नहीं) कोड हो सकता है। इसलिए सिंगल स्टाइल रूल को बाकी स्टाइल गाइड्स और टूल्स से अलग देखना संभव नहीं है। मैं सिर्फ उस नियम # 3 के बारे में कुछ महत्वपूर्ण विवरण लाऊंगा जिसका उल्लेख अन्य उत्तरों में भी नहीं किया गया है।

पहला दिलचस्प विवरण यह है कि उस नियम के अधिकांश प्रस्तावक इसके मामले में उल्लंघन करने के लिए सहमत हैं else। दूसरे शब्दों में, वे ऐसे कोड की समीक्षा करने की मांग नहीं करते हैं:

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

इसके बजाय, अगर वे इसे देखते हैं तो वे इसे इस तरह लिखने का सुझाव भी दे सकते हैं:

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

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

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

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

— Öö तििब
स्रोत
1

मुझे स्वीकार करना होगा कि हमेशा {}सिंगल लाइन के लिए उपयोग न करें , लेकिन यह एक अच्छा अभ्यास है।

  • कहते हैं कि आप कोष्ठक के बिना एक कोड लिखते हैं जो इस तरह दिखता है:

    for (int i = 0; i <100; ++ i) for (int j = 0; j <100; ++ j) DoSingleStuff ();

और कुछ समय बाद आप jलूप में कुछ अन्य सामान जोड़ना चाहते हैं और आप बस संरेखण द्वारा ऐसा करते हैं और कोष्ठक जोड़ना भूल जाते हैं।

  • मेमोरी डीलोकेशन तेज है। कहते हैं कि आपके पास बड़ा स्कोप है और अंदर बड़े ऐरे बनाएं (बिना newइसके वे स्टैक में हैं)। स्कोप छोड़ने के तुरंत बाद ही वे एरेज़ मेमोरी से निकाल रहे हैं। लेकिन यह संभव है कि आप उस एरे को एक जगह इस्तेमाल करते हैं और यह थोड़ी देर के लिए स्टैक में होगा और किसी तरह का बकवास होगा। जैसा कि एक स्टैक सीमित होता है और काफी छोटा आकार होता है, स्टैक के आकार को पार करना संभव होता है। इसलिए कुछ मामलों में इससे {}बचने के लिए लिखना बेहतर है। ध्यान दें कि यह एकल पंक्ति के लिए नहीं है, बल्कि ऐसी स्थितियों के लिए है:

    if (...) {// SomeStuff ... {// हमारे पास कोई नहीं है, जबकि, आदि // SomeOtherStuff} // SomeMoreStuff}

  • इसका उपयोग करने का तीसरा तरीका दूसरे के साथ समान है। यह सिर्फ स्टैक क्लीनर बनाने के लिए नहीं बल्कि कुछ कार्यों को खोलने के लिए है । यदि आप mutexलंबे कार्यों में उपयोग करते हैं तो आमतौर पर डेटा एक्सेस करने से ठीक पहले लॉक करना और अनलॉक करना बेहतर होता है और पढ़ने / लिखने के बाद ही समाप्त होता है। नोट अगर आप कुछ अपनी खुद की है इस तरह से उपयोग कर रहा है classया structके साथ constructorऔर destructorताला स्मृति करने के लिए।

  • अधिक क्या है:

    if (...) if (...) SomeStuff (); वरना SomeOtherStuff (); // दूसरे पर जाता है अगर, लेकिन आवंटन से पता चलता है कि यह पहले पर है ...

ऑल इन ऑल, मैं यह नहीं कह सकता कि हमेशा {}एक लाइन के लिए उपयोग करने का सबसे अच्छा तरीका क्या है, लेकिन ऐसा करना बुरा नहीं है।

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

— ST3
स्रोत
1

नियंत्रण बयान लिखने के कई संभावित तरीके हैं; उनमें से कुछ संयोजनों को बिना किसी बाधा के सह-अस्तित्व में रखा जा सकता है, लेकिन अन्य संयोजन परेशानी का कारण बनेंगे। शैली

if (condition)
  statement;

नियंत्रण बयान लिखने के कुछ अन्य तरीकों के साथ आराम से सह-अस्तित्व होगा, लेकिन दूसरों के साथ इतना अच्छा नहीं। यदि बहु-पंक्ति नियंत्रित कथनों को लिखा जाता है:

if (condition)
{
  statement;
  statement;
}

तब यह स्पष्ट रूप से स्पष्ट हो जाएगा कि कौन से ifकथन एक लाइन को नियंत्रित करते हैं और कौन से कई लाइनों को नियंत्रित करते हैं। यदि, हालांकि, बहु-पंक्ति ifबयान इस प्रकार लिखे गए हैं:

if (condition) {
  statement;
  statement;
}

तब किसी व्यक्ति ifके आवश्यक ब्रेसेस को जोड़े बिना एकल स्टेटमेंट के निर्माण का विस्तार करने की संभावना अधिक हो सकती है।

ifयदि कोडबेस फॉर्म का महत्वपूर्ण उपयोग करता है तो सिंगल-स्टेटमेंट-ऑन-नेक्स्ट लाइन स्टेटमेंट भी समस्याग्रस्त हो सकता है

if (condition) statement;

मेरी अपनी प्राथमिकता यह है कि अपनी स्वयं की लाइन पर बयान होने से आमतौर पर उन मामलों को छोड़कर, जहां ifसमान नियंत्रण ब्लॉकों के साथ कई बयान होते हैं , जैसे कि उदाहरण के लिए, पठनीयता बढ़ाता है।

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

जिस स्थिति में मैं आम तौर पर पूर्ववर्ती ifबयानों के ऐसे समूहों का पालन करूंगा और उन्हें अन्य कोड से अलग करने के लिए एक रिक्त रेखा के साथ। एक ifही इंडेंटेशन के साथ शुरू होने वाले बयानों की एक सीमा होने से तब स्पष्ट दृश्य संकेत मिलेगा कि कुछ असामान्य है।

— supercat
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.