एकल निर्णय और कार्यवाही बयान के लिए पसंदीदा शैली क्या है?

उन भाषाओं के मामले में जो एकल निर्णय और कार्रवाई को ब्रैकेट के बिना समर्थन देते हैं, जैसे कि निम्न उदाहरण:

if (var == true)
    doSomething();

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

if (var == 1)
    doSomething(1);
else if (var > 1 && var < 10)
    doSomething(2);
else
{
    validate(var);
    doSomething(var);
}
0
ro fr bn

18 उत्तर

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

if (cond1)
{
   SomeOperation();
   Another();
}
elseif (cond2)
{
   DoSomething();
}
else
{
   DoNothing();
   DoAnother();
}

लेकिन अगर आपके पास सिर्फ एक लाइनर का गुच्छा है:

if (cond1)
    DoFirst();
elseif (cond2)
    DoSecond();
else
    DoElse();

क्लीनर दिखता है (यदि आपको डमी विधि के नामों पर कोई ध्यान नहीं है;) इस तरह, लेकिन यह सिर्फ मुझे है।

यह लूप संरचनाओं पर भी लागू होता है और जैसा:

foreach (var s as Something)
    if (s == someCondition)
        yield return SomeMethod(s);

आपको यह भी विचार करना चाहिए कि यह एक ऐसा सम्मेलन है जो .NET के लिए अधिक उपयुक्त हो सकता है (ध्यान दें कि जावा पेपज़ को उसी पंक्ति में अपनी पहली घुंघराले ब्रेस रखना है)।

0
जोड़ा

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

और बुद्धिमानों से पहले, नहीं, इसका कारण यह नहीं था कि "हर कोई हमेशा ब्रेसिज़ का उपयोग करता है"।

तो, एक ईमानदार सवाल - मैं वास्तव में केवल डाउनवॉट्स के बजाय वास्तविक उत्तरों प्राप्त करना चाहता हूं: क्या वास्तव में ऐसा होता है?

(संपादित करें: मैंने कुछ स्पष्ट करने के लिए पर्याप्त आउटसोर्सिंग डरावनी कहानियों को सुना है: क्या यह वास्तव में सक्षम प्रोग्रामर के साथ होता है?)

0
जोड़ा
मैंने यह गलती की है, और जब मैंने किसी और को यह गलती की है तो मैंने इसे पाया और ठीक कर दिया है। चाहे हम सक्षम थे चर्चा के लिए खुला है।
जोड़ा लेखक Jay Bazuzi, स्रोत

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

उस स्थिति में, मैं सुनिश्चित करता हूं कि यह स्पष्ट है कि यह सब कुछ एक पंक्ति पर रखकर एक ही कथन है, जैसे:

if (aString) free(aString);
0
जोड़ा

हमारा मालिक हमें निर्णय कथन के बाद {} डाल देता है चाहे कोई भी बयान न हो, भले ही यह एक ही कथन है। दो अतिरिक्त लाइनों को जोड़ना वास्तव में परेशान है। एकमात्र अपवाद टर्नरी ऑपरेटरों है।

मुझे लगता है कि यह अच्छी बात है कि मेरे पास 1200x1600 पर पोर्ट्रेट अभिविन्यास में मेरा कोड मॉनीटर है।

0
जोड़ा

मेरा सुझाव है

if(a==b)
{
    doSomething();
}

क्योंकि जब मैं सफलता की स्थिति में दूसरा कथन जोड़ता हूं तो मुझे ब्रेसिज़ जोड़ने के लिए याद रखने की तुलना में इसे आगे करना आसान लगता है ...

if(a==b)
    doSomething();
    doSomethingElse();

बहुत अलग है

if(a==b)
{
    doSomething();
    doSomethingElse();
}

अधिक जानकारी के लिए जोएल का लेख देखें

0
जोड़ा
आपको हमेशा किसी और में ब्रेसिज़ के साथ भागना चाहिए। हमेशा हमेशा हमेशा।
जोड़ा लेखक 5arx, स्रोत

There is no right or wrong way to write the above statement. There are plenty of accepted coding styles. However, for me, I prefer keeping the coding style consist throughout the entire project. ie. If the project is using K&R style, you should use K&R.

0
जोड़ा

मैं हर समय ब्रेसिज़ का उपयोग करता हूं। आप कुछ सूक्ष्म बग प्राप्त कर सकते हैं जहां आपने कुछ इस तरह से शुरू किया था:

if(something)
 DoOneThing();
else
  DoItDifferently();

और फिर else खंड में एक और ऑपरेशन जोड़ने का निर्णय लेते हैं और इसे ब्रेसिज़ में लपेटना भूल जाते हैं:

if(something)
 DoOneThing();
else
  DoItDifferently();
  AlwaysGetsCalled(); 

AlwaysGetsCalled() will always get called, and if you're sitting there at 3am wondering why your code is behaving all strange, something like that could elude you for quite some time. For this reason alone, I always use braces.

0
जोड़ा

रुबी ने चर्चा में एक मुद्दे को अच्छी तरह से रोक दिया। एक लाइनर के लिए मानक है:

do_something if (a == b)

और एक बहु-रेखा के लिए:

if (a == b)
  do_something
  do_something_else
end

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

यह जावा में उपलब्ध नहीं है, न ही कई अन्य भाषाओं में, AFAIK।

0
जोड़ा

मैं एक apparatchik की तरह "घुंघराले ब्रेसिज़ हमेशा उपयोग करें" लाइन का पालन करता था। हालांकि, मैंने अपनी शैली को एकल पंक्ति सशर्त अभिव्यक्तियों पर छोड़ने की अनुमति देने के लिए संशोधित किया है:

if(!ok)return;

किसी भी बहुस्तरीय परिदृश्य के लिए हालांकि मुझे अभी भी राय है कि ब्रेसिज़ अनिवार्य होना चाहिए:

if(!ok){

    do();

    that();

    thing();
}
0
जोड़ा
मुझे यकीन नहीं है हालांकि मुझे संदेह नहीं है कि स्टैक ओवरफ्लो पर एपारैचिक्स हैं।
जोड़ा लेखक t3rse, स्रोत
डाउनवोट क्यों?
जोड़ा लेखक David Thornley, स्रोत

सुनहरा नियम यह है कि, किसी मौजूदा प्रोजेक्ट में काम करते समय, उन कोडिंग मानकों का पालन करें।

जब मैं घर पर हूं, मेरे पास दो रूप हैं।

पहला एकल पंक्ति है:

if (condition) doThis();

और दूसरा एकाधिक लाइनों के लिए है:

if (condition) {
   doThis();
}
0
जोड़ा

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

if ( a == b)    {
    doSomething();
}
else {
    doSomething();
}

लेकिन यह एक पवित्र युद्ध है।

0
जोड़ा

जैसा कि अन्य ने उल्लेख किया है, ब्रेसिज़ के बिना दो लाइनों में अगर कथन कर रहा है तो भ्रम पैदा हो सकता है:

if (a == b)
    DoSomething();
    DoSomethingElse(); <-- outside if statement

तो अगर मैं पठनीयता को नुकसान पहुंचाए बिना ऐसा कर सकता हूं तो मैं इसे एक पंक्ति पर रखता हूं:

if (a == b) DoSomething();

और दूसरी बार मैं ब्रेसिज़ का उपयोग करता हूं।

टर्नरी ऑपरेटर थोड़ा अलग हैं। अधिकांश समय मैं उन्हें एक पंक्ति पर करता हूं:

var c = (a == b) ? DoSomething() : DoSomethingElse();

लेकिन कभी-कभी बयान में फ़ंक्शन कॉल, या लैम्ब्डा अभिव्यक्तियां होती हैं एक पंक्ति कथन को दृष्टि से पार्स करना मुश्किल है, इसलिए मैं इस तरह कुछ पसंद करता हूं:

var c = (a == b)
    ? AReallyReallyLongFunctionName()
    : AnotherReallyReallyLongFunctionOrStatement();

अगर/अन्य ब्लॉक की तुलना में अभी भी अधिक संक्षिप्त है लेकिन यह देखने में आसान है कि क्या हो रहा है।

0
जोड़ा

पर्ल में यदि आप एक साधारण परीक्षा कर रहे हैं, तो कभी-कभी आप इसे इस फॉर्म में लिखेंगे:

do_something if condition;

do_something unless condition;

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

sub test{
  my($self,@args) = @_;

  return undef unless defined $self;

  # rest of code goes here

}
0
जोड़ा

यह वास्तव में कोई फर्क नहीं पड़ता, जब तक आप इसके साथ संगत हो।

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

0
जोड़ा

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

if (cond)
   {
   //statement
   }

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

हां, मैं अपने ब्रैकेट को ब्लॉक के स्तर पर भी इंडेंट करना पसंद करता हूं।

पाइथन अच्छा है कि इंडेंटेशन ब्लॉक को परिभाषित करता है। प्रश्न इस तरह की भाषा में मूक है।

0
जोड़ा

मैं दृढ़ता से हमेशा ब्रेसिज़ का उपयोग करके वकालत करता हूं, भले ही वे वैकल्पिक हों। क्यूं कर? सी ++ कोड का यह हिस्सा लें:

if (var == 1)
  doSomething();
doSomethingElse();

अब, कोई ऐसे व्यक्ति के साथ आता है जो वास्तव में पर्याप्त ध्यान नहीं दे रहा है और निर्णय लेता है कि कुछ अतिरिक्त होने की आवश्यकता है यदि (var == 1), तो वे ऐसा करते हैं:

if (var == 1)
  doSomething();
  doSomethingExtra();
doSomethingElse();

यह सब अभी भी खूबसूरती से इंडेंट है लेकिन यह इरादा नहीं करेगा।

हमेशा ब्रेसिज़ का उपयोग करके, आप इस प्रकार की बग से बचने की अधिक संभावना रखते हैं।

0
जोड़ा

मैं उस लेख के साथ जोएल स्पॉस्की से सहमत हूं ( गलत कोड देखो गलत ) निम्नलिखित कोड उदाहरण के साथ:

if (i != 0)
bar(i);
foo(i);

फू अब बिना शर्त है। वास्तव में बुरा बुरा है!

मैं निर्णय निर्णय के लिए हमेशा ब्रैकेट का उपयोग करता हूं। यह कोड रखरखाव में मदद करता है और यह कोड कम बग प्रवण बनाता है।

0
जोड़ा

मैं कोड पूर्ण से मैककनेल के स्पष्टीकरण के साथ व्यक्तिगत रूप से पक्ष करता हूं।

जब भी आप कर सकते हैं उनका इस्तेमाल करें। वे आपके कोड की पठनीयता को बढ़ाते हैं और कुछ और दुर्लभ भ्रम को हटा सकते हैं जो हो सकता है।

हालांकि एक चीज है जो अधिक महत्वपूर्ण है .... संगठनात्मकता। आप जिस शैली का उपयोग करते हैं, सुनिश्चित करें कि आप हमेशा ऐसा ही करते हैं।

सामान लिखना शुरू करें जैसे:


If A == true
   FunctA();

If B == "Test"
{
   FunctB();
}

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

असल में वह व्यक्ति ढूंढें जिसे आप हर बार लिखने में सहज महसूस करते हैं और इसके साथ चिपके रहते हैं। मुझे ब्लॉक डिलीमीटर ('{', '}') का उपयोग करने में विश्वास है जितना संभव हो सके जाने का तरीका है।

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


If A == false {
  //calls and whatnot
}
//or
If B == "BlaBla"
{
  //calls and whatnot
}
//or
If C == B
  {
  //calls and whatnot
  }

कृपया इसका उत्तर न दें क्योंकि यह एक नया सवाल होगा। अगर मुझे इसमें दिलचस्पी दिखाई देती है तो मैं आपका इनपुट एक नया प्रश्न खोलूंगा।

0
जोड़ा