क्या हर फ़ंक्शन / विधि तर्क को एक नई लाइन पर सूचीबद्ध करना एक बुरा विचार है और क्यों?

Question

मैं किसी ऐसे व्यक्ति के साथ काम करता हूं, जो हर बार किसी फ़ंक्शन को कॉल करने के लिए एक नई पंक्ति जैसे तर्क रखते हैं

aFunction(
    byte1,
    short1,
    int1, 
    int2,
    int3,
    int4,
    int5
) ;

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

Comments

+1, मुझे आपके प्रश्न का उत्तर देने के लिए पर्याप्त नहीं है, लेकिन मुझे इससे नफरत है। यदि आपके पास किसी फ़ंक्शन में कई तर्क हैं, तो आपका फ़ंक्शन संभवतः बहुत अधिक कर रहा है।

— maple_shaft

इस बिंदु पर अधिक, हमें अभी भी इस बारे में एक-दूसरे की प्राथमिकताएं क्यों देखनी हैं? हमारी IDEs स्वचालित रूप से इसे उस शैली में प्रस्तुत नहीं कर सकती जो हम चाहते हैं?

— एलेक्स Feinman

माइक, मुझे लगता है कि कोड को कम से कम स्क्रीन रियल एस्टेट लेना पसंद है। लेकिन यह एक समझौता है। मैंने {एक अलग लाइन पर {क्योंकि यह समापन के साथ मेल करना आसान बनाता है} और ब्लॉक के दायरे को सही ढंग से समझता है। यह स्क्रीन अचल संपत्ति की एक पंक्ति को खोने के tradeoff के लायक है।

— ब्रायन श्रोथ

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

— नील जी

@maple_shaft मैं उस तरह के बयानों का तिरस्कार करता हूं। इसलिए नहीं कि इसमें कोई सच्चाई नहीं है, बल्कि इसलिए कि बहुत से लोग बिना किसी सलाह के कमरे से बाहर चले जाते हैं।

— टिजिन

Answer 1

यह सिर्फ एक कोडिंग गाइडलाइन है जिसे आप पसंद कर सकते हैं या नहीं। महत्वपूर्ण बात यह है कि आप और आपके सहयोगी इसका उपयोग करने के लिए सहमत हैं या नहीं।

जाहिर है, पठनीयता बढ़ाने का सबसे अच्छा तरीका तर्कों की संख्या को सीमित करना है।

Comments

बहुत से लोग एक सरणी में डंप करके तर्कों को कम करते हैं। मैं बल्कि छिपी हुई जटिलता के साथ क्लीनर-दिखने वाले कोड की तुलना में एक बदसूरत गड़बड़ देखता हूं।

— शैतानिकप्‍पी

Arrays जाने का रास्ता नहीं है। आर्गों में एक संरचना छिपी हो सकती है, या हो सकता है कि फ़ंक्शन बहुत अधिक हो रहा हो और अलग हो जाना चाहिए।

— माइकल के

मुझे लगता है कि कई लाइनों का उपयोग कोड को पठनीय बनाने में मदद करता है यदि पैरामीटर लंबी अभिव्यक्ति या कुछ बहुत अधिक हैं। अन्यथा यह केवल कष्टप्रद है।

— 15 अक्टूबर को पेड्रो सी 8

उन्हें डेटा ट्रांसफर ऑब्जेक्ट में डालने से समस्या बस बढ़ती है। यदि सभी तर्कों की आवश्यकता होती है, तो उन सभी को डीटीओ के निर्माता के अनिवार्य तर्क होने चाहिए, जिसका अर्थ है कि आपके पास अभी भी कई तर्क हैं।

— स्कॉट व्हिटलॉक

Answer 2

यह वरीयता की बात है। जटिल फ़ंक्शन कॉल के लिए जहां आप प्रत्येक पैरामीटर को दस्तावेज़ करना चाहते हैं, या जहां चर लंबे नहीं हैं और उनमें से कई हैं, यह अच्छा हो सकता है।

उदाहरण के लिए:

do_complex_op(
      0, //Starting state, always 0, ask Joe why
      X, //X-coord of thingy
      y, //Y-coord of thingy
      73, //in this case, we don't want to use Z but want constant 
      dlogMessageTitle, //message for dialogue title
      dlogMessageText, //message for dialogue contents, don't care about this.
      SomethingIP, //IP of something-or-other server, can be NULL, won't crash.
      someObject.childObject.getValue(key1).HVAL, //very long path to HVAL
      someObject.childObject.getValue(key1).LVAL, //very long path to LVAL
      this.parentWindow.owner.mainTextBox.text.value.trim, //get the trimmed text, untrimmed text causes weird output
      pvrMainSettingForLongBlahs.getObjectByPath(somePath),
      pvrMainSettingForLongBlahs.K_TCA_UPPER_LIMIT,
      pvrMainSettingForLongBlahs.K_ENDPOINT_COMPLIANCE_LEVEL,
 );

यदि आप नामांकित पैरामीटर का उपयोग करते हैं, तो ऐसी भाषाएं जो पैरामीटर नाम (उदाहरण PL / SQL में है) का उपयोग करने पर यह अधिक सामान्य है:

PKG_SOME_TEST_CODE.FN_DO_SOMETHING( in_text => 'test text',
                                    in_id => v_id,
                                    in_ref_id => v_ref_id,
                                    out_array_for_storage => v_bArray); 

लेकिन मैं आपसे सहमत हूं कि यदि फ़ंक्शन कॉल सरल है और बहुत सारे पैरामीटर नहीं हैं, तो यह कष्टप्रद हो सकता है, जैसे:

setColour (
    r,
    g,
    b
 );

मुझे पढ़ने में बहुत आसान लगता है

 setColour(r,g,b);

---

@AmmoQ के लिए:

rc=a(b,c(d,e(f)))

rc=a(
     b,
     c(
       d,
       e(
         f
        )
      )
    )

Comments

पहला उदाहरण एक वास्तविक समस्या का गलत उत्तर है। पहली जगह में स्पष्ट चर एनीम्स का उपयोग क्यों नहीं किया जाता है?

— डेडलिंक

@ डेडलोनिक्स: अच्छी बात है, इसे थोड़ा साफ किया।

— FrustratedWithFormsDesigner

सच। हालांकि, यह हमेशा चर नामों के साथ एक मुद्दा नहीं है। यह लंबे वैरिएबल नामों, डिफॉल्ट मानों के साथ तर्क आदि के साथ करने के लिए अधिक है

— इंस्पेक्टरगेटगैन्ड

मैं इस समस्या के बेहतर समाधान का तर्क दूंगा d_complex_op () तो यह एक पैरामीटर के रूप में एक संरचना लेता है। फिर आप कर सकते हैं do_complex_op(new paramStruct { StartingState = 0, XCoord = xcoord }), फिर यह स्व दस्तावेज और पढ़ने में बहुत आसान हो जाता है

— कल्लड्रेक्स

@KallDrexx: मैं सहमत हूं, लेकिन कभी-कभी कोड को बदलना कोई विकल्प नहीं है, जैसे कि जब यह किसी और के पुस्तकालय में एक समारोह है। ज़रूर, मैं इसे एक आवरण बना सकता हूं, लेकिन मुझे अभी भी उनके मूल कार्य को किसी बिंदु पर कॉल करना होगा।

— FrustratedWithFormsDesigner

Answer 3

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

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

Comments

हम्म ... उस दृष्टिकोण के साथ, हम कभी भी एक नया सर्वोत्तम अभ्यास कैसे पेश कर सकते हैं (या, ग्राम्य रूप से सही: एक बेहतर अभ्यास )?

— ट्रेब

ट्रेब: ज़रूर, बस यह दिखाएं कि बेहतर अभ्यास वास्तव में बेहतर है , न कि अलग ।

— user281377

लेकिन "पढ़ने में कठिन", स्वयं, व्यक्तिपरक और राय का विषय है। मेरे लिए, प्रति पंक्ति एक तर्क दो, तीन या चार तर्क प्रति पंक्ति की तुलना में नेत्रहीन पार्स करना आसान है। और मैं हमेशा कई पंक्तियों में एक कॉल को तोड़ता हूं अगर वह संपादक में लगभग 100 वर्ण चिह्न से परे फैली हुई है।

— टॉबी

भावहीन। "पढ़ने के लिए कठिन" को निष्पक्ष रूप से मापा जा सकता है। यह बस नहीं हो जाता है। इसके बारे में तर्क देना ज्यादा मजेदार है।

— जेसनट्र्यू

यह उद्देश्यपूर्ण रूप से मापा जा सकता है लेकिन स्वतंत्र रूप से पढ़ने वाले व्यक्ति के लिए नहीं।

— जे.के.

Answer 4

खैर, यहाँ कुछ नीचे-चारा है। मुझ पर कभी भी लोकप्रिय काम करने का आरोप नहीं लगाया गया। जाहिर है, अगर चीजें एक लाइन पर फिट होती हैं, तो ठीक है, उन्हें एक लाइन पर फिट करें।

लेकिन मेरी मुख्य चिंता यह नहीं है कि कोड "बदसूरत" या "सुंदर" है। मेरी मुख्य चिंता यह है कि गलतियों को समझे बिना बदलाव करना और समझना कितना आसान है।

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

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

तो (लड़का, मैं इसके लिए लज्जित हो जाता हूं) मैं इसे इस तरह से लिखता हूं:

nameOfFunction(firstArgument
    , secondArgument // optional comment
       ...
    , lastArgument   // optional comment
    );

जब पाँच से बीस तर्कों के साथ कोई फ़ंक्शन होता है, तो फ़ंक्शन को उस समय बिल्कुल नहीं मिलता है। यह समय के साथ बढ़ता गया, मतलब बहुत सारे संपादन थे। पूरा नहीं किया गया कोई भी वाक्यविन्यास त्रुटि या बग है। इसलिए मैं यह दावा नहीं करता कि यह सुंदर है। मेरा दावा है कि यह संपादनों को सही होने में मदद करता है।

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

Comments

मुझे व्यक्तिगत रूप से लगता है कि यह एक महान जवाब है क्योंकि आपने अपने तर्क को बहुत अच्छी तरह से समझाया है। अच्छा काम माइक।

— जॉर्डन

Answer 5

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

यही कारण है कि एक संगठन के लिए गाइड का एक सेट स्थापित करना अच्छा है, जिसके लिए सभी प्रोग्रामर का पालन करना चाहिए। यह सब संगति और पठनीयता के बारे में है।

Answer 6

यह इसे आसान बनाता है:

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

Answer 7

मैं कहूंगा कि फ़ंक्शन कॉल सभी एक पंक्ति में होनी चाहिए जब तक कि वे आपके मानक कोड की चौड़ाई से अधिक न हों (अक्सर 80 वर्ण, अक्सर तर्क का एक कारण :-)।

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

Comments

यह 80 चरित्र की बात है, इसके लिए कोई तकनीकी रूप से मान्य कारण नहीं हैं। अब हम 19xx X 16xx मॉनिटर और एडजस्टेबल फोंट और फॉन्ट साइज के एक युग में रहते हैं।

— अनॉन

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

— ज़ैन लिंक्स

@anon: इसके अलावा मुझे अपनी वाइडस्क्रीन का उपयोग दो या तीन फ़ाइलों को एक क्षैतिज विभाजन में खोलने के लिए करना पसंद है जो एक पंक्ति में 80-100 वर्णों में वापस मिल जाती है।

— Zan Lynx

@anon: तकनीकी रूप से नहीं, व्यावहारिक रूप से: नरक हाँ। ज़ैन लिंक्स पूरी तरह से सही है, इसके अतिरिक्त कारण भी हैं: विलय, अंतर, कमांड लाइन उपयोगिताओं का उपयोग ... ओह और अच्छी किस्मत 8p फ़ॉन्ट पर ध्यान केंद्रित करते हुए जैसे कि आप बड़े हो जाएंगे: ओ)

— MaR

Answer 8

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

Comments

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

— बिलथोर

Answer 9

क्या यह कंपनी कोडिंग मानकों के खिलाफ है?

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

क्यों इस बारे में पूरी चर्चा करें आपको नहीं लगता कि यह उपयोगी है और उम्मीद है कि आप दिन जीतेंगे। आप कभी नहीं जानते कि आपका सहयोगी आपको समझा सकता है कि उसका रास्ता सब के बाद सबसे अच्छा है;)

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

Answer 10

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

यह पढ़ने में भी आसान है:

int f(int, int, int,
      char, double, int
      X const&, Y)
{}

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

महत्वपूर्ण बात यह है कि आपका कोड मानक पर मुद्रित या प्रदर्शित किया जा सकता है, 80col डिस्प्ले और अभी भी सुपाठ्य हो सकता है।

Answer 11

आप शायद ही कभी इस तरह से कुछ के लिए एक प्रोग्रामर से एक ईमानदार जवाब मिलेगा। हर कोई बस इसका जवाब देगा कि वे क्या करते हैं या क्या नहीं पसंद करते हैं। सच्चाई यह है कि, हम सभी समय पर इसके साथ संघर्ष करते हैं, यहाँ केवल "बुरा अभ्यास" आपकी अपनी अनम्यता है।

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

जो मेरे पढ़ने के लिए ... ठीक है कि आप इस प्रश्न में क्या अनुरोध कर रहे हैं: आपकी व्यक्तिगत पसंद को सही ठहराने के लिए एक हास्यास्पद, विवादास्पद तर्क।

Answer 12

ईमानदार होने के लिए यह व्यक्ति पर निर्भर करता है .. मैं जटिल कार्यों के लिए कहूँगा जैसा कि FrustratedWithForms द्वारा पहले उदाहरण में दिखाया गया है, फिर हाँ; अन्यथा कोई बड़ा सं। तब फिर से यही कारण है कि मैं मनमाने ढंग से कोड की आईडीई कार्यक्षमता को लागू करना पसंद करता हूं।

Answer 13

"मुझे यह जानने में दिलचस्पी है कि क्या यह वास्तव में बुरा व्यवहार है ..."

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

"... और यदि हां, तो मैं उन्हें यह कैसे करने के लिए मना कर सकता हूं?"

उन्हें नीचे बांधें और जब तक वे उस बकवास को रोकने के लिए सहमत न हों, तब तक उन्हें गुदगुदी करते रहें।

Comments

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

— Stijn

Answer 14

आप ऐसी तुच्छ चिंता पर चक्र क्यों बर्बाद कर रहे हैं? बस अपने भरोसेमंद आईडीई को आग दें, फ़ाइल खोलें और सुधार करें। देखा! यह आप जिस भी रूप में चाहेंगे।

अब चलो वास्तव में महत्वपूर्ण मुद्दे पर चलते हैं - vi या emacs, LOL।

Comments

और फिर जब आप स्रोत-नियंत्रण में जांच करने आते हैं?

— पीडीआर

Answer 15

मैं कहूंगा, अगर तर्क एक पंक्ति में फिट होते हैं, तो ऐसा करें। यदि नहीं, तो प्रति पंक्ति एक तर्क महान पठनीयता के लिए बनाता है।

foo(arg1, arg2, arg3, arg4, arg5)

बनाम

foo(
    arg1=arg1,
    arg2=arg2,
    arg3=arg3,
    arg4=arg4,
    arg5=arg5,
    arg6=arg6,
    arg7=arg7
)

Comments

इस प्रस्ताव को कुछ भी बना अंक पर पर्याप्त प्रतीत नहीं होता है और पहले 14 जवाब में बताया गया है

— कुटकी