क्या मुझे तार्किक बयानों में कोष्ठक का उपयोग करना चाहिए जहां आवश्यक नहीं है?

100

मान लीजिए कि मेरे पास एक बूलियन स्थिति है a AND b OR c AND dऔर मैं एक ऐसी भाषा का उपयोग कर रहा हूं, जहां ANDऑपरेशन की एक उच्चतर मिसाल है OR। मैं कोड की यह पंक्ति लिख सकता था:

If (a AND b) OR (c AND d) Then ...

लेकिन वास्तव में, इसके बराबर है:

If a AND b OR c AND d Then ...

क्या इसमें या बाहर के कोष्ठकों को शामिल करने का कोई तर्क है? क्या व्यावहारिक अनुभव बताता है कि यह पठनीयता के लिए उनके लायक है? या यह एक संकेत है कि एक डेवलपर को अपनी भाषा की मूल बातों में वास्तव में बैठकर आश्वस्त होने की आवश्यकता है?

coding-style operator-precedence

— जेफ ब्रिजमैन
स्रोत

90

मैं आलसी हो सकता हूं, लेकिन मैं पठनीयता के लिए ऐसी अधिकांश स्थितियों में कोष्ठक रखना पसंद करता हूं।

— वोरस्टेन मुलर

6

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

— जेफ ब्रिजमैन

16

कोष्ठक का अच्छा उपयोग व्याकरण के अच्छे उपयोग की तरह है। 2 * 3 + 2जैसा हो सकता है (2 * 3) + 2लेकिन दूसरा पढ़ना आसान है।

— रिएक्टगुलर

16

@ मैथ्यू अगर आप मैथ्स में कमजोर हैं। अधिक जटिल मामलों के लिए, सुनिश्चित करें, कोष्ठक का उपयोग करें। लेकिन स्पष्ट रूप से स्पष्ट लोगों (BODMAS ...) के लिए वे अव्यवस्था के कारण इसकी सहायता से पठनीयता को कम करते हैं ।

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

3

उन्होंने कहा कि बेसिक, पाइथन, एसक्यूएल में AND / OR की एक ही मिसाल है ... मेरी धारणा है कि आधुनिक भाषाओं के विशाल बहुमत में यह नियम है (यद्यपि सभी नहीं)।

— टिम गुडमैन

117

अच्छे डेवलपर्स कोड लिखने का प्रयास करते हैं जो स्पष्ट और सही है । सशर्त में कोष्ठक, भले ही वे कड़ाई से आवश्यक न हों, दोनों के साथ मदद करें।

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

वे कोड को समझने के लिए आवश्यक कार्य को कम करते हैं।
वे डेवलपर के इरादे की पुष्टि प्रदान करते हैं।

इसके अलावा, अतिरिक्त कोष्ठक, बस इंडेंटेशन, व्हॉट्सएप और अन्य शैली मानकों की तरह, तार्किक तरीके से कोड को व्यवस्थित करने में मदद करते हैं।

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

और यहां तक कि अगर आप इसे सही पाते हैं, तो आपके कोड पर काम करने वाला अगला व्यक्ति या तो अभिव्यक्ति में त्रुटियां जोड़ सकता है या आपके तर्क को गलत समझ सकता है और इस प्रकार त्रुटियों को कहीं और जोड़ सकता है (जैसा कि LarsH सही तरीके से बताता है)।

मैं हमेशा भाव है कि गठबंधन के लिए कोष्ठक का उपयोग andऔर or(समान पूर्वता मुद्दों के साथ अंकगणितीय आपरेशनों के लिए और भी)।

— user82096
स्रोत

3

हालांकि, मैंने सुना है कि यह कहा गया है कि टिप्पणियां माफी (बुरे / कठिन-से-पढ़ने के लिए कोड) हैं ... एक अच्छा मौका है जो आप इसे बेहतर लिख सकते थे। मुझे लगता है कि आप कोष्ठक के बारे में ऐसी ही बातें कह सकते हैं।

— जेफ ब्रिजमैन ने

6

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

— लार्स

1

@ लार्स, धन्यवाद, मैंने इसे स्पष्ट रूप से उत्तर में जोड़ दिया।

8

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

— मैट्नज़

2

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

— डैनियल बी

94

यह कम मायने रखता है कि क्या आप अपनी भाषा पर विश्वास कर रहे हैं। जो बात ज्यादा मायने रखती है वह है n00b की भाषा की समझ जो आपके पीछे है।

संभव सबसे स्पष्ट तरीके से अपने कोड को लिखें। अतिरिक्त कोष्ठक अक्सर (लेकिन हमेशा नहीं) मदद करते हैं। लाइन पर केवल एक स्टेटमेंट डालने से अक्सर मदद मिलती है। कोडिंग शैली में सुसंगतता अक्सर मदद करती है।

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

— Dan Pichelman
स्रोत

72

यह मत भूलो कि भले ही आप बीमार हों, जब आप बीमार हों, या पिछले साल लिखे गए कोड से निपट रहे हों; आपकी समझ का स्तर n00b से कम हो गया है।

— दान नीली

30

There is such a thing as too many parenthesis- आप स्पष्ट रूप से एक lisper नहीं कर रहे हैं;)

— पॉल

18

यह बुरी सलाह है: नोब्स के लिए न लिखें। इससे आपकी कोड गुणवत्ता कम हो जाएगी (काफी) क्योंकि आप अच्छी तरह से स्थापित मुहावरों का उपयोग नहीं कर सकते हैं जो शुरुआती किताब के पहले दो अध्यायों से परे हैं।

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

10

@KonradRudolph: शायद ऐसा हो, लेकिन केवल उन लोगों के लिए मत लिखिए, जो कंप्यूटर प्रोग्रामिंग की कला को कवर से कवर करने के लिए जानते हैं, या बाद में अपने कोड को डिबग करने के लिए तैयार रहें, और इस बात का कोई सुराग नहीं है कि आपने इस तरह से चीजें क्यों कीं । कोड बहुत अधिक पढ़ा गया है जितना लिखा है।

— ज्येष्ठ

15

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

— ब्रेंडन

31

हाँ

आपको हमेशा कोष्ठक का उपयोग करना चाहिए ... आप पूर्वता के क्रम को नियंत्रित नहीं करते हैं ... संकलक का विकास करता है। यहाँ एक कहानी है जो मुझे कोष्ठक के गैर-उपयोग के बारे में हुई। इसने दो सप्ताह की अवधि में सैकड़ों लोगों को प्रभावित किया।

वास्तविक विश्व कारण

मुझे मेन-फ्रेम एप्लीकेशन विरासत में मिली। एक दिन, साफ नीले रंग से बाहर काम करना बंद कर दिया। यह बात है ... poof यह बस बंद कर दिया।

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

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

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

जैसा कि मैंने धीरे-धीरे इसे साफ करना शुरू कर दिया है, मैं समय-समय पर अपने काम को बचाऊंगा। एक बिंदु पर मैंने कोड को संकलित करने की कोशिश की और एक अजीब बात खुशी हुई। त्रुटि ने छलांग लगा दी थी कि वह कोड की मूल पंक्ति को पार कर गया था और अब नीचे आ गया था। तो मैं जारी रखा, ANDऔर ORparens के साथ शर्तों speparating । जब मैंने सफाई की तो यह काम कर गया। जाओ पता लगाओ।

मैंने तब संचालन की दुकान का दौरा करने और उनसे पूछने का फैसला किया कि क्या उन्होंने हाल ही में मुख्य-फ्रेम पर कोई नया घटक स्थापित किया है। उन्होंने कहा कि हां, हमने हाल ही में कंपाइलर को अपग्रेड किया है। Hmmmm।

यह पता चला है कि पुराने संकलक ने बिना किसी परवाह के बाएं से दाएं की अभिव्यक्ति का मूल्यांकन किया। संकलक के नए संस्करण ने भी बाएं से दाएं लेकिन अस्पष्ट कोड के भावों का मूल्यांकन किया, जिसका अर्थ अस्पष्ट संयोजन है ANDऔर ORइसे हल नहीं किया जा सकता है।

सबक मैंने इससे सीखा है ... ALWAYS, ALWAYS, ALWAYS अलग-अलग ANDस्थितियों और ORस्थितियों के लिए पैरेन्स का उपयोग करते हैं जब वे एक दूसरे के साथ संयोजन में उपयोग किए जाते हैं।

सरलीकृत उदाहरण

IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...(इनमें से कई के साथ कोडित)

यह एक सरल संस्करण है जो मैंने सामना किया। कंपाउंड बूलियन लॉजिक स्टेटमेंट के साथ और भी स्थितियां थीं।

मुझे याद है कि इसका पीछा करना:
IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...

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

— माइकल रीली - एकेए गनी का पता चलता है
स्रोत

22

ऐसा लगता है कि एक अच्छा संकलक होना एक बेहतर चित्रण क्यों है।

— ruakh

6

@CapeCodGunny: मुझे यकीन है कि आपने नहीं किया। लेकिन यहाँ समस्या यह है कि आपके पास एक खराब संकलक विक्रेता था जिसने एक ब्रेकिंग परिवर्तन किया। मैं यह नहीं देखता कि आपने "एलेवेयस, ऑलवेज्स, ऑल्वेज़" को एक सबक कैसे सीखा है, उस समस्या के इर्द-गिर्द, यहां तक कि जब भी अन्य बॉयलर का उपयोग किया जाता है।

— बर्बाद

5

@ruakh - नहीं, विक्रेता ने अपना कोड पार्सर बदल दिया है। मैं पुराना स्कूल हूं, मैं अपनी हर प्रणाली को याद रखने की अपनी क्षमता पर भरोसा नहीं करता, जिसे मैंने कोडित किया है या उसमें शामिल रहा हूं। आपके सभी दस्तावेज के बिना स्रोत कोड है। जब स्रोत कोड को पढ़ना और उसका पालन करना कठिन होता है, तो यह एक अत्यंत तनावपूर्ण स्थिति पैदा करता है। प्रोग्रामर जो व्हाट्सएप का उपयोग नहीं करते हैं, उन्हें शायद कभी भी ऐसी स्थिति से जूझना नहीं पड़ा था, जिस तरह से मैं सामना कर रहा था। मैंने यह भी सीखा कि यह कोड लिखने के लिए अधिक समझ में आता है जैसे: सी डिक; जेन को देखें; डिक और जेन देखें; सरल कथन जिन्हें पढ़ना आसान है ... टिप्पणी करें ... और अनुसरण करें।

— माइकल रिले - AKA Gunny

2

महान कहानी, लेकिन मैं सहमत हूं कि यह कोष्ठक का उपयोग करने का कारण नहीं है। और / या पूर्वता लगभग सार्वभौमिक है और कम से कम संभावना के बारे में बदलने के लिए जिसे कोई सोच भी नहीं सकता था। यदि आप इस तरह के एक मानक, बुनियादी ऑपरेशन के लिए निरंतर व्यवहार पर भरोसा नहीं कर सकते हैं, तो आपका कंपाइलर कचरा है और आपको कोई फर्क नहीं पड़ता कि आप क्या करते हैं। आपकी कहानी 100% एक कंपाइलर समस्या है और 0% एक कोड समस्या है। विशेष रूप से यह देखते हुए कि डिफ़ॉल्ट व्यवहार सरल बाएं से दाएं मूल्यांकन था - आदेश हमेशा स्पष्ट होगा, इसलिए कोई भी कोष्ठक का उपयोग क्यों करेगा?

7

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

— लार्स

18

हां, अगर मिश्रित हैं 'और' और 'या'।

इसके अलावा अच्छी तरह से () तार्किक रूप से एक चेक है।

हालांकि सबसे अच्छा है नामांकित विधेय कार्यों का उपयोग करना और सरल और पठनीय होने के बावजूद, अधिकांश चेक और शर्तों को बेदखल करना।

— बालोग पाल
स्रोत

6

सच है, एक बहुत अच्छा मौका है a AND bशायद इसे या तो एक फ़ंक्शन या पूर्व-परिकलित बूलेन मान के साथ प्रतिस्थापित किया जाना चाहिए जिसमें अधिक वर्णनात्मक नाम है।

— जेफ ब्रिजमैन ने

14

कोष्ठक शब्दार्थ निरर्थक हैं, इसलिए संकलक परवाह नहीं करता है, लेकिन यह एक लाल हेरिंग है - वास्तविक चिंता प्रोग्रामर पठनीयता और समझ है।

मैं यहां कट्टरपंथी पद लेने जा रहा हूं और कोठरी में हार्दिक को "नहीं" दूंगा a AND b OR c AND d। हर प्रोग्रामर को दिल से जानना चाहिए कि बूलियन एक्सप्रेशन में पूर्वगामी नहीं> और> या , याद रखने की तरह कृपया बीजीय भाव के लिए माई डियर आंटी सैली को क्षमा करें । निरर्थक विराम चिह्नों में प्रोग्रामर पठनीयता में कोई लाभ नहीं होने के कारण कोड में अधिकांश समय दृश्य अव्यवस्था होती है।

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

मैं इस तरह के सी, में सूचक अभिव्यक्ति के रूप में बीजगणित (बूलियन या नहीं), के दायरे के बाहर कुछ भी के लिए एक अपवाद बनाना होगा जहां कुछ भी की तरह मानक मुहावरों से अधिक जटिल *p++या p = p->nextशायद अपसंदर्भन और गणित सीधे रखने के लिए parenthesized किया जाना चाहिए। और, बेशक इनमें से कोई भी लिस्प, फोर्थ या स्मॉलटाक जैसी भाषाओं पर लागू नहीं होता है जो अभिव्यक्ति के लिए पोलिश संकेतन के कुछ रूप का उपयोग करते हैं; लेकिन अधिकांश मुख्यधारा की भाषाओं के लिए, तार्किक और अंकगणित पूर्वता पूरी तरह से मानकीकृत है।

— dodgethesteamroller
स्रोत

1

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

— टिम गुडमैन

1

सभी भाषाओं मैं के साथ काम में नियमित रूप से यह .memberपहले एकल ऑपरेटरों, एकल द्विआधारी ऑपरेटरों से पहले, *और /पहले +और -पहले <और >और ==से पहले &&से पहले ||काम से पहले। उन नियमों को याद रखना आसान है क्योंकि वे मेरे "सामान्य ज्ञान" से मेल खाते हैं कि ऑपरेटरों को सामान्य रूप से कैसे उपयोग किया जाता है (उदाहरण के लिए, आप काम करने की ==तुलना में अधिक पूर्वता नहीं देते हैं +या 1 + 1 == 2काम करना बंद कर देते हैं), और वे पूर्ववर्ती प्रश्नों के 95% हिस्से को कवर करेंगे। ।

— टिम गुडमैन

4

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

— डोडगेटेस्टेमोलर

8

जैसा की मैं देख पा रहा हूँ:

हाँ पेशेवरों:

संचालन का आदेश स्पष्ट है।
आपको भविष्य के डेवलपर्स से बचाता है जो संचालन के आदेश को नहीं समझते हैं।

हाँ विपक्ष:

कोड को पढ़ने में कठिनाई का परिणाम हो सकता है

कोई पेशेवरों:

?

कोई विपक्ष:

संचालन का आदेश निहित है
कोड संचालन के क्रम की अच्छी समझ के बिना डेवलपर्स के लिए कम रखरखाव योग्य है।

— MetaFight
स्रोत

अच्छी तरह से कहा, हालांकि मुझे लगता है कि "अव्यवस्था में परिणाम हो सकता है, कोड को पढ़ना मुश्किल है" बल्कि व्यक्तिपरक है।

— FrustratedWithFormsDesigner

2

आपके कोड के शब्दार्थ को स्पष्ट रूप से पढ़ने में कठिनाई कैसे होती है?

— मेसन व्हीलर

1

मैं आपके "यस कंसल" पर सवाल उठाने के लिए दूसरों से सहमत हूं। मुझे लगता है कि यह लगभग हमेशा विपरीत है।

@ दावा विपरीत के रूप में व्यक्तिपरक के रूप में दिया। मतलब, बिल्कुल नहीं। बस मापना मुश्किल है।

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

1

@MasonWheeler: जब मैं सहमत हूं कि स्पष्ट मामले कई मामलों में स्पष्ट हैं, तो मैं देख सकता हूं कि शब्दार्थ को स्पष्ट करने के लिए कोई कैसे ओवरबोर्ड जा सकता है। मुझे 3 * a^2 + 2 * b^2पढ़ने में आसान लगता है (3 * (a^2)) + (2 * (b^2)), क्योंकि प्रारूप और पूर्वता परिचित और मानक है। इसी तरह, आप अपने कोड के शब्दार्थ को और अधिक स्पष्ट करने के लिए कार्यों और मैक्रोज़ (या संकलक!) के उपयोग को मना कर सकते हैं। जाहिर है मैं इसकी वकालत नहीं कर रहा हूं, लेकिन मैं आपके प्रश्न का उत्तर देने की उम्मीद कर रहा हूं कि चीजों को स्पष्ट करने पर सीमाएं (संतुलन) की आवश्यकता क्यों है।

— लार्स

3

क्या इसमें या बाहर के कोष्ठकों को शामिल करने का कोई तर्क है? क्या व्यावहारिक अनुभव बताता है कि यह पठनीयता के लिए उनके लायक है? या यह एक संकेत है कि एक डेवलपर को अपनी भाषा की मूल बातों में वास्तव में बैठकर आश्वस्त होने की आवश्यकता है?

अगर किसी और को कभी भी मेरे कोड को फिर से नहीं देखना होगा, तो मुझे नहीं लगता कि मुझे परवाह होगी।

लेकिन, मेरे अनुभव से:

मैं अपने कोड को कभी-कभार देखता हूं (कभी-कभी इसे लिखने के वर्षों बाद)
अन्य कभी-कभी मेरे कोड को देखते हैं
- या यहां तक कि इसे विस्तार / ठीक करना है!
न तो खुद को और न ही दूसरे को याद है कि इसे लिखते समय मैं क्या सोच रहा था
क्रिप्टिक लिखना "वर्ण गणना को छोटा करें" कोड पठनीयता को नुकसान पहुंचाता है

मैं लगभग हमेशा ऐसा करता हूं क्योंकि मुझे अपनी क्षमता पर भरोसा है कि जल्दी से पढ़ो और कुछ नहीं की तुलना में थोड़ी गलतियों को बहुत अधिक कर दो।

आपके मामले में, मैं लगभग कुछ ऐसा करने का आश्वासन दे सकता हूं:

if (a AND b) then ab = true
if (c AND d) then cd = true
If (ab OR cd) Then ...

हाँ, यह अधिक कोड है। हां, मैं बदले में फैंसी बूल ऑपरेटर कर सकता हूं। नहीं, मुझे मौका नहीं पसंद है जब भविष्य में कोड 1+ वर्ष को कम करके मैं फैंसी बूल ऑपरेटरों को गलत करता हूं। क्या होगा अगर मैं एक ऐसी भाषा में कोड लिख रहा था जिसमें अलग और / या पूर्वता थी और इसे ठीक करने के लिए वापस कूदना पड़ा? क्या मैं जाने वाला हूँ, "अहा! मुझे यह चतुर छोटी सी बात याद है जो मैंने की थी! मुझे पिछले साल जब मैंने लिखा था तो मुझे इसमें शामिल नहीं होना था, अच्छी बात है कि मुझे अब याद है!" अगर ऐसा होता है (या इससे भी बदतर, कोई और जो इस चतुराई से वाकिफ नहीं था या उसे "फिक्स एसैप" टाइप स्थिति में फेंक दिया गया था)?

के साथ अलग करना () यह इतना अधिक सीधा बनाता है जल्दी से स्किम और बाद में समझने के लिए ...

— enderland
स्रोत

7

यदि आप ऐसा करने जा रहे हैं, तो क्यों नहीं ab = a AND b?

— एरिक

1

शायद abनहीं तो अपरिवर्तित रहेगा a AND b।

— आर्मली

3

सामान्य मामला

C # में, गुणा और भाग में जोड़ और घटाव की पूर्वता होती है।

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

var a = 1 + 2 * 3;

यह स्पष्ट है कि परिणाम है 7और नहीं 9, लेकिन फिर भी, स्टाइलकॉप को कोष्ठक लगाने का सुझाव है:

var a = 1 + (2 * 3);

आपका विशेष मामला

आपके विशेष मामले में, आपके द्वारा उपयोग की जाने वाली विशेष भाषा में OR की तुलना में AND की पूर्वता है।

ऐसा नहीं है कि हर भाषा कैसे व्यवहार करती है। कई अन्य इलाज करते हैं और समान रूप से।

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

यह विशिष्टता और जोखिम जो कुछ डेवलपर्स का मानना हो सकता है कि AND और OR की समान प्राथमिकता है, इससे कोष्ठक जोड़ना और भी महत्वपूर्ण हो जाता है।

एक लक्ष्य के साथ कोड न लिखें, यह दिखाने के लिए कि आप स्मार्ट हैं। उन लोगों सहित, जो भाषा के हर पहलू से परिचित नहीं हो सकते हैं, पठनीयता के लक्ष्य के साथ कोड लिखें।

— आर्सेनी मूरज़ेंको
स्रोत

1

"यह बहुत असामान्य है": स्ट्रॉस्ट्रुप2013 के अनुसार, C ++ 11 को AND और OR (पृष्ठ 257) की अलग-अलग पूर्वता प्रतीत होती है। पाइथन के लिए समान: docs.python.org/2/reference/expressions.html

— डिर्क

10

पुन: "हर भाषा मैं जानता हूँ कि इलाज और समान रूप से": मुझे संदेह है कि यह सच है। यदि यह है सच है, तो आप नहीं जानते कि किसी भी की दस सबसे लोकप्रिय भाषाओं (सी, जावा, सी ++, पीएचपी, जावास्क्रिप्ट, अजगर, सी #, पर्ल, एसक्यूएल, और रूबी), और पर टिप्पणी किए जाने की कोई स्थिति में हैं क्या "असामान्य" है, अकेले "बहुत असामान्य" है।

— ruakh

1

मैं रुख से सहमत हूं और इसे C ++ 11, अजगर, मतलूब और जावा के लिए देखा।

— डिर्क

3

ऐसी भाषाएं जिनमें AND और OR द्विआधारी संचालक हैं, और जो इलाज नहीं करती हैं और OR की तुलना में एक उच्च मिसाल हैं, वे ब्रिंडामेडेड बकवास हैं, जिनके लेखक कंप्यूटर विज्ञान के फंक हैं। यह तर्क संकेतन से आता है। नमस्कार, "उत्पादों का योग" कुछ भी मतलब नहीं है? यहां तक कि एक बूलियन संकेतन भी है जो AND के लिए गुणन (कारकों का गुणक) और + के लिए + प्रतीक का उपयोग करता है।

— कज़

3

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

— dodgethesteamroller

1

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

— होन्जा ब्रेबेक
स्रोत

0

या यह एक संकेत है कि एक डेवलपर को अपनी भाषा की मूल बातों में वास्तव में बैठकर आश्वस्त होने की आवश्यकता है?

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

क्या आपको इन भाषाओं में से प्रत्येक के लिए सटीक पूर्वता के नियम याद हैं, बिना देखे?

— सुरक्षित
स्रोत

1

और जैसा कि @Cape कॉड गनी ने ऊपर उल्लेख किया है, भले ही आपको लगता है कि आप भाषा को ठंडा जानते हैं, संकलक / रन-टाइम आपके नीचे बदल सकता है।