एक-पंक्ति के कार्य जिन्हें केवल एक बार कहा जाता है

Question

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

यह एक क्वेरी कर सकता है, कुछ मूल्यों की जांच कर सकता है, कुछ regex को शामिल कर सकता है ... कुछ भी अस्पष्ट या "हैकी"।

इसके पीछे तर्क यह होगा कि मुश्किल से पढ़े जाने वाले मूल्यांकन से बचें:

if (getCondition()) {
    // do stuff
}

getCondition()एक-पंक्ति फ़ंक्शन कहां है।

मेरा सवाल बस यह है: क्या यह एक अच्छा अभ्यास है? यह मेरे लिए ठीक लगता है लेकिन मुझे दीर्घकालिक के बारे में नहीं पता है ...

Comments

जब तक आपके कोड का टुकड़ा ओओपी भाषा से नहीं होता है, तो निहित रिसीवर (जैसे यह) यह निश्चित रूप से एक बुरा अभ्यास होगा, जैसा कि getCondition () सबसे अधिक वैश्विक स्थिति पर निर्भर करता है ...

— इंगो

उसका मतलब यह हो सकता है कि getCondition () में तर्क हो सकते हैं?

— user606723

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

— जेम्स एंडरसन

आप सिर्फ इनलाइन क्यों नहीं करते getCondition? यदि यह उतना ही छोटा और असीम रूप से उपयोग किया जाता है जैसा कि आप कहते हैं कि यह तो यह एक नाम दे रहा है कुछ भी पूरा नहीं कर रहा है।

— davidk01

davidk01: कोड पठनीयता।

— wjl

Answer 1

उस एक लाइन पर निर्भर करता है। यदि रेखा पठनीय और स्वयं द्वारा संक्षिप्त है, तो फ़ंक्शन की आवश्यकता नहीं हो सकती है। सरल उदाहरण:

void printNewLine() {
  System.out.println();
}

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

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isFemale() 
        && (taxPayer.getNumberOfChildren() > 2 
        || (taxPayer.getAge() > 50 && taxPayer.getEmployer().isNonProfit()));
}

Comments

+1। यहाँ जादू शब्द "स्व-दस्तावेजीकरण कोड" है।

— कोनमन

अंकल बॉब को "इनकंप्लिमेंटिंग कंडीशन्स" का एक अच्छा उदाहरण।

— एंथनी पेग्राम

@ आदित्य: कुछ भी नहीं कहता है कि taxPayerइस परिदृश्य में वैश्विक है। शायद यह वर्ग है TaxReturn, और taxPayerएक विशेषता है।

— एडम रॉबिन्सन

इसके अतिरिक्त यह आपको फ़ंक्शन को इस तरह से दस्तावेज़ करने की अनुमति देता है जिसे उदाहरण के लिए javadoc द्वारा उठाया जा सकता है और सार्वजनिक रूप से दिखाई दे सकता है।

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

— अक्टूबर को Péter Török

Answer 2

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

startIgnition();
petrolFlag |= 0x006A;
engageChoke();

इस मामले में निश्चित रूप से मध्य रेखा को समझदारी से नामित फ़ंक्शन में स्थानांतरित करना बेहतर है।

Comments

यह 0x006A प्यारा है: डीए एडिटिव्स के साथ कार्बोनेटेड ईंधन की अच्छी तरह से ज्ञात निरंतरता है, बी और सी।

— कोडर

+1 मैं स्व-दस्तावेजीकरण कोड के लिए सभी हूं :) वैसे, मुझे लगता है कि मैं ब्लॉकों के माध्यम से एक निरंतर अमूर्त स्तर रखने पर सहमत हूं, लेकिन मैं यह नहीं बता सकता कि क्यों। क्या आप इसका विस्तार करना चाहेंगे?

— vemv

यदि आप केवल यह कह रहे हैं कि petrolFlag |= 0x006A;किसी भी प्रकार के निर्णय लेने के बिना, बस एक अतिरिक्त कार्य के petrolFlag |= A_B_C; बिना कहना बेहतर होगा । निश्चित रूप से , engageChoke()केवल तभी बुलाया जाना चाहिए जब petrolFlagएक निश्चित मानदंडों को पूरा किया जाए और यह स्पष्ट रूप से कहा जाए कि 'मुझे यहां एक समारोह की आवश्यकता है।' बस एक छोटी सी निट, इस सवाल का जवाब मूल रूप से पर अन्यथा स्थान है :)

— टिम पोस्ट

+1 एक विधि के भीतर उस कोड को इंगित करने के लिए समान अमूर्त स्तर में होना चाहिए। @vemv, यह अच्छा अभ्यास है क्योंकि यह कोड को पढ़ने के दौरान अपने दिमाग को कूदने और अलग-अलग स्तरों के बीच नीचे-नीचे जाने की आवश्यकता से बचकर कोड को समझने में आसान बनाता है। विधि कॉल / रिटर्न (यानी संरचनात्मक "कूद") के लिए अमूर्त स्तर के स्विच को बांधना कोड को अधिक धाराप्रवाह और स्वच्छ बनाने का एक अच्छा तरीका है।

— पेटर तोर्क

नहीं, यह पूरी तरह से बना हुआ मूल्य है। लेकिन जो तथ्य आपको आश्चर्यचकित करता है, वह सिर्फ इस बिंदु पर जोर देता है: यदि कोड ने कहा था mixLeadedGasoline(), तो आपको नहीं करना होगा!

— किलन फ़ॉथ

Answer 3

मुझे लगता है कि कई मामलों में ऐसा कार्य अच्छी शैली है, लेकिन आप स्थानीय बूलियन चर को उन मामलों में वैकल्पिक मान सकते हैं, जब आपको इस स्थिति का उपयोग कहीं और करने की आवश्यकता नहीं है जैसे:

bool someConditionSatisfied = [complex expression];

यह कोड रीडर को एक संकेत देगा और एक नया फ़ंक्शन शुरू करने से बचाएगा।

Comments

बूल विशेष रूप से फायदेमंद होता है यदि स्थिति फ़ंक्शन नाम मुश्किल या संभवतः भ्रामक होगा (जैसे IsEngineReadyUnlessItIsOffOrBusyOrOutOfService)।

— dbkk

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

— वुल्फ

@Wolf OTOH, मैं कोड के "अमूर्त गहराई" को कम करने के लिए एक फ़ंक्शन कॉल के लिए इसे पसंद करता हूं। IMO, एक फ़ंक्शन में कूदना कोड के एक स्पष्ट और प्रत्यक्ष युगल लाइनों की तुलना में एक बड़ा संदर्भ स्विच है, खासकर अगर यह सिर्फ एक बूलियन देता है।

— कैश

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

— वुल्फ

Answer 4

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

पीटर के उदाहरण के बाद, यदि यह

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isFemale() 
        && (taxPayer.getNumberOfChildren() > 2 
        || (taxPayer.getAge() > 50 && taxPayer.getEmployer().isNonProfit()));
}

यह बन जाता है

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isMutant() 
        && (taxPayer.getNumberOfThumbs() > 2 
        || (taxPayer.getAge() > 123 && taxPayer.getEmployer().isXMan()));
}

आप एकल संपादन करते हैं और यह सार्वभौमिक रूप से अपडेट किया गया है। बनाए रखने योग्य बुद्धिमान, यह एक प्लस है।

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

Comments

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

— vemv

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

— सुपरकट

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

— सुपरकट

Answer 5

पठनीयता (या इसके पूरक में) के अलावा यह अमूर्तता के उचित स्तर पर कार्यों को लिखने की अनुमति देता है।

Comments

मुझे डर है कि मुझे समझ में नहीं आ रहा है कि आपका क्या मतलब है ...

— vemv

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

— ईगॉन सेप

Answer 6

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

हालाँकि, कभी-कभी यह कुछ ऐसा है जिसकी आपको आवश्यकता नहीं है। जब अभिव्यक्ति को किसी भी तरह से पढ़ना आसान होता है और / या बस एक ही स्थान पर दिखाई देता है, तो उसे लपेटें नहीं।

Answer 7

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

Comments

स्टीफन के जवाब के अनुसार यह हमेशा नहीं हो सकता है (हालांकि संकलकों के जादू में आँख बंद करके भरोसा करना अच्छा नहीं हो सकता है)

— vemv

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

— वोज्सटेक

+1 ग्रहों के संरेखण के लिए :) लेकिन आपका अंतिम वाक्य मुझे पूरी तरह से पागल लगता है, क्या आप वास्तव में ऐसा करते हैं?

— vemv

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

— वोजंसटेक

Answer 8

मैंने यह सटीक काम अभी हाल ही में एक एप्लिकेशन में किया है जिसे मैं रीफैक्टरिंग कर रहा हूं, कोड सेंस टिप्पणियों के वास्तविक अर्थ को स्पष्ट करने के लिए:

protected void PaymentButton_Click(object sender, EventArgs e)
    Func<bool> HaveError = () => lblCreditCardError.Text == string.Empty && lblDisclaimer.Text == string.Empty;

    CheckInputs();

    if(HaveError())
        return;

    ...
}

Comments

बस जिज्ञासु, क्या भाषा है?

— vemv

@vemv: मुझे C # दिखता है।

— स्कॉट मिशेल

मैं टिप्पणियों पर अतिरिक्त पहचानकर्ताओं को भी प्राथमिकता देता हूं। लेकिन क्या यह वास्तव में शॉर्ट रखने के लिए एक स्थानीय चर को पेश करने से अलग है if? यह स्थानीय (लैम्ब्डा) दृष्टिकोण PaymentButton_Clickपढ़ने के लिए कठिन (पूरे के रूप में ) बनाता है । lblCreditCardErrorअपने उदाहरण में एक सदस्य हो रहा है, तो भी HaveErrorएक (निजी) विधेय है कि वस्तु के लिए मान्य है। मैं इसे कम करना चाहूंगा, लेकिन मैं C # प्रोग्रामर नहीं हूं, इसलिए मैं विरोध करता हूं।

— वुल्फ

@ भेड़िया अरे यार, हाँ। मैंने इसे काफी पहले लिखा था :) मैं निश्चित रूप से अब काफी दिनों से अलग चीजें करता हूं। वास्तव में, लेबल की सामग्री को देखने के लिए यह देखने के लिए कि क्या कोई त्रुटि हुई थी, मैं परेशान हो गया ... मैंने सिर्फ एक बूल क्यों नहीं लौटाया CheckInputs()???

— जॉस्पररी

Answer 9

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

Answer 10

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

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

दिलचस्प बात यह है कि यदि वर्तमान में ऐसा कुछ नहीं करना है, तो वही किया जा सकता है, लेकिन एक टिप्पणी की आवश्यकता के विस्तार की याद दिलाती है (बहुत निकट भविष्य में ¹⁾ ), इसलिए यह,

def sophisticatedHello():
    # todo set up
    say("hello")
    # todo tear down

के रूप में अच्छी तरह से इस में बदल सकता है

def sophisticatedHello():
    setUp()
    say("hello")
    tearDown()

---

¹⁾ आपको वास्तव में इस बारे में निश्चित होना चाहिए (देखें YAGNI सिद्धांत)

Answer 11

यदि भाषा इसका समर्थन करती है, तो मैं इसे पूरा करने के लिए आमतौर पर लेबल अनाम कार्यों का उपयोग करता हूं।

someCondition = lambda p: True if [complicated expression involving p] else False
#I explicitly write the function with a ternary to make it clear this is a a predicate
if (someCondition(p)):
    #do stuff...

IMHO यह एक अच्छा समझौता है क्योंकि यह आपको ifछोटे फेंक-दूर के लेबल के साथ वैश्विक / पैकेज के नाम स्थान को अव्यवस्थित करने से बचने के दौरान जटिल अभिव्यक्ति को अव्यवस्थित करने की पठनीयता का लाभ देता है । इसका अतिरिक्त लाभ यह है कि फ़ंक्शन "परिभाषा" सही है, जहां इसका उपयोग परिभाषा को संशोधित करने और पढ़ने में आसान बनाता है।

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

#goal - I have a list of PIL Image objects and I want them all as grayscale (uint8) numpy arrays
im_2_arr = lambda im: array(im.convert('L')) 
arr_list = [im_2_arr(image) for image in image_list]

Comments

"लैम्ब्डा पी: क्यों सच है अगर [पेम्बल से जुड़ी जटिल अभिव्यक्ति]" लैम्ब्डा पी: [पी से जुड़ी जटिल अभिव्यक्ति] "के बजाय? 8-)

— हंस-पीटर स्टॉपर

@hstoerr उस लाइन के ठीक नीचे टिप्पणी में। मुझे यह स्पष्ट रूप से ज्ञात करना पसंद है कि हम someCondition एक विधेय हैं। हालांकि इसकी सख्ती से अनावश्यक, मैं उन लोगों द्वारा पढ़ी जाने वाली बहुत सारी वैज्ञानिक स्क्रिप्ट लिखता हूं जो इतना कोड नहीं करते हैं, मुझे व्यक्तिगत रूप से लगता है कि मेरे सहयोगियों को भ्रमित करने के बजाय अतिरिक्त मरोड़ के लिए उपयुक्त है क्योंकि वे नहीं जानते कि [] == Falseकुछ या अन्य इसी तरह का पायथोनिक तुल्यता जो 'हमेशा' सहज नहीं है। इसका मूल रूप से झंडा लगाने का एक तरीका है कि someCondition, वास्तव में, एक विधेय है।

— अर्धसैनिक

बस मेरी स्पष्ट गलती को साफ़ करने के लिए, [] != Falseलेकिन []जब एक बूल को कास्ट के रूप में गलत है

— crasic

@ क्रैसिक: जब मैं अपने पाठकों से यह जानने की उम्मीद नहीं करता कि [] गलत मूल्यांकन करता है, तो मैं ऐसा करना पसंद करता हूं len([complicated expression producing a list]) == 0, True if [blah] else Falseजिसके बजाय अभी भी पाठक को यह जानना आवश्यक है कि [] गलत मूल्यांकन करता है।

— रेयान