क्या जावास्क्रिप्ट में एक-लाइन बयान में ब्रेस आवश्यक हैं?

Question

मैंने एक बार सुना था कि एक पंक्ति के बयानों में घुंघराले ब्रेसिज़ को छोड़ना जावास्क्रिप्ट में हानिकारक हो सकता है। मुझे अब तर्क याद नहीं है और Google खोज ने बहुत मदद नहीं की।

क्या कुछ भी है जो जावास्क्रिप्ट में घुंघराले ब्रेसिज़ के भीतर सभी बयानों को घेरना एक अच्छा विचार है?

मैं पूछ रहा हूं, क्योंकि सभी को ऐसा लगता है।

Comments

नोट: केवल पहला कथन ही मान रहा है, भले ही आपके पास एक पंक्ति में कई कथन हों, इसलिए यह "वन लाइन स्टेटमेंट" नहीं है, बल्कि एकल कथन है

— Kris Ivanov

आप इस उत्तर

— ब्लोगर्बर्ड

@Blorgbeard: नहीं, मैंने वास्तव में उस उत्तर का उत्तर दिया था जबकि पहले।

— टॉवर

हह, तो मैं देखता हूं। कोई बात नहीं तो :)

— ब्लोर्बर्ड

: यहाँ अपने जवाब है medium.com/@jonathanabrams/...

— एर्वान लीग्रैन्ड

Answer 1

नहीं

लेकिन उन्हें सिफारिश की जाती है। यदि आप कभी भी बयान का विस्तार करते हैं तो आपको उनकी आवश्यकता होगी।

यह पूरी तरह से वैध है

if (cond) 
    alert("Condition met!")
else
    alert("Condition not met!")

हालाँकि यह अत्यधिक अनुशंसा की जाती है कि आप हमेशा ब्रेसिज़ का उपयोग करें क्योंकि यदि आप (या कोई और) कभी भी उस कथन का विस्तार करते हैं तो इसकी आवश्यकता होगी।

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

if (cond) 
{
    alert("Condition met!")
}
else
{
    alert("Condition not met!")
}

Comments

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

— जकॉब

@ किर्क: डगलस क्रॉकफोर्ड ने इसकी सिफारिश की है। मैं मानता हूं कि यह एक व्यक्तिपरक व्यक्तिगत निर्णय है लेकिन समूह में काम करते समय केवल ब्रेस टाइप करना आसान होता है।

— जोश के

@ जोश, ओह, अच्छी तरह से क्रॉकफोर्ड ने कहा। वह अंतिम शब्द होना चाहिए। ;) (सिर्फ मजाक कर रहे हैं) मुद्दा यह है कि इस बिंदु की विषय-वस्तु सभी सी-लाइक भाषाओं में फैली हुई है, और मजबूत राय पूरे (दोनों पदों के लिए) पाई जा सकती है।

— कर्क वल्ल

मेरा व्यक्तिगत अनुभव बताता है कि टीमों में काम करने के दौरान ब्रेज़र नहीं रखने से बड़े पेंच हो सकते हैं।

— महोदय

हमेशा ब्रेसिज़ {} का उपयोग करना एक अच्छा अभ्यास है। जैसा कि @Axx ने कहा, यदि आप उन्हें छोड़ देते हैं, तो त्रुटि के लिए बहुत अधिक जगह है। यहां तक ​​कि Apple ने iOS के SSL / TLS में एक बग दिया क्योंकि वे ब्रेसिज़ का उपयोग नहीं करते थे

— कीनन लिदल-पोर्टर

Answer 2

एक पठनीयता का पहलू है - इसमें जब आपके पास यौगिक कथन होते हैं तो यह बहुत भ्रामक हो सकता है। इंडेंटिंग मदद करता है, लेकिन संकलक / दुभाषिया के लिए कुछ भी मतलब नहीं है।

var a;
var b;
var c;

//Indenting is clear
if (a===true)
  alert(a); //Only on IF
alert(b); //Always

//Indenting is bad
if (a===true)
  alert(a); //Only on IF
  alert(b); //Always but expected?

//Nested indenting is clear
if (a===true)
  if (b===true)
    alert(a); //Only on if-if
alert (b); //Always

//Nested indenting is misleading
if (a===true)
  if (b===true)
    alert(a); //Only on if-if
  alert (b); //Always but expected as part of first if?

//Compound line is misleading
//b will always alert, but suggests it's part of if
if (a===true) alert(a);alert(b); 
else alert(c); //Error, else isn't attached

और फिर एक एक्स्टेंसिबिलिटी पहलू है:

//Problematic
if (a===true)
  alert(a);
  alert(b); //We're assuming this will happen with the if but it'll happen always
else       //This else is not connected to an if anymore - error
  alert(c);

//Obvious
if (a===true) {
  alert(a); //on if
  alert(b); //on if
} else {
  alert(c); //on !if
} 

सोच यह है कि यदि आपके पास हमेशा ब्रैकेट होते हैं तो आप उस ब्लॉक के अंदर अन्य स्टेटमेंट डालना जानते हैं।

Comments

इसलिए हमें हमेशा इसे वन-लाइनर के रूप में उपयोग करना चाहिए if (a===true) alert(a);:। अब यह स्पष्ट है!

— जोहो पिमेंटेल फरेरा

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

— हॉफमेन्स

Answer 3

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

उदाहरण के लिए, सवाल यह है कि क्या यह ठीक है:

 if (condition) statement;

यह नहीं पूछता कि क्या यह ठीक है:

 if (condition)
   statement;

मुझे लगता है कि कोष्ठक को छोड़ना बेहतर है क्योंकि यह कोड को कम सुपरफ़्लेक्स सिंटैक्स के साथ अधिक पठनीय बनाता है।

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

 if (condition) {
   statement;
 }

एक पंक्ति का उपयोग करना अगर बयान बेहतर है क्योंकि यह कम ऊर्ध्वाधर स्थान का उपयोग करता है और कोड अधिक कॉम्पैक्ट है।

मैं दूसरों को इस पद्धति का उपयोग करने के लिए मजबूर नहीं करूंगा, लेकिन यह मेरे लिए काम करता है और मैं इस बात से अधिक असहमत नहीं था कि कैसे ब्रैकेट को छोड़ कर कोडिंग / स्कोपिंग त्रुटियों की ओर जाता है।

Comments

मुझे हमेशा लगा कि किसी को हमेशा ब्रेसिज़ को शामिल करना चाहिए ... लेकिन मैं अब इसे पुनर्विचार कर रहा हूं। आप अपने पक्ष में airbnb शैली गाइड है!

— प्रेषित

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

— किम

प्रत्येक ब्रैकेट के लिए जोड़े गए 2-लाइन, आपके एक-लाइन स्टेटमेंट को घेरने के लिए संभावित नुकसान की तुलना में एक बड़ी लागत नहीं है - जो आपके कोड को बनाए रखते हुए - यहां तक ​​कि बहुत सावधान डेवलपर द्वारा भी हो सकता है। आप खुद एक पौराणिक कौशल के साथ एक महान डेवलपर हो सकते हैं, लेकिन आप यह नहीं मान सकते हैं कि आपके सहकर्मी हैं। KISS, एक संदर्भ के साथ रैप बातें और दूसरों के लिए संभव के रूप में आसान के रूप में यह कर सकते हैं या आप अंततः मुसीबत में पड़ जाएगा।

— मैकीज टोकरज

@senderle इसे नियंत्रित करने के लिए एस्लिंट नियम यहाँ पाया जा सकता है: eslint.org/docs/rules/curly#multi /*eslint curly: ["error", "multi"]*/

— Silkfire

Answer 4

तकनीकी रूप से नहीं, लेकिन अन्यथा बिल्कुल हाँ !!!

"यह व्यक्तिगत प्राथमिकता है" के बारे में भूल जाओ, "कोड ठीक चलेगा", "यह मेरे लिए ठीक काम कर रहा है", "यह अधिक पठनीय है" यदा यदा बीएस। यह आसानी से बहुत ही गंभीर समस्याओं को जन्म दे सकता है अगर आप एक गलती करते हैं और मुझे विश्वास है कि यह जब आप कोडिंग कर रहे हैं एक गलती करते हैं करने के लिए (क्या नहीं belive ?, प्रसिद्ध की जाँच बहुत ही आसान है एप्पल बग विफल जाना )।

तर्क: "यह व्यक्तिगत प्राथमिकता है"

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

तर्क: "कोड ठीक चलेगा"

तो स्पेगेटी कोड करता है! क्या इसका मतलब यह है कि इसे बनाना ठीक है?

तर्क: "यह मेरे लिए ठीक काम कर रहा है"

अपने करियर में मैंने इस समस्या के कारण इतने सारे कीड़े पैदा किए हैं। आपको शायद याद नहीं है कि आपने कितनी बार टिप्पणी की थी 'DoSomething()'और इस बात से हैरान थे कि 'SomethingElse()':

if (condition) 
    DoSomething();
SomethingElse();

या 'SomeMore' को जोड़ा और ध्यान नहीं दिया कि इसे कहा नहीं जाएगा (भले ही इंडेंटेशन का अर्थ है अन्यथा):

if (condition)
  DoSomething();
  SomethingMore();

यहाँ एक वास्तविक जीवन उदाहरण है जो मेरे पास था। कोई व्यक्ति सभी लॉगिंग को चालू करना चाहता था ताकि वे खोजें और बदलें "console.log"=> //"console.log":

if (condition) 
   console.log("something");
SomethingElse();

समस्या देखें?

यहां तक ​​कि अगर आपको लगता है, "ये बहुत तुच्छ हैं, तो मैं ऐसा कभी नहीं करूंगा"; याद रखें कि हमेशा आपकी तुलना में अवर प्रोग्रामिंग कौशल वाला एक टीम सदस्य होगा (उम्मीद है कि आप टीम में सबसे खराब नहीं हैं!)

तर्क: "यह अधिक पठनीय है"

अगर मैंने प्रोग्रामिंग के बारे में कुछ भी सीखा है, तो यह है कि सरल चीजें बहुत जल्दी जटिल हो जाती हैं। यह बहुत आम है कि यह:

if (condition) 
    DoSomething();

विभिन्न ब्राउज़रों / वातावरणों / उपयोग के मामलों के साथ परीक्षण किए जाने के बाद निम्नलिखित में बदल जाता है या नई सुविधाएँ जोड़ी जाती हैं:

if (a != null)
   if (condition) 
      DoSomething();
   else
      DoSomethingElse(); 
      DoSomethingMore();
else 
    if (b == null)
         alert("error b");
    else 
         alert("error a");

और इसके साथ इसकी तुलना करें:

 if (a != null) {
    if (condition) { 
       DoSomething();
    }
    else {
       DoSomethingElse();
       DoSomethingMore();
    }
 } else if (b == null) {
    alert("error b");
 } else {
    alert("error a");
 }

पुनश्च: बोनस अंक ऊपर दिए गए उदाहरण में बग पर ध्यान देने वाले को जाता है।

Comments

अच्छी तरह से स्पष्ट बग DoSomethingMore () है; लेकिन एक और बग भी है। यदि कोई शून्य और बी शून्य है, तो आपको केवल "त्रुटि बी" मिलती है, आपको "त्रुटि" कभी नहीं मिलती है।

— राकेट 1936

आपके उदाहरणों से, आपकी विकास टीम को पता नहीं है कि कैसे कोड करना है, ब्रेसिज़ उनकी मदद नहीं करेगा ...

— कार्लोस ABS

कुछ उदाहरण Apple डेवलपर टीम के हैं

— Caner

Answer 5

कोई रखरखाव की समस्या नहीं है!

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

if (a > 1)
 alert("foo"),
 alert("bar"),
 alert("lorem"),
 alert("ipsum");
else
 alert("blah");

यह मान्य कोड है जो आपकी अपेक्षा के अनुरूप चलेगा!

Comments

आप मतलब नहीं है if, elseऔर alertऔर नहीं If, Elseऔर Alert?

— अनीश गुप्ता

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

— हेंडेका

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

— साइमन

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

— इंगो बुर्क

मैं "हेमिंग्वेयन" दृष्टिकोण पसंद करता हूं : बहुत साफ। और बीच की जगह के बिना ifऔर (की तरह,if(true) doSomething();

— victorf

Answer 6

एक पंक्ति के बयानों पर घुंघराले ब्रेसिज़ का उपयोग करने के लिए कोई प्रोग्रामिंग कारण नहीं है।

यह केवल कोडर वरीयताओं और पठनीयता के लिए नीचे आता है।

आपका कोड इसकी वजह से नहीं टूटेगा।

Answer 7

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

return
a + b;

// Returns undefined. Treated as:
//   return;
//   a + b;

तो, यह भी अप्रत्याशित परिणाम मिल सकता है, अगर इस तरह से इस्तेमाल किया:

if (x)
   return
   a + b;

यह वास्तव में लिखने के लिए बहुत बेहतर नहीं है

if (x) {
   return
   a + b;
}

लेकिन शायद यहाँ त्रुटि का पता लगाना थोड़ा आसान है (?)

Comments

उन सभी उदाहरण मेरे लिए भयानक लगते हैं, जब तक कि लेखक अस्थायी और भुगतान लाइन द्वारा या जब तक यह काम नहीं करता है।

— सीस टिमरमैन

Answer 8

यह शैली की बात है, लेकिन घुंघराले ब्रेसिज़ संभावित लटकने से रोकने के लिए अच्छे हैं ।

Answer 9

बहुत सारे अच्छे उत्तर हैं, इसलिए मैं अपना "नियम" कहने के अलावा दोहराऊंगा नहीं जब ब्रेसिज़ को छोड़ा जा सकता है: उन शर्तों पर जो 'वापसी' या 'थ्रो' (जैसे।) उनके एकमात्र कथन के रूप में । इस मामले में प्रवाह-नियंत्रण पहले से ही स्पष्ट है कि यह समाप्त हो रहा है:

यहां तक ​​कि "खराब स्थिति" को समाप्त प्रवाह नियंत्रण के कारण जल्दी से पहचाना जा सकता है (और तय किया गया है)। यह अवधारणा / संरचना "नियम" कई भाषाओं पर भी लागू होती है।

if (x)
    return y;
    always();

बेशक, यह भी है कि क्यों एक linter का उपयोग कर सकते हैं ..

Answer 10

यहाँ क्यों यह सिफारिश की है

मान लीजिए कि मैं लिखता हूं

if(someVal)
    alert("True");

फिर अगला डेवलपर आता है और कहता है "ओह, मुझे कुछ और करने की ज़रूरत है", इसलिए वे लिखते हैं

if(someVal)
    alert("True");
    alert("AlsoTrue");

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

Comments

यह सही नहीं है, आपको 'और' याद आ रही है: अगर (someVal) अलर्ट ("ट्रू"); अन्य चेतावनी ("इसके अलावा"); सही होगा। मैं इसका उपयोग नहीं करूंगा क्योंकि मुझे इसके लिए {} पसंद है, यह बेहतर पठनीय है।

— गेरिट बी

है ना? मेरे पास एक और बयान नहीं था। मैं कह रहा था कि घुंघराले ब्रेसिज़ के बिना, यह बग को जन्म दे सकता है अगर कोई नई लाइन जोड़ता है। मुझे लगता है कि आपको मेरी बात समझ में नहीं आई।

— अमीर रामिनफर

मुझे लगता है कि वह जो कह रहा है, वह यह है कि दूसरी पंक्ति को कोई बात नहीं मिलेगी। यदि ब्रेसिज़ के बिना एक कथन केवल 1 पंक्ति निष्पादित कर सकता है।

— पोस्टकोडिज़्म

Answer 11

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

function a(b){if(c){d}else{e}} //ok  
function a(b){if(c)d;else e}   //ok

निश्चित रूप से आपको समापन ब्रेस को अर्धविराम के साथ बदलने की आवश्यकता है यदि यह अन्य समापन ब्रेस पर नहीं है।

एक समारोह अल्पविराम में समाप्त नहीं होना चाहिए।

var a,b=function()c;  //ok *but not in Chrome
var b=function()c,a;  //error  

क्रोम और एफएफ पर परीक्षण किया गया।

Answer 12

हमेशा ऐसा पाया

if(valid) return;

मेरी आँख से आसान है

if(valid) {
  return;
}

भी सशर्त जैसे

(valid) ? ifTrue() : ifFalse();

पढ़ने में आसान (मेरी व्यक्तिगत राय) के बजाय

if(valid) {
  ifTrue();
} else {
  ifFalse();
}

लेकिन मुझे लगता है कि यह कोडन शैली के लिए नीचे आता है

Answer 13

सीधे सवाल का जवाब नहीं दे रहा है, लेकिन नीचे एक पंक्ति पर शर्त के बारे में एक छोटा वाक्यविन्यास है

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

var i=true;
if(i){
  dosomething();
}

इस तरह लिखा जा सकता है:

var i=true;
i && dosomething();

Answer 14

जावास्क्रिप्ट में कई समस्याएं हैं। पर एक नजर डालें इसके बारे में बात जावास्क्रिप्ट वास्तुकार डगलस Crockford अगर बयान ठीक हो रहा है, लेकिन बदले बयान एक समस्या उत्पन्न हो जाएं।

return
{
    ok:false;
}
//silent error (return undefined)

return{
    ok:true;
}
//works well in javascript

Answer 15

मुझे एक समान अनुभव के बारे में खोज करने का यह उत्तर मिला तो मैंने अपने अनुभव से इसका उत्तर देने का निर्णय लिया।

ब्रैकेटलेस स्टेटमेंट अधिकांश ब्राउज़रों में काम करते हैं, हालांकि, मैंने परीक्षण किया कि ब्रैकेटलेस तरीके वास्तव में कुछ ब्राउज़र में काम नहीं करते हैं।

26 फरवरी 2018 तक, यह कथन पैले मून में काम करता है, लेकिन Google क्रोम में नहीं।

function foo()
   return bar;

Answer 16

एक बयान का शुरुआती इंडेंटेशन स्तर इसके ऊपर खुले ब्रेसिज़ की संख्या के बराबर होना चाहिए। (प्रीप्रोसेसर निर्देशों में उद्धृत या टिप्पणी किए गए ब्रेसिज़ या लोगों को छोड़कर)

अन्यथा K & R अच्छा इंडेंटेशन स्टाइल होगा। उनकी शैली को ठीक करने के लिए, मैं एक पंक्ति में कथनों को सरल रखने की सलाह देता हूं।

if (foo) bar();    // I like this. It's also consistent with Python FWIW

के बजाय

if (foo)
   bar();   // not so good

यदि मैं एक संपादक लिख रहा था, तो मैं इसके ऑटो प्रारूप बटन को बार को foo के रूप में एक ही पंक्ति में चूसूंगा, और अगर आप इसे इस तरह से पहले वापस दबाते हैं तो मैं इसे बार के चारों ओर ब्रेसिज़ बनाऊंगा:

if (foo) {
  bar();    // better
}

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

if (foo) {
  bar();    // consistent
  baz();    // easy to read and maintain
}

Answer 17

कभी-कभी उन्हें जरूरत लगती है! मैं खुद इस पर विश्वास नहीं कर सकता था, लेकिन कल यह मेरे लिए फायरबग सत्र (हाल ही में फ़ायरफ़ॉक्स 22.0) में हुआ

if (! my.condition.key)
    do something;

मेरे . condition.key के बावजूद कुछ किया गया था सच था । ब्रेसिज़ जोड़ना:

if (! my.condition.var) {
    do something;
}

उस बात को तय किया। ऐसे उदाहरण हैं जहां यह स्पष्ट रूप से ब्रेसिज़ के बिना काम करता है, लेकिन इस मामले में यह निश्चित रूप से नहीं हुआ।

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

if (condition)
    do something; do something else;

खोजना मुश्किल है।

Comments

मैं इस बात से उत्सुक हूं कि अगर स्थिति को सच कर दिया जाए तो ब्रेसेस की कमी क्या आपको याद दिला सकती है या इसका वास्तविक उदाहरण दे सकती है?

— gitsitgo

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

— अर्धविराम

Answer 18

मैं बस यह ध्यान देना चाहूंगा कि आप घुंघराले ब्रेसिज़ को सिर्फ और सिर्फ छोड़ सकते हैं। जैसा कि जॉन रेजिग के इस लेख में देखा गया है ।

if(2 == 1){
    if(1 == 2){
        console.log("We will never get here")
    }
} else 
    console.log("We will get here")

Comments

[Qt ब्रेसिज़ शैली] [1] को elseब्रेस उपयोग के दोनों किनारों पर ब्लॉक की आवश्यकता होती है - इस उदाहरण को elseकोड समीक्षा पास करने के लिए ब्लॉक पर ब्रेसिज़ की आवश्यकता होगी । [१]: wiki.qt.io/Qt_Coding_Style#Braces

— पिक्सेल

क्यों होता है पतन? ऊपर दिया गया कथन 100% सटीक है।

— जॉनसन

Answer 19

बयान करने के लिए कई लाइन नॉन कर्ली ब्रेसेस को प्राप्त करने का एक तरीका है .. (वाह क्या अंग्रेजी ..), लेकिन यह थोड़े ही है।

if(true)
   funcName();
else
   return null;


function funcName(){
  //Do Stuff Here...
}

Comments

घुंघराले ब्रेसिज़ को छोड़ते समय आपके पास इतनी नई लाइनें नहीं होती हैं। ऊपर भी दो पंक्तियों के रूप में लिखा जा सकता है: if (true) funcName()और else return null

— फोबोस