क्लीन कोड में अतिरिक्त बनाम ब्लॉक में अतिरिक्त लाइन

Question

प्रसंग

में स्वच्छ कोड , पृष्ठ 35, यह कहता है

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

मैं पूरी तरह से सहमत हूं, यह बहुत मायने रखता है।

बाद में, पृष्ठ 40 पर, यह फ़ंक्शन तर्कों के बारे में कहता है

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

मैं पूरी तरह से सहमत हूं, यह बहुत मायने रखता है।

मुद्दा

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

या तो मैं ब्लॉक में दो पंक्तियों का उपयोग करता हूं , एक चीज बनाने के लिए, एक इसे परिणाम में जोड़ने के लिए:

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            Flurp flurp = CreateFlurp(badaBoom);
            flurps.Add(flurp);
        }
        return flurps;
    }

या मैं सूची के लिए फ़ंक्शन में एक तर्क जोड़ता हूं जहां चीज को जोड़ा जाएगा, जिससे यह "एक तर्क खराब" होगा।

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            CreateFlurpInList(badaBoom, flurps);
        }
        return flurps;
    }

सवाल

क्या मैं (डिस) फायदे देख नहीं रहा हूं, जो उनमें से एक को सामान्य रूप से बेहतर बना सकते हैं? या कुछ स्थितियों में ऐसे फायदे हैं; उस मामले में, निर्णय लेते समय मुझे क्या देखना चाहिए?

Comments

इसमें गलत क्या है flurps.Add(CreateFlurp(badaBoom));?

— 15

नहीं, यह सिर्फ एक बयान है। यह सिर्फ एक तुच्छ नेस्टेड अभिव्यक्ति है (एक नेस्टेड स्तर)। और अगर कोई साधारण f(g(x))आपके स्टाइल-गाइड के खिलाफ है, तो ठीक है, मैं आपकी स्टाइल-गाइड को ठीक नहीं कर सकता। मेरा मतलब है, आप sqrt(x*x + y*y)या तो चार लाइनों में विभाजित नहीं हैं, क्या आप? और वह तीन (!) नेस्टेड नेक्सैक्सेंस दो पर (!) इनर नेस्टिंग लेवल (हांसी!) है। आपका लक्ष्य पठनीयता होना चाहिए , न कि एकल ऑपरेटर स्टेटमेंट। यदि आप बाद में चाहते हैं, तो ठीक है, मेरे पास आपके लिए एकदम सही भाषा है: असेंबलर।

— विगत

@cmaster यहां तक ​​कि x86 असेंबली में भी सिंगल-ऑपरेटर स्टेटमेंट्स नहीं हैं। मेमोरी एड्रेसिंग मोड में कई जटिल ऑपरेशन शामिल हैं और इसका उपयोग अंकगणित के लिए किया जा सकता है - वास्तव में, आप केवल X86 movनिर्देशों और jmp toStartअंत में एकल का उपयोग करके ट्यूरिंग-पूर्ण कंप्यूटर बना सकते हैं । किसी ने वास्तव में एक कंपाइलर बनाया जो बिल्कुल ऐसा करता है: D

— Luaan

@ Luaan rlwimiपीपीसी पर कुख्यात निर्देश की बात करने के लिए नहीं । (जो रोटेट लेफ्ट वर्ड इमीडिएट मास्क इंसर्ट के लिए खड़ा है।) इस कमांड ने पांच ऑपरेंड्स (दो रजिस्टर, और तीन तत्काल मान) से कम नहीं लिया, और इसने निम्नलिखित ऑपरेशन किए: एक रजिस्टर सामग्री को तत्काल शिफ्ट द्वारा घुमाया गया, एक मुखौटा 1 बिट्स के एक रन के साथ बनाया गया था, जिसे दो अन्य तत्काल ऑपरेंड्स द्वारा नियंत्रित किया गया था, और दूसरे रजिस्टर ऑपरेंड में उस मास्क में 1 बिट्स के अनुरूप बिट्स को घुमाए गए रजिस्टर के संबंधित बिट्स के साथ बदल दिया गया था। बहुत अच्छा निर्देश :-)

— cmaster

@ R.Schmitz "Im सामान्य प्रयोजन प्रोग्रामिंग कर रहा है" - वास्तव में नहीं, आप नहीं हैं, आप एक विशिष्ट उद्देश्य के लिए प्रोग्रामिंग कर रहे हैं (मुझे नहीं पता कि उद्देश्य क्या है, लेकिन मैं आपको मान रहा हूं; ;-) प्रोग्रामिंग के लिए वास्तव में हजारों उद्देश्य हैं, और उनके लिए इष्टतम कोडिंग शैलियों में भिन्नता है - इसलिए जो आपके लिए उपयुक्त है वह दूसरों के लिए उपयुक्त नहीं हो सकता है, और इसके विपरीत: अक्सर यहां सलाह निरपेक्ष है (" हमेशा एक्स करें; वाई खराब है" "आदि) को अनदेखा करना कि कुछ डोमेन में इसे चिपकाने के लिए पूरी तरह से अव्यावहारिक है। इसीलिए क्लीन कोड जैसी किताबों में सलाह हमेशा एक चुटकी (व्यावहारिक) नमक के साथ लेनी चाहिए :)

— psmears

Answer 1

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

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

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

यदि यह बेहतर करना संभव है, तो यह ध्यान देने योग्य है कि "सभी तत्वों को एक सूची से दूसरी सूची में बदलना" एक सामान्य पैटर्न है जिसे अक्सर एक कार्यात्मक map()ऑपरेशन का उपयोग करके दूर किया जा सकता है । C # में, मुझे लगता है कि यह कहा जाता है Select। कुछ इस तरह:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(BadaBoom => CreateFlurp(badaBoom)).ToList();
}

Comments

कोड अभी भी गलत है, और यह पहिया को निरर्थक रूप से पुनर्स्थापित करता है। CreateFlurps(someList)जब बीसीएल पहले से ही उपलब्ध है तो कॉल क्यों करें someList.ConvertAll(CreateFlurp)?

— बेन वायगट

@BenVoigt यह एक डिज़ाइन-स्तरीय प्रश्न है। मैं सटीक वाक्य रचना के साथ असंबद्ध हूँ, खासकर जब से एक व्हाइटबोर्ड में एक संकलक नहीं होता है (और मैंने अंतिम बार '09 में C # लिखा है)। मेरी बात "मैंने सबसे अच्छा संभव कोड दिखाया है" लेकिन "एक तरफ के रूप में, यह एक सामान्य पैटर्न है जो पहले से ही हल है"। Linq इसे करने का एक तरीका है, ConvertAll जिसका आप अन्य उल्लेख करते हैं । उस विकल्प का सुझाव देने के लिए धन्यवाद।

— आमोन

आपका उत्तर समझदार है, लेकिन तथ्य यह है कि LINQ तर्क को दूर कर देता है और आपकी सलाह के विपरीत होने के बाद बयान को एक पंक्ति में कम कर देता है। एक साइड नोट के रूप में, BadaBoom => CreateFlurp(badaBoom)बेमानी है; आप CreateFlurpसीधे फ़ंक्शन के रूप में पास कर सकते हैं ( Select(CreateFlurp))। (जहाँ तक मुझे पता है, यह हमेशा से रहा है।)

— jpmc26

ध्यान दें कि यह पूरी तरह से विधि की आवश्यकता को हटा देता है। नाम CreateFlurpsवास्तव में अधिक भ्रामक है और केवल देखने की तुलना में समझना कठिन है badaBooms.Select(CreateFlurp)। उत्तरार्द्ध पूरी तरह से घोषणात्मक है - विघटित होने की कोई समस्या नहीं है और इसलिए किसी भी तरीके की आवश्यकता नहीं है।

— कार्ल लेथ

@ R.Schmitz इसे समझना मुश्किल नहीं है , लेकिन इसे समझना आसान नहीं है badaBooms.Select(CreateFlurp)। आप एक विधि बनाते हैं ताकि उसका नाम (उच्च स्तर) उसके कार्यान्वयन (निम्न स्तर) के लिए खड़ा हो। इस मामले में वे समान स्तर पर हैं, इसलिए यह पता लगाने के लिए कि मुझे क्या हो रहा है, बस विधि को देखने जाना चाहिए (इसके बजाय इसे इनलाइन करने के लिए)। CreateFlurps(badaBooms)आश्चर्य पकड़ सकता है, लेकिन badaBooms.Select(CreateFlurp)नहीं कर सकता। यह भी भ्रामक है क्योंकि यह गलती से एक के Listबजाय के लिए पूछ रहा है IEnumerable।

— कार्ल लेथ

Answer 2

किसी फ़ंक्शन के लिए तर्क की आदर्श संख्या शून्य (निलादिक) है

नहीं! किसी फ़ंक्शन के लिए तर्क की आदर्श संख्या एक है। यदि यह शून्य है, तो आप गारंटी दे रहे हैं कि फ़ंक्शन को कार्रवाई करने में सक्षम होने के लिए बाहरी जानकारी तक पहुंचना है। "अंकल" बॉब को यह बहुत गलत लगा।

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

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    List<Flurp> flurps = new List<Flurp>();
    foreach (BadaBoom badaBoom in badaBooms)
    {
        flurps.Add(CreateFlurp(badaBoom));
    }
    return flurps;
}

लेकिन यह बहुत लंबा घुमावदार है (C #) कोड। बस इसे इस प्रकार करें:

IEnumerable<Flurp> CreateFlurps(IEnumerable<BadaBoom> badaBooms) =>
    from badaBoom in babaBooms select CreateFlurp(badaBoom);

Comments

शून्य तर्कों के साथ एक फ़ंक्शन का मतलब यह है कि ऑब्जेक्ट आवश्यक डेटा को एन्क्रिप्ट करता है न कि किसी वस्तु के बाहर वैश्विक स्थिति में चीजें मौजूद हैं।

— रायथल

@ रायथल, दो अंक: (1) यदि आप विधियों की बात कर रहे हैं, तो अधिकांश (सभी?) ओओ भाषाओं के लिए, उस वस्तु को पहले पैरामीटर के रूप में अनुमान (या स्पष्ट रूप से कहा गया है, पायथन के मामले में)। जावा, सी # आदि में, सभी विधियां कम से कम एक पैरामीटर के साथ कार्य करती हैं। संकलक आपसे वह विवरण छिपाता है। (२) मैंने कभी "वैश्विक" का उल्लेख नहीं किया। वस्तु स्थिति उदाहरण के लिए एक विधि के लिए बाहरी है।

— डेविड अर्नो

मुझे पूरा यकीन है, जब अंकल बॉब ने "शून्य" लिखा था तो उनका मतलब था "शून्य (यह गिनती नहीं)"।

— डॉक्टर ब्राउन

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

— डेविड अर्नो

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

— डेविड अर्नो

Answer 3

'क्लीन कोड' सलाह पूरी तरह से गलत है।

अपने लूप में दो या अधिक लाइनों का उपयोग करें। किसी फ़ंक्शन में समान दो पंक्तियों को छुपाने से समझ में आता है जब वे कुछ यादृच्छिक गणित होते हैं जिन्हें विवरण की आवश्यकता होती है लेकिन यह तब कुछ नहीं करता है जब लाइनें पहले से ही वर्णनात्मक होती हैं। 'बनाएँ' और 'जोड़ें'

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

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            flurps.Add(badaBoom .CreateFlurp());
            //or
            badaBoom.AddToListAsFlurp(flurps);
            //or
            flurps.Add(new Flurp(badaBoom));
            //or
            //make flurps a member of the class
            //use linq.Select()
            //etc
        }
        return flurps;
    }

या

foreach(var flurp in ConvertToFlurps(badaBooms))...

जैसा कि दूसरों ने नोट किया है, सबसे अच्छा कार्य जो किसी भी तर्क के साथ होता है, वह OOP में सबसे अच्छा और कम से कम बुरी सलाह पर तिरछा होता है

Comments

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

— आर। श्मिट

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

— इवान

@ R.Schmitz मैंने स्वयं "क्लीन कोड" पढ़ा है, और मैं उस पुस्तक का सबसे ज्यादा पालन करता हूं। हालांकि, एकदम सही फ़ंक्शन आकार के बारे में बहुत अधिक एक ही बयान दिया जा रहा है, यह सिर्फ सादा गलत है। एकमात्र प्रभाव यह है, कि यह स्पेगेटी कोड को चावल कोड में बदल देता है। पाठक तुच्छ कार्यों की भीड़ में खो जाता है जो केवल एक साथ देखने पर समझदार अर्थ उत्पन्न करते हैं। मनुष्य के पास काम करने की सीमित क्षमता होती है, और आप या तो बयानों के साथ, या कार्यों के साथ अधिभार कर सकते हैं। यदि आप पढ़ना चाहते हैं, तो आपको दोनों के बीच एक संतुलन बनाना होगा। अति से बचें!

— सेमीस्टर

@cmaster उत्तर केवल पहले 2 पैराग्राफ थे जब मैंने वह टिप्पणी लिखी थी। यह अब तक एक बेहतर जवाब है।

— आर। श्मिट

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

— इवान

Answer 4

दूसरा निश्चित रूप से बदतर है, क्योंकि CreateFlurpInListसूची को स्वीकार करता है और उस सूची को संशोधित करता है, जिससे फ़ंक्शन शुद्ध नहीं होता है और इसके बारे में तर्क करना मुश्किल होता है। विधि नाम में कुछ भी नहीं है विधि केवल सूची में जोड़ता है।

और मैं तीसरा, सबसे अच्छा विकल्प प्रदान करता हूं:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(CreateFlurp).ToList();
}

और नरक, आप उस पद्धति को तुरंत इनलाइन कर सकते हैं यदि केवल एक ही स्थान है जहां इसका उपयोग किया जाता है, क्योंकि एक-लाइनर अपने आप से स्पष्ट है, इसलिए इसे अर्थ देने के लिए विधि द्वारा इनकैप्सुलेट होने की आवश्यकता नहीं है।

Comments

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

— gnasher729

Answer 5

एक तर्क संस्करण बेहतर है, लेकिन प्राथमिक रूप से तर्कों की संख्या के कारण नहीं।

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

क्या आप मुझे एक साथ प्रदान करते हैं CreateFlurp(BadaBoom), मुझे लगता है कि उपयोग कर सकते हैं संग्रह कंटेनर के किसी भी प्रकार के साथ: सरल Flurp[], List<Flurp>, LinkedList<Flurp>, Dictionary<Key, Flurp>, और इतने पर। लेकिन एक के साथ CreateFlurpInList(BadaBoom, List<Flurp>), मैं कल आपके पास वापस आ रहा हूं CreateFlurpInBindingList(BadaBoom, BindingList<Flurp>)ताकि मेरे दृष्टिकोण को सूचना मिल सके कि सूची बदल गई है। नीरस

अतिरिक्त लाभ के रूप में, सरल हस्ताक्षर मौजूदा एपीआई के साथ फिट होने की अधिक संभावना है। आप कहते हैं कि आपको आवर्ती समस्या है

बल्कि अक्सर मैं खुद को एक और सूची से एक सूची बनाने लगता है

यह उपलब्ध साधनों का उपयोग करने की बात है। सबसे छोटा, सबसे कुशल और सबसे अच्छा संस्करण है:

var Flurps = badaBooms.ConvertAll(CreateFlurp);

न केवल आपके लिए लिखने और परीक्षण करने के लिए यह कम कोड है, यह तेज़ भी है, क्योंकि List<T>.ConvertAll()यह जानने के लिए काफी स्मार्ट है कि परिणाम में इनपुट के समान आइटम होंगे, और परिणाम सूची को सही आकार में प्रचारित करेंगे। जबकि आपके कोड (दोनों संस्करणों) को सूची को बढ़ाने की आवश्यकता थी।

Comments

उपयोग न करें List.ConvertAll। C # में अलग-अलग वस्तुओं के लिए किसी ऑब्जेक्ट को मैप करने का मुहावरेदार तरीका कहा जाता है Select। एकमात्र कारण ConvertAllयहां तक ​​उपलब्ध है क्योंकि ओपी गलती Listसे विधि में पूछ रहा है - यह एक होना चाहिए IEnumerable।

— कार्ल लेथ

Answer 6

समग्र लक्ष्य को ध्यान में रखें: कोड को पढ़ना और बनाए रखना आसान है।

अक्सर, कई लाइनों को एक एकल, सार्थक फ़ंक्शन में समूहित करना संभव होगा। इन मामलों में ऐसा करें। कभी-कभी, आपको अपने सामान्य दृष्टिकोण पर पुनर्विचार करने की आवश्यकता होगी।

उदाहरण के लिए, आपके मामले में, पूरे कार्यान्वयन को var के साथ प्रतिस्थापित करना

flups = badaBooms.Select(bb => new Flurp(bb));

एक संभावना हो सकती है। या आप ऐसा कुछ कर सकते हैं

flups.Add(new Flurp(badaBoom))

कभी-कभी, सबसे साफ और सबसे पठनीय समाधान बस एक पंक्ति में फिट नहीं होगा। तो आपके पास दो लाइनें होंगी। कोड को समझने में मुश्किल न करें, बस कुछ मनमाने नियम को पूरा करने के लिए।

आपका दूसरा उदाहरण (मेरी राय में) पहले की तुलना में समझने में काफी कठिन है। ऐसा नहीं है कि आपके पास दूसरा पैरामीटर है, यह है कि पैरामीटर फ़ंक्शन द्वारा संशोधित है। उस बारे में क्या कहना है क्लीन कोड। (अभी पुस्तक हाथ में नहीं है, लेकिन मुझे पूरा यकीन है कि यह मूल रूप से "ऐसा नहीं है कि अगर आप इसे टाल सकते हैं")।