कौन सा अधिक रखरखाव योग्य है - अगर / या बूलियन अभिव्यक्ति के माध्यम से बूलियन असाइनमेंट?

Question

जिसे अधिक रखरखाव योग्य माना जाएगा?

if (a == b) c = true; else c = false;

या

 c = (a == b);

मैंने कोड कंप्लीट में देखने की कोशिश की है, लेकिन जवाब नहीं मिल रहा है।

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

Comments

दो बराबर नहीं हैं। आपको else c = falseपहले के लिए या ||=दूसरे में असाइनमेंट करने की आवश्यकता है ।

मुझे लगता है कि आपको इस तथ्य के बारे में दो सम्पादन करने होंगे कि आप पहले प्रश्न का उत्तर दें!

— जेम्स

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

— एरिक किंग

वाह, क्या सी # देव वास्तव में पहले रूप को स्वीकार्य मानते हैं? यह ... उन पर मेरे विश्वास को गंभीरता से कम करता है। मेरे अनुभव में, बूलियन अभिव्यक्तियों की पूरी गलतफहमी पर पहले रूप में भारी संकेत का उपयोग।

— एंड्रेस एफ।

बस चीजों को दिलचस्प रखने के लिए, यहाँ एक और विकल्प है:c = a==b ? true : false;

— FrustratedWithFormsDesigner

Answer 1

दूसरा विकल्प बेहतर है।

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

हालाँकि, मैं c = (a == b);एक चतुर चाल का उदाहरण नहीं मानता । यह एक सरल अवधारणा का सीधा प्रतिनिधित्व है। जैसे-जैसे आगे-आगे हो सकते हैं।

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

if (a == b)
{
    c = true; 
}
else 
{
    c = false;
}

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

Answer 2

सबसे पहले, महसूस करें कि आपके दो रूप समतुल्य नहीं हैं।

if (a == b) c = true;

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

c = (a == b);

cसत्य के लिए सेट किया जाएगा यदि aबराबर है b, और यदि नहीं, तो यह गलत पर सेट किया जाएगा।

यदि आप पहले फॉर्म की शैली में दूसरे फॉर्म के बराबर चाहते हैं, तो आपको इसे इस तरह से लिखना होगा:

if (a == b) {
  c = true;
} else c = false;

अब यह स्पष्ट है कि दोनों में से कौन सा अधिक पठनीय, अधिक रख-रखाव करने वाला है, और अगर कुछ बदला है, तो बग को पेश करने की संभावना कम है। दूसरे रूप के साथ रहना।

Comments

बिल्कुल सही - मैंने अपना प्रश्न अपडेट कर लिया है।

— ब्रेट वॉकर

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

— मोनिका को पुनः स्थापित करें - एम। श्रोडर 12

Answer 3

मैं असहमत हूँ कि आपका पहला रूप अधिक पठनीय है - यह निश्चित रूप से मुहावरेदार नहीं है C # एक पंक्ति में दो कथन हैं, और यह ifब्रेसिज़ का उपयोग किए बिना एक बयान के लिए अनुशंसित नहीं है।

दूसरी बात, मैं यह नहीं देखता कि दूसरा रूप किस तरह से कम बनाए रखा जा सकता है - बनाए रखने के लिए कुछ भी नहीं है। यह के बीच संबंधों का एक सरल बयान है aऔर bऔर यह किसी भी अधिक बस व्यक्त नहीं किया जा सकता है।

दूसरे रूप को पसंद करने का एक और कारण यह है कि आप cइसे एक ही कथन में घोषित और असाइन कर सकते हैं

bool c = (a == b);

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

Comments

मैंने छद्म कोड के रूप में एक पंक्ति में दो कथन पढ़े

— जिमी हॉफ

+1 के लिए " Another reason to prefer the second form is that you can declare c and assign it in a single statement"

— एन्ड्रेस एफ।

Answer 4

"अधिक बनाए रखने योग्य" बहुत व्यक्तिपरक हो सकता है।

मैं आमतौर पर कोड की कमी पर पठनीयता और इरादा पसंद करता हूं। मुझे लगता है कि आप कम फ़ॉर्म का उपयोग करके 8 टाइप किए गए पात्रों को बचाते हैं।

भाषा और संस्कृति को भाषा के आसपास ले जाना मेरे विचार में 'पठनीयता' की विशेषता है।

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

Comments

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

पहले फॉर्म में कम से कम 1 बग था जिसे ठीक करने की जरूरत थी, इसकी क्रिया में छिपा हुआ था। दूसरा रूप सरल और बिंदु तक था, और कोई बग नहीं था। बस इतना ही कहना चाहता हूं। किसी भी मामले में, मुख्य उद्देश्य कम वर्ण टाइप करना नहीं था! और यह सवाल प्रदर्शन के बारे में बिल्कुल नहीं था, जो इस मामले में अप्रासंगिक है।

— एंड्रेस एफ।

@delnan बिल्कुल मेरी बात, Duh। किसी की कोड कमी किसी और की स्पष्टता है। मैंने प्राथमिक चिंता के रूप में अनुकूलन का हवाला नहीं दिया ... मैंने इसे एक उदाहरण के रूप में इस्तेमाल किया। चतुर चालें जोड़ने या आदर्श से बाहर जाने का आपका कारण आपके द्वारा जो भी / संस्कृति / उद्यम को पठनीय माना जाएगा, उसे संतुलित किया जाना चाहिए।

— जॉनी

एक साफ बूलियन अभिव्यक्ति लिखना एक चतुर चाल नहीं है!

— एंड्रेस एफ।

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

— जॉनी डेसी

Answer 5

द्वितीय। इसमें कम पुनरावृत्ति (DRY) है और यह समझना आसान है कि क्या चल रहा है, जो cमान रखता है या नहीं aऔर bबराबर हैं।

IMHO, और भी बेहतर होगा

c = a == b

जैसा लिखूंगा वैसा लिखूंगा

• 1 + 2 + 3 के बजाय ((1 + 2) + 3)
• 5 + 3 * 7 के बजाय (5 + (3 * 7))

जाहिर है और तुच्छ अनावश्यक कोड एक गुण नहीं है। यह बरबाद है।

Answer 6

डाउन-वोटर्स, कृपया विस्तृत करें कि मेरे संशोधित उत्तर में क्या गलत है।

हां, c = (a == b);पढ़ना मुश्किल हो सकता है (अभी तक, स्टाइलकोप अनावश्यक कोष्ठक के बारे में शिकायत करता है), लेकिन मुझे अभी भी सरलता पसंद है a == b। इसलिए, यहाँ है कि मुझे क्या उपयोग करना पसंद है जब दोनों aऔर bसमान हैं:

private static bool NoPeriod
{
    get
    {
        return this.MyWaveLength == this.HerWaveLength;
    }
}

और फिर आप कर सकते हैं: के this.c = this.NoPeriodबजाय:

this.c = this.MyWavelength == this.HerWaveLength;

Comments

तो आपका मतलब return this.MyWaveLength = this.HerWaveLength;या return this.MyWaveLength == this.HerWaveLength;था?

— जेसी सी। स्लाइसर

क्या!? c = (a == b);त्रुटि-प्रवण नहीं है। मूल प्रश्न में पहला रूप रास्ता अधिक त्रुटि प्रवण है , जैसा कि ओपी ने खुद को कीड़े को ठीक करने के लिए अपने प्रश्न को संपादित करने के लिए प्रदर्शित किया है!

— एंड्रेस एफ।

मुझे लगता है कि आपके सुझाए गए समाधान में बग = बनाम == है

— ओन्ड्रा

@Ondra Morský, धन्यवाद ... संकलक ने मेरे लिए इसे पकड़ा होगा।

— अय्यूब

मैं स्टाइलकॉप से ​​परिचित नहीं हूं, लेकिन अगर यह बताता है कि अनावश्यक कोष्ठक खराब हैं, तो आपको इसे बंद कर देना चाहिए। संकलक के लिए अनावश्यक कोष्ठक आवश्यक नहीं हैं, लेकिन वे मानव आंखों के लिए बहुत, बहुत अच्छे हो सकते हैं। यदि आपने c = a = b लिखा है; संकलक यह ठीक समझ सकता है, लेकिन यह मानव के लिए कठिन है।

— माइकल शॉ