एकल कथन यदि ब्लॉक - ब्रेसिज़ या नहीं? [बन्द है]

Question

कौन सा बेहतर / अधिक सामान्यतः स्वीकार किया जाता है?

इस:

if(condition)
{
  statement;
}

या:

if(condition)
  statement;

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

Comments

लेकिन आपके पास गलत स्थिति में अपने शुरुआती ब्रेस हैं। इतना तय है।

— ईसाई मान

कई भाषाओं में, एक ब्लॉक एक बयान है, इसलिए, वाक्यात्मक रूप से, यह हमेशा होता है अगर (एक्सप्रेशन) बयान

— Ingo

चूंकि आपने कोई भाषा निर्दिष्ट नहीं की है ... क्या है statement if condition;?

— डेव शेरोमैन

@ क्रिसियन - अच्छा। यह इससे अलग एक और सवाल होगा, नहीं?

— ज़नजमाइंडर्सन

@ इंगो - अच्छी बात है।

— ज़नजमाइंडर्सन

Answer 1

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

if(condition) 
//      statement;
otherStatement;

या जल्दी में कोड जोड़ना:

if(condition) 
    statement;
    otherStatement;

यह स्पष्ट रूप से बुरा है। दूसरी ओर, पहला व्यक्ति कई बार बहुत अधिक क्रियात्मक महसूस करता है। इसलिए, अगर यह पर्याप्त रूप से छोटा और सरल है, तो मैं सब कुछ एक पंक्ति में रखना पसंद करता हूं:

if(condition) statement;

निर्माण कार्य करते समय यह सिंटैक्टिक शोर में कटौती करता है, जैसा कि यह वास्तव में करता है, यह कम त्रुटि वाला बनाता है। बशर्ते कि यह वाक्यविन्यास केवल बहुत ही सरल, छोटी स्थितियों और बयानों के लिए उपयोग किया जाता है, मुझे यह पूरी तरह से पठनीय लगता है।

Comments

सब कुछ एक लाइन पर रखने के बारे में अच्छी बात।

— नील ऐटकन

@artjomka: यदि कथन लंबा है, और उसे अपनी लाइन पर जाना है, तो मैं पठनीयता के लिए ब्रेसिज़ का उपयोग करता हूं। मुद्दा यह है कि आप सबसे छोटा, कम से कम वाक्य निर्माण चाहते हैं जो मानव के लिए असंदिग्ध है जो इसे जांचने के बजाय जल्दी से पढ़ रहा है।

— dsimcha

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

— जिम ए

@ टीएमएन व्हाट्सएप स्वतंत्र है, मॉनिटर बड़े हैं और आपका मस्तिष्क आकृति को पहचानना सीखता है जो आपको कोड पार्स करने में मदद करता है।

— मर्फ़

@ मर्फ़: व्हॉट्सएप फ्री है? मेरे से वह छूट गया होगा। मेरी स्क्रीन पर, यह वास्तव में बहुत जगह लेता है। वास्तव में 50% से अधिक। जो मेरी किताब में एक बड़ी बर्बादी की तरह लगता है। व्यक्तिगत रूप से, मुझे कोड में प्रति वर्ग सेंटीमीटर अधिकतम सामग्री पसंद है।

— कोनराड रूडोल्फ 16

Answer 2

मैं हमेशा सुरक्षित रहने के लिए कोष्ठक का उपयोग करता हूं।

जब आप इसे लिखते हैं तो यह ठीक है, लेकिन आप जानते हैं कि कोई व्यक्ति भविष्य में साथ आएगा और उसके चारों ओर कोष्ठक लगाए बिना एक और कथन सम्मिलित करेगा।

Comments

क्या लोगों ने वास्तव में ऐसा होते देखा है? मुझे नहीं लगता कि मैंने इसे 10 साल की प्रोग्रामिंग में कभी देखा है। हो सकता है कि मैं अभी आश्रय में आया हूँ। :)

— डेविड

मुझे ना कहना अच्छा लगेगा, लेकिन दुख की बात है कि मैंने इसे देखा है।

— नील एटकन

आप हमेशा कोष्ठक का उपयोग करते हैं ताकि आप कोष्ठक का उपयोग करना कभी न भूलें - इसके रूप में सरल है।

— मर्फ़

+1 से @ मर्फ़। उसी कारण जब मैं किसी के आसपास - और पार्किंग स्थल में अपनी बारी के संकेतों का उपयोग करता हूं!

— दान रे

शाखा-से-ट्रंक या शाखाओं के बीच विलय करते समय त्रुटियों को रोकने में मदद करने के लिए यह अच्छा अभ्यास है।

— JBRWilkinson

Answer 3

मैं जहां संभव हो बिना ब्रेसिज़ के संस्करण को पसंद करता हूं ।

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

(पास-) खाली लाइनें एक बेकार हैं

इसका कारण यह है कि समापन ब्रेस को कोड की एक अतिरिक्त रेखा की आवश्यकता होती है - और इसलिए शैली के आधार पर उद्घाटन ब्रेस होता है। ¹

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

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

यह एक मूलभूत समस्या है: एक बार जब आप अपनी स्क्रीन पर पूरे ब्लॉक को किसी भी समय नहीं देख सकते हैं, तो यह समझ में आ जाता है।

एक परिणाम के रूप में, मैं निरर्थक खाली लाइनों का पता लगाता हूं। जहाँ सिंगल खाली लाइनें स्वतंत्र ब्लाकों का परिसीमन करने के लिए महत्वपूर्ण हैं (बस इस पाठ के दृश्य स्वरूप को देखें), मेरी किताब में लगातार खाली लाइनें एक बहुत खराब शैली हैं (और मेरे अनुभव में वे आमतौर पर नौसिखिए प्रोग्रामर का संकेत हैं)।

इसी तरह, लाइनें जो एक ब्रेस रखती हैं, और जो किफायती हो सकती हैं, होनी चाहिए। एक एकल-स्टेट ब्लॉक जिसे ब्रेसिज़ द्वारा सीमांकित किया गया है, एक से दो लाइनों को बर्बाद करता है। प्रति स्क्रीन ऊंचाई केवल 50-ईश लाइनों के साथ, यह ध्यान देने योग्य है।

ब्रेसिज़ को छोड़ने से शायद कोई नुकसान न हो

ब्रेसिज़ को छोड़ने के खिलाफ सिर्फ एक तर्क है: कोई बाद में प्रश्न में ब्लॉक में एक और बयान जोड़ देगा और ब्रेसिज़ जोड़ना भूल जाएगा, इस प्रकार अनजाने में कोड के शब्दार्थ को बदल देगा।

यह वास्तव में एक बड़ी बात होगी।

लेकिन मेरे अनुभव में, ऐसा नहीं है। मैं एक मैला प्रोग्रामर हूँ; और फिर भी, अपने दशक के प्रोग्रामिंग अनुभव में, मैं ईमानदारी से कह सकता हूं कि मैं एक बार सिंगलटन ब्लॉक में एक अतिरिक्त स्टेटमेंट जोड़ते समय ब्रेसिज़ जोड़ना नहीं भूलता।

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

अब, मैं यह नहीं कह रहा हूँ कि ब्रेसिज़ को छोड़ने से गलतियाँ नहीं होती हैं। मैं जो कह रहा हूं वह यह है कि हमारे पास कोई रास्ता नहीं है। हम बस यह नहीं जानते कि क्या इससे नुकसान होता है।

इसलिए जब तक कोई मुझे कठिन डेटा नहीं दिखा सकता है, वैज्ञानिक प्रयोगों से एकत्र किया गया है, यह दर्शाता है कि यह वास्तव में व्यवहार में एक मुद्दा है, यह सिद्धांत एक " जस्ट-सो स्टोरी " बना हुआ है: एक बहुत ही सम्मोहक परिकल्पना जो कभी भी परीक्षण में नहीं डाली गई है, और वह एक तर्क के रूप में इस्तेमाल नहीं किया जाना चाहिए ।

---

¹ इस समस्या को कभी-कभी सब कुछ डालकर हल किया जाता है - ब्रेसिज़ सहित - एक ही लाइन पर:

if (condition)
{ do_something(); }

हालांकि, मेरा मानना ​​है कि यह कहना सुरक्षित है कि ज्यादातर लोग इसे घृणा करते हैं। इसके अलावा, इसमें ब्रेसिज़ के बिना वैरिएंट के समान समस्याएं होंगी, इसलिए यह दोनों दुनिया में सबसे खराब है।

Comments

ओमिटिंग ब्रेसिज़ पठनीयता को नुकसान पहुँचाता है और कोड को संशोधित करने पर आसानी से समस्या पैदा कर सकता है।

— जोश के

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

— कोनराड रुडोल्फ

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

— 18

@bedwyr: हालांकि गुणात्मक अंतर है। सबसे पहले, मैं यह स्पष्ट करता हूं कि मुझे वास्तव में डेटा द्वारा राजी किया जाएगा, और मैं यह भी स्पष्ट रूप से स्पष्ट करता हूं कि मेरा केवल एक परिकल्पना है, डेटा द्वारा समर्थित नहीं है । दूसरे, मैंने अपने विश्वास के लिए एक (कम से कम मेरे लिए) प्रशंसनीय तर्क दिया है कि यह दावा झूठा है कि इसकी पुष्टि क्यों की जानी चाहिए। जो मुझे तीसरे स्थान पर ले जाता है: यहाँ पर विपक्ष अपने दावे को साबित करने के लिए विपक्ष में है, न कि मुझ पर इसे लागू करने के लिए। और बहुतायत समस्या के अलावा, मैंने अपनी कोडिंग शैली का समर्थन करते हुए एक असंबंधित तथ्यात्मक तर्क दिखाया है।

— कोनराड रुडोल्फ

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

— मर्फ़

Answer 4

मैं दूसरे के साथ जाता हूं। यह अधिक रसीला और कम क्रिया है।

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

Comments

पूर्ण रूप से! आखिरकार, अगर कोड लिखना मुश्किल था, तो इसे बनाए रखना मुश्किल होना चाहिए! ;-)

— स्टीवन ए लोव

@ यदि आप ब्रेसिज़ भूल जाते हैं, तो मुझे लगता है कि यहां अन्य समस्याएं हैं।

— 1

अधिक succint == कम

— क्रिया

@SnOrfus: कुछ व्यंग्यात्मक, चूंकि अतिरिक्त 2 वर्ण तुच्छ ओवरहेड हैं और एक बहुत ही सामान्य रखरखाव गलती को रोकते हैं। आपका माइलेज मई वैरी ;-)

— स्टीवन ए लोव

मेरे लिए इंडेंटिंग यह स्पष्ट करता है कि क्या चल रहा है। पहला रूप अतिरिक्त स्क्रीन स्थान को जलता है और इस तरह मेरे लिए एक नकारात्मक है।

— लोरेन Pechtel

Answer 5

मैं निम्नलिखित (यहां सर्वसम्मति) का उपयोग करूंगा:

if (condition) {
    any_number_of_statements;
}

यह भी संभव है:

if(condition) single_compact_statement;

इतना अच्छा नहीं है, खासकर सी / सी ++ में - भाषाओं की तरह:

if(condition) 
    single_compact_statement;

( पायथन में यहाँ कोई विकल्प नहीं ; ;-)

---

में पर्ल , आप उपयोग करेंगे:

$C = $A**3 if $A != $B;

या

$C = $A**3 unless $A == $B;

(यह छद्म कोड नहीं है ;-)

Comments

मेरे विचार से भी। यदि एकल कथन ifखंड के बाद एकल पंक्ति पर अच्छा लगता है , तो मैं ब्रेसिज़ का उपयोग नहीं करता। किसी भी अन्य ifकथन के लिए (या कोई भी कथन जो कई लाइनों का उपयोग करता है), मैं हमेशा ब्रेसिज़ का उपयोग करता हूं। विशेष रूप से, यदि कोई elseखंड है, तो प्रत्येक मामले में हमेशा ब्रेसिज़ होते हैं।

— eswald

मैंने पहले कभी किसी को pseudocode के साथ perl को भ्रमित नहीं देखा है। यादृच्छिक वर्ण हां, स्यूडोकोड - नहीं।

— जो डी डी

मुझे आश्चर्य है कि अगर किसी ने पर्ल प्रोग्राम को जेनरेटर बनाया है / हुक / देव / यादृच्छिक से पर्ल इंटरप्रेटर ...

— ईसाई मान

मुझे यहां रूबी का दृष्टिकोण पसंद है। यह पेरल स्टाइल को सिंगल-लाइन <statement> if <condition>या मल्टीलाइन ब्लॉक स्टाइल if <condition>/ <do something>/ प्रदान करता है end(रूबी ब्रेसेस से बचता है, इसलिए यहां ओपनिंग ब्रेस निहित है ifऔर एंड ब्रेस को शाब्दिक रूप से बदल दिया जाता है end)। यह अजीब बहुस्तरीय-लेकिन-वास्तव में सिर्फ-एकल-पंक्ति की पेशकश नहीं करता है यदि कथन।

— बेन ली

एक-लाइनर अधिकांश डिबगर्स के साथ काम नहीं करता है (जब 'क्लॉज निष्पादित होने वाला है' की सामग्री होने पर ब्रेक को ट्रिगर करना संभव नहीं है)।

— पीटर मॉर्टेंसन

Answer 6

मैं ब्रेसिज़ विधि का उपयोग करता हूं - उपरोक्त सभी कारणों के लिए प्लस एक और।

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

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

Answer 7

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

Comments

ठीक ठीक! यह हमारी गलती नहीं है कि वह वाक्य रचना नहीं जानता है।

— kirk.burleson

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

— ०४:३३ में ०४:३५

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

— अराम कोचरन

Answer 8

हमारे यहाँ यह तर्क एक से अधिक बार आया है, और समग्र आम सहमति हमेशा ब्रेसिज़ का उपयोग करना है। मुख्य कारण पठनीयता / स्थिरता के बारे में हैं।

यदि आपको ifब्लॉक में कोड जोड़ने की आवश्यकता है , तो आपको ब्रेसिज़ को याद रखने / खोजने की आवश्यकता नहीं है। जब भविष्य के प्रोग्रामर कोड पढ़ते हैं, तो ब्रेसिज़ हमेशा अस्पष्ट होते हैं।

दूसरी तरफ, ReSharper विजुअल स्टूडियो में आलसी प्रोग्रामर के लिए ब्रेसिज़ को स्वचालित रूप से जोड़ देगा, और मुझे लगता है कि अन्य IDE के लिए एडऑन हैं जो ऐसा भी करेंगे।

Comments

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

— कोनराड रुडोल्फ

जैसा कि पायथन ने सीमांकक के बजाय इंडेंटेशन का उपयोग किया है, वे इसका अनुमान है कि इसकी वैध तुलना नहीं है।

— मर्फ़

@ कोनराड - अनुभवजन्य साक्ष्य: जब मैं एक नया प्रोग्रामर था, तो मैंने व्यक्तिगत रूप से एक अन-ब्रेस्ड में कोड जोड़ा था अगर यह महसूस किए बिना ब्लॉक किया जाता है कि पिछले प्रोग्रामर ने ब्रेसिज़ के साथ परेशान नहीं किया था। मैंने व्यक्तिगत रूप से अन्य लोगों को अपनी आंखों से ऐसा करते देखा है। दी, केवल एक बार मैंने देखा कि किसी को उनके कोड को चलाने के बाद समस्या को खोजने में मदद की जरूरत है, लेकिन खराब परीक्षण कौशल के साथ ऐसा करने के लिए अधिक था।

— shimonyk

@shimonyk: तो मूल रूप से आपके अवलोकन मेरे दावे का समर्थन करते हैं कि यह समस्या असंगत है? वैसे, व्यक्तिगत अवलोकन एक किस्से हैं, वे अनुभवजन्य साक्ष्य के रूप में नहीं गिने जाते हैं।

— कोनराड रूडोल्फ

@Konrad बहुत अच्छी तरह से, कृपया अपने स्रोतों का भी हवाला दें। मुझे लगता है कि आपके पास एक सहकर्मी की समीक्षा की गई है जो डबल-ब्लाइंड अध्ययन कर रहे हैं जिसे आप संदर्भित कर रहे हैं? यदि नहीं, तो केवल अन्य प्रमाणों की मांग करते हुए दूसरों को गलत साबित करने के प्रयास में अपने स्वयं के उपाख्यानों को फड़फड़ाने की तुलना में, सबसे अच्छे रूप में पाखंडी है। जैसा कि इस विषय पर आगे किसी ने लिखा है "यहाँ पर विपक्ष अपने दावे को साबित करने के लिए विपक्ष पर है, न कि मुझ पर इसे अस्वीकार करने के लिए"।

— shimonyk

Answer 9

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

"मुझे मत सोचो" सिर्फ उपयोगकर्ता-इंटरफेस, y'all ;-) पर लागू नहीं होता है

Comments

मैं ऐसा करता था, लेकिन मुझे इस तर्क से जीत मिली कि प्रोग्रामर को भाषा जानने की जरूरत है और उन्हें सोचने के लिए बनाया जाना चाहिए।

— kirk.burleson

मैं इसे आम शिष्टाचार मानता हूं ... अपने भविष्य के स्व।

— स्टीवन ए। लोव

Answer 10

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

इसके लिए, मैं कहता हूं "मैक्रोज़ का उपयोग न करें"। मैं यह भी कहता हूं, "अपने लानत कोड को सही ढंग से इंडेंट करें"। यह देखते हुए कि प्रोग्रामिंग के लिए उपयोग किए जाने वाले प्रत्येक टेक्स्ट एडिटर / आईडीई स्वचालित रूप से इंडेंटेशन कैसे करते हैं, यह ऐसा करना मुश्किल नहीं होना चाहिए। Emacs में कोड लिखते समय, मैं पहचानने के लिए ऑटो-इंडेंट का उपयोग करूंगा कि क्या मैंने पिछली पंक्ति में कुछ गलत लिखा है। कभी भी Emacs ने पंगा लेना शुरू कर दिया है, मुझे आमतौर पर पता है कि मैंने कुछ गलत किया है।

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

if (condition) {
    statement;
} // stupid extra brace looks ugly

फिर

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

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

Comments

यदि आप मैक्रोज़ लिखने जा रहे हैं, तो आपको उन्हें यह सुनिश्चित करने के लिए लिखना चाहिए कि उन्हें किसी भी तरह से बिना कोड के किसी भी हिस्से में डाला जा सकता है।

— कोव्वर

Answer 11

मैं ब्रेसिज़ (दूसरा रूप) के बिना दो-पंक्ति संस्करण का उपयोग करता हूं, लेकिन अंतरिक्ष को बचाने के लिए नहीं।

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

यदि मैं इस फॉर्म का उपयोग करता हूं, तो मैं यह सुनिश्चित करता हूं कि ifकथन से पहले और बाद में (या टिप्पणी के ऊपर ) एक खाली लाइन (या केवल एक ब्रेस युक्त लाइन ) मौजूद है। हालांकि यह एक नियम नहीं है जिसका मैं जानबूझकर पालन करता हूं, मैं इस प्रश्न को पढ़ने के बाद अब इसे नोटिस करता हूं।

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

नीचे कुछ उदाहरण दिए गए हैं जो बताते हैं कि मैं ifबयान के इस रूप का उपयोग कैसे करता हूं ।

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

Answer 12

ब्रेसिज़। हमेशा। मैं उनकी तरह का प्रशंसक हूं, क्योंकि यह कोड को कुछ स्थिरता देता है। और जैसा कि @dsimcha ने लिखा है - कोड की अतिरिक्त लाइनें जोड़ने में त्रुटियों के लिए कम मौका।

कोड की एकल पंक्ति के चारों ओर ब्रेसिज़ की "उथल-पुथल" अतिरिक्त काम की तुलना में कम हानिकारक है जो कि डिबगिंग और / या कोड जोड़ने के साथ उन मामलों में संभावित है।

Comments

मैंने कभी नहीं देखा कि कोई भी आपके द्वारा की जा रही त्रुटि को सुधार दे।

— kirk.burleson 3

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

— वेदरन क्रिवोकूसा

Answer 13

व्यक्तिगत रूप से मैं कोष्ठक के साथ जाता हूं।

क्यों?

अगर किसी के साथ आता है और अगर यह बयान में कोड जोड़ने की जरूरत है तो यह 100% स्पष्ट है कि गुंजाइश कहाँ है।

यह ifबयानों के प्रारूप को बनाए रखता है, चाहे ब्लॉक में कितने भी बयान हों।

हालाँकि, अगर प्रोजेक्ट स्टाइल बिना जाना है, तो उससे चिपके रहें।

Answer 14

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

if (x==5) Console.WriteLine("It's a five!");

Comments

किसी को लगता है कि संक्षिप्तता का प्रशंसक नहीं है।

— JohnFx

पठनीयता के लिए Brevity? बिलकुल नहीं। यह एक गोल्फ प्रतियोगिता नहीं बल्कि कोड है।

— जोश के

मुझे लगता है कि पठनीयता व्यक्तिगत रूप से संक्षिप्तता का एक बड़ा कारण है। किसी भी स्थिति में: मेरे कोड-गोल्फ नियम पुस्तिका में व्हाइट-स्पेस की गिनती नहीं है।

— जॉनफैक्स

इसके साथ एक समस्या यह है कि यह दुर्व्यवहार के लिए खुद को उधार देता है

— कॉनरेड फ्रीक्स

फिर इसका दुरुपयोग न करें। मैं यह नहीं कह रहा हूं कि इसे कोडिंग मानक के रूप में उपयोग करें। बहुत बार ऐसा होता है जब आपके पास वास्तव में एक छोटे से कथन के बाद एक छोटी शर्त होती है और यह अच्छी तरह से काम करता है। उदाहरण के लिए यदि (assert) log.write ("मुखर विफल");

— JohnFx

Answer 15

मैं स्थिरता के लिए ब्रेसिज़ पसंद करता हूं, लेकिन बहुत अधिक सफेद स्थान को बर्बाद नहीं करना (इसलिए मेरे सीमित क्षेत्र में अधिक आसानी से प्रारूपित कोड है)। इसलिए मैं इसे छोटी लाइनों के लिए लिखता हूं:

If (cond) { statement; }

Comments

दिलचस्प है, मैं वास्तव में इस तरह कोड नहीं देखता, लेकिन मुझे यह पसंद है।

— थॉमस ईडिंग जूल

Answer 16

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

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

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

Comments

आप बस आसानी से उपयोग कर सकते हैंreturn (obj != null) ? obj : "Error";

— जोश K

@ जोश, संपादित देखें

— स्वयं पर ध्यान दें -

उस मामले में मैं कुछ का उपयोग करेगा Object returnObj = defaultObj; /* Three else-if's to change it to obj1/2/3 */ return returnObj;।

— जोश के

@Josh, stackoverflow.com/questions/36707/… के माध्यम से पढ़ें । पहले उत्तर पर पहली टिप्पणी, "हालांकि कई निकास बिंदु हाथ से निकल सकते हैं, मुझे निश्चित रूप से लगता है कि यह एक IF ब्लॉक में आपके पूरे फ़ंक्शन को डालने से बेहतर है ।"

— स्वयं पर ध्यान दें -

Answer 17

यदि IDE में कोड स्वरूपण उपलब्ध है तो मैं ब्रेसिज़ का उपयोग नहीं करता हूं।

दूसरी ओर, जहां कोड को अन्य संपादकों में संपादित किया जा सकता है, जो ऑटो स्वरूपण का समर्थन नहीं करता है क्योंकि अन्य पदों में उल्लिखित ब्रेसिज़ को नहीं रखना खतरनाक है। लेकिन फिर भी मैं ब्रेसिज़ का उपयोग नहीं करना पसंद करता हूं, और यह मेरे लिए समस्या नहीं है।