क्या सादगी हमेशा पठनीयता में सुधार करती है?

32

हाल ही में, मैं हमारी कंपनी के लिए कोडिंग मानकों का एक समूह विकसित कर रहा था। (हम कंपनी के लिए एक नई भाषा में एक नई टीम बना रहे हैं।)

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

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

हालाँकि, मैंने इस धक्का के पीछे की धारणा पर सवाल उठाया है:

क्या सादगी हमेशा पठनीयता में सुधार करती है?

क्या ऐसा मामला है जहां सरल कोड लिखने से पठनीयता घट जाती है?

यह स्पष्ट होना चाहिए, लेकिन "सरल" से मेरा मतलब "लिखना आसान" नहीं है, लेकिन प्रति पंक्ति कम सामान जा रहा है।

code-quality readability

— रिचर्ड
स्रोत

16

यदि विकल्प "चालाक" कोड है, तो हाँ ... है

— Oded

2

हाँ - प्रति Occam है उस्तरा - en.wikipedia.org/wiki/Occam%27s_razor

— aggietech

17

हमेशा और कभी भी इस तरह के कठोर शब्दों के इस्तेमाल से बचने की कोशिश करें। यह किनारे के मामलों पर ध्यान केंद्रित करने से बचने के लिए है और इसके बजाय हम सामना करने वाले सबसे आम मुद्दों पर ध्यान केंद्रित करते हैं। यह वही है जो सर्वोत्तम प्रथाओं के बारे में है।

— पी। ब्रायन। मैके डे

वास्तव में, आप प्रति पंक्ति 2 कार्य / संचालन चाहते हैं। a = bएक ऑपरेशन है, b + cएक दूसरा है, जिसका अर्थ a = b + cहै 2 ऑपरेशन। 2 फ़ंक्शंस / ऑपरेटर्स का पीछा करना अभी भी पठनीय है: foo(bar())या a = foo()।

— zzzzBov

2

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

— स्टीव 314

47

"सरल" एक अति प्रयोग किया जाने वाला शब्द है। "पठनीय" को लाभप्रद रूप से "समझने में सरल" के रूप में परिभाषित किया जा सकता है, जिस स्थिति में परिभाषा द्वारा (सादगी के) बढ़ते हुए पठनीयता बढ़ जाती है, लेकिन मुझे नहीं लगता कि इसका मतलब यह है। मैं गए प्रश्न के लिखित के बारे में इस कहीं और है, लेकिन आम तौर पर कुछ "सरल" या तो अधिक अमूर्त किया जा रहा है (इस स्थिति में कम अवधारणाओं अधिक घटनाएं व्यक्त कर सकते हैं) द्वारा या एक से अधिक ठोस होने से कहा जा सकता है (इस स्थिति में एक अवधारणा बहुत पृष्ठभूमि के रूप में की आवश्यकता नहीं है पहली जगह में समझने के लिए ज्ञान)। मैं तर्क दे रहा हूं कि, परिप्रेक्ष्य के आधार पर, एक अधिक अमूर्त अवधारणा को एक अधिक ठोस अवधारणा, या इसके विपरीत से अधिक सरल कहा जा सकता है । यह, हालांकि "सार" और "

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

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

उत्तर में से एक ने इसे कम कर दिया:

count = mapM (enumFromTo 0)

समझने के लिए इनमें से कौन सा "सरल" है (अर्थात अधिक पठनीय) पूरी तरह से इस बात पर निर्भर करता है कि पाठक कितने सहज (अमूर्त) मौद्रिक कार्यों (और, उस मामले के लिए, बिंदु-मुक्त कोड) के साथ कितना सहज हो गया है। एक पाठक जो इन अमूर्त अवधारणाओं के साथ बहुत सहज है, वह (लघु) अधिक सार संस्करण पढ़ना पसंद करेगा, जबकि एक जो उन कार्यों के साथ सहज नहीं है, वह (लंबे) अधिक ठोस संस्करण को पढ़ना पसंद करेगा। इस बारे में कोई जवाब नहीं है कि कौन सा संस्करण अधिक पठनीय है जो हर किसी के लिए धारण करेगा।

— ऐदन कलली
स्रोत

11

कुछ डेवलपर्स तब तक प्रगति करेंगे जब तक कि वे वन-लाइनर को समझते और पसंद नहीं करते। एक डेवलपर की कल्पना करना मुश्किल है जो लंबे संस्करण को पसंद करने के लिए आने वाले वन-लाइनर को समझता है। इसलिए IMO वन-लाइनर स्पष्ट रूप से बेहतर है।

— केविन क्लाइन

7

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

— ऐदन कल्ली

6

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

— तिखन जेल्विस

6

@ स्टीव ३१४: mapMबहुत मुहावरेदार है, और enumFromToयह वही करता है जो टिन पर कहता है। सामान्य तौर पर, मुझे लगता है कि यदि आप कोड का विस्तार करते हैं, तो यह वास्तव में ऑफ-बाय-वन त्रुटियां बनाना आसान है - इसमें गलती करने के लिए बस अधिक कोड है। यह विशेष रूप से अन्य भाषाओं में उच्च-क्रम प्रक्रियाओं के लिए लूप जैसी चीजों से स्पष्ट है। , लेकिन मुझे यह एक सामान्य सिद्धांत लगता है।

— तिखन जेल्विस

1

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

— स्टीव 314

13

यदि आपका कोडिंग मानक "पठनीयता, रख-रखाव, विश्वसनीयता और प्रदर्शन" के बारे में है, तो बस यह बताएं कि ।

कोशिश मत करो और लिखो कि कैसे इन चीजों को प्राप्त करना है क्योंकि हमेशा ऐसी परिस्थितियां होंगी जहां एक काउंटर उदाहरण है।

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

— मार्टिन यॉर्क
स्रोत

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

— रिचर्ड

5

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

— मार्टिन

3

+1 (क्योंकि मैं +10 नहीं कर सकता) एक सामान्य गलती जो मैं नए प्रोग्रामिंग प्रबंधकों के साथ देखता हूं, वह यह है कि वे हर अंतिम विवरण को संहिताबद्ध करने का प्रयास करते हैं। व्यंजनों की तुलना में सबसे अच्छा कोडिंग मानक भाग्य कुकीज़ की तरह हैं।

— जॉन डेक्स

"कोडिंग शैलियों और मानकों" दस्तावेज़ का नाम था। जाहिर है कि यह एक मानक नहीं है (जैसा कि "कभी भी GoTo का उपयोग न करें" या "कभी भी शॉर्ट इन्ट्स का उपयोग न करें") लेकिन एक शैली है। स्टाइल की शैली को पठनीयता और बनाए रखने के लिए महत्वपूर्ण है।

— रिचर्ड

1

शैली गाइड: "यह परियोजना टैब / रिक्त स्थान (एक का चयन करें) का उपयोग करती है। यह परियोजना ब्रेस स्टाइल K & R / Allman / BSD / GNU (एक का चयन करें) का उपयोग करती है। कृपया लाइनों के अंत में खाली स्थान न जोड़ें। कृपया अपने पास रखें।" कोड साफ-सुथरा और पठनीय। सब कुछ कोड की समीक्षा दो टीम के सदस्यों और स्वयं द्वारा की जाएगी: पठनीयता / स्थिरता के लिए आपको कोड में जांच करने के लिए बहुमत 2/3 चाहिए, विश्वसनीयता के लिए, और प्रदर्शन के लिए आपको 3/3 की आवश्यकता है (कृपया साबित करने के लिए उपयुक्त परीक्षण प्रदान करें। ) .अधिक नियमों को जोड़ा जाएगा अगर इन के साथ दुर्व्यवहार किया जाता है :-) "हो गया।

— मार्टिन यॉर्क

7

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

कम "सामान प्रति पंक्ति" को कोड ब्लॉक को अब और अधिक लंबवत रूप से देखने के लिए महान बड़े लम्बे मॉनिटर के साथ डेवलपर्स की आपूर्ति की आवश्यकता हो सकती है। या टीनियर फोंट पढ़ने से आंखों का तनाव।

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

— hotpaw2
स्रोत

5

हमेशा? - नहीं

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

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

— DKnight
स्रोत

5

अगर मैं सरलता के लिए जाता हूं, तो मैं इस तरह कोड लिख सकता हूं:

10000000000000000000000000000000000000000000

लेकिन अगर मैं पठनीयता के लिए जाता हूं, तो मैं इसे पसंद करूंगा:

1e43

दूसरी ओर, 1000बहुत अधिक पठनीय और सरल है 1e3जब तक कि आप हर समय वैज्ञानिक संकेतन में संख्याओं के साथ काम न करें।

यह बहुत अधिक सामान्य पैटर्न का एक विकृत उदाहरण है जिसे आप लगभग कहीं भी पा सकते हैं - बहुत सरल ब्लॉकों में से कुछ का निर्माण जल्दी से बहुत अलग-अलग तरीकों से अपठनीय / अक्षम / खराब हो सकता है। दूसरी ओर सामान्यीकरण और पुन: उपयोग करना, पहले कठिन होता है ("wtf है e? - क्या उनका मतलब लिखने का है 1343?" कोई कह सकता है), लेकिन लंबे समय में बहुत मदद कर सकता है।

— Rotsor
स्रोत

"100e" से कम पठनीय होने के बारे में आपकी बात अच्छी तरह से बताई गई है। वास्तव में, यह एक बड़ा उदाहरण है कि संज्ञानात्मक भार पठनीयता को कैसे प्रभावित करता है। "Ie3" को 3 वर्णों को पढ़ने, और घातांक का अनुवाद करने की आवश्यकता है। "100" को पढ़ने के लिए 3 वर्णों को पढ़ना पड़ता है, और आगे के मूल्यांकन को नहीं।

— स्टीफन ग्रॉस

स्टीफन, वास्तव में जब 100आप तीन अंकों की संख्या पढ़ते हैं तो आपको दो गुणा और दो जोड़ ( 0+10*(0+10*1)) करने होते हैं। हालाँकि, इस संकेतन का उपयोग करने के बाद, आपको यह भी ध्यान नहीं है। यह फिर से दिखाता है कि सादगी की धारणा कितनी व्यक्तिपरक हो सकती है।

— Rotsor

दिलचस्प। तो, सख्ती से बोलते हुए, "100" के लिए 2 गुणा (1 * 100, 0 * 10) और 2 अतिरिक्त संचालन की आवश्यकता होती है। "Ie3" को एक गुणा ऑपरेशन की आवश्यकता होती है। तो, किसी भी संज्ञानात्मक संदर्भ से अनुपस्थित , "1e3" की तुलना में "100" पढ़ना कठिन है। परंतु! यदि आप संदर्भ-स्विचिंग संज्ञानात्मक लोड शामिल करते हैं, तो गणना अलग है। चूँकि हम सामान्य रूप से गैर-वैज्ञानिक रूप में पूर्णांक पढ़ते हैं, इसलिए "100" आसान है। लेकिन, अगर हम एक इंजीनियरिंग ऐप लिख रहे हैं, जिसमें सभी नंबर वैज्ञानिक संकेतन में व्यक्त किए गए हैं, तो "1e3" फॉर्म आसान है!

— स्टीफन ग्रॉस

2

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

— मेसन व्हीलर
स्रोत

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

— S.Lott

1

@ S.Lott: सच है, लेकिन पर्याप्त स्क्रॉलिंग और Ctrl-क्लिक करने से "सरलीकृत" प्रक्रिया का पालन करना अधिक कठिन हो सकता है। मैंने देखा है कि यह एक या दो बार होता है (यह आम नहीं है लेकिन जब यह बहुत दूर तक जाता है तो काम करना बहुत निराशाजनक हो सकता है)।

— FrustratedWithFormsDesigner 21

3

@ एस.लॉट - अभी भी सीमाएं हैं कि कितनी जटिलता को कम किया जा सकता है। आप अनावश्यक जटिलता को समाप्त कर सकते हैं, लेकिन आप केवल आवश्यक जटिलता को समाप्त (समाप्त नहीं) कर सकते हैं - वह जटिलता जो आवश्यकताओं में निहित है। यकीनन, जटिलता का प्रबंधन करने वाले तंत्र भी जटिलता को बढ़ाते हैं - कुछ अतिरिक्त जटिलता एक विशेष पहलू / मुद्दे / निर्माण के लिए प्रासंगिक विवरणों को बेहतर तरीके से प्रकट करने के लिए अप्रासंगिक जटिलता को आगे बढ़ाने में शामिल है।

— स्टीव 314

1

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

— स्टीव 314

1

@ S.Lott - यदि आप दावा कर रहे हैं कि आप क्रिसमस दिवस पर बृहस्पति की स्थिति का अनुमान लगा सकते हैं G=0, लेकिन मुझे लगता है कि आप पागल हैं। यदि आप नहीं हैं, तो आप मेरी बात याद कर रहे हैं। निश्चित रूप से आप अप्रासंगिक विस्तार को दूर कर सकते हैं, लेकिन यह अप्रासंगिक नहीं है यदि आपकी आवश्यकताओं का कहना है कि यह प्रासंगिक है। यदि आप वापस पढ़ते हैं, तो मैंने कभी दावा नहीं किया कि सभी जटिलताएं आवश्यक हैं - केवल यह कि आवश्यकताओं में कुछ जटिलता अंतर्निहित है और इसे समाप्त नहीं किया जा सकता है।

— स्टीव 314

2

स्पष्टता + मानक + कोड पुन: उपयोग + अच्छी टिप्पणियाँ + अच्छा डिजाइन पठनीयता में सुधार कर सकता है ।

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

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

— कोई मौका नहीं
स्रोत

2

क्या सादगी हमेशा पठनीयता में सुधार करती है?

नहीं, मैंने ऐसे बहुत से मामले देखे हैं जहाँ एक लाइन पर कई सरल चीजें करना कई लाइनों की तुलना में कम जटिल है।

कम कोड और सरल कोड के बीच एक व्यापार है।

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

— टॉम स्क्वायर्स
स्रोत

1

"चीजों को जितना संभव हो उतना सरल बनाएं, लेकिन कोई सरल नहीं है" - अल्बर्ट आइंस्टीन का अक्सर एक पैराफेरेस

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

— जेसी सी। स्लीकर
स्रोत

उद्धरण के लिए +1, लेकिन क्या सादगी पठनीयता में सुधार करती है?

— रिचर्ड

"चीजों को जितना संभव हो उतना सरल बनाएं फिर उन्हें सरल बनाएं" एक बेहतर विरोधाभास है क्योंकि एसडब्ल्यू इंजीनियर इंजीनियरिंग से अधिक प्रभावित हैं।

— मटकाव

1

काश लोग यह कहते हुए रुक जाते कि "चीजों को जितना हो सके उतना सरल बनाओ, लेकिन कोई सरल नहीं"। क्या हम कम से कम MakeAsGoodAsPossibleButNoMoreSo के लिए सामान्यीकरण नहीं कर सकते <Thing, Attribute> as us go to uselessly general engineering tip? (क्षमा करें @ जेसे सी। स्लीकर, आप इसे उद्धृत करने वाले एकमात्र व्यक्ति से बहुत दूर हैं, इसलिए आप वास्तव में किसी और की तुलना में मिनी-रैंट के लायक नहीं हैं)।

— psr

1

क्या सादगी हमेशा पठनीयता में सुधार करती है? हाँ। क्या प्रति पंक्ति एक कथन हमेशा सरल होता है? नहीं, कुछ भाषाओं में एक टर्नरी ऑपरेटर होता है, जो एक बार समझ में आ जाता है, तो सरल है और समतुल्य की तुलना में समझने में आसान है / अन्य कार्य।

ऐसी भाषाओं में जो एक से अधिक चर को एक पंक्ति में सेट करने की अनुमति देती हैं, ऐसा करना अक्सर सरल और सहज होता है जो कि समतुल्य की तुलना में समझने में आसान होता है।

एक और उदाहरण: नियमित अभिव्यक्तियाँ बहुत कुछ करती हैं, आम तौर पर सिर्फ एक पंक्ति में, और रेगेक्स के बिना समकक्ष अक्सर पढ़ने के लिए बहुत कठिन होता है। / \ d {3} [-] \ d {3} - \ d {4} / कम से कम कई टिप्पणियों के साथ एक फ़ंक्शन कॉल के बराबर है, और संबंधित फ़ंक्शन बॉडी की तुलना में समझना आसान है।

— jmoreno
स्रोत

1

पठनीयता और सरलता व्यक्तिपरक शब्द हैं, जो व्यक्ति और संदर्भ पर निर्भर करता है, आमतौर पर लेकिन हमेशा एक साथ नहीं चलते हैं।

एक अधिक वस्तुनिष्ठ शब्द संक्षिप्तता है - कुछ आप वर्ण गणना के द्वारा सिद्धांत रूप में गिन सकते हैं, हालांकि इसमें कुछ खामियां हैं। सादगी सादगी और पठनीयता का संकेत देती है, लेकिन (कम से कम मेरी राय में) अपवाद हैं।

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

तो, एक अच्छी तरह से चुना हुआ लंबा नाम हो सकता है ...

बेहतर व्यक्त इरादे से पठनीयता में सुधार
संक्षिप्तता कम करें - यह सब के बाद, लंबा है
सिंटैक्टिक सादगी पर कोई प्रभाव नहीं पड़ता है - कोड की सिंटैक्टिक संरचना अपरिवर्तित है

इसी तरह, मैं लिख सकता हूँ if (some_boolean == true)। समकक्ष विकल्प के साथ तुलना में if (some_boolean), यह ...

सुगमता को कम करता है
सिंटैक्टिक सादगी को कम करता है, लेकिन
बेहतर आशय व्यक्त करके पठनीयता में सुधार कर सकते हैं।

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

जो निश्चित रूप से समग्र विषयवस्तु का और प्रमाण है।

— steve314
स्रोत

1

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

लो rotsor के एक बहुत बड़े मूल्य के प्रदर्शन। वह कहता है कि यह सरल है । मेरे अनुमान में, सरल नहीं है। यह आसान है। यह आवश्यक 0 की संख्या टाइप करने के लिए हाथ के करीब है।

10000000000000000000000000000000000000000000

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

1e43

क्या आप Aidan के "सरल" कोड स्निपेट को एक काम करने के रूप में वर्णित कर सकते हैं ? इसमें कोड की 10 लाइनें (टिप्पणियों की गिनती नहीं) और कम से कम 7 ब्लॉक (जैसा कि मैं उन्हें गिनूंगा)। यदि आप टिप्पणियों का पालन करते हैं, तो आप देखेंगे कि यह कम से कम 4 चीजें करता है!

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

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

count = mapM (enumFromTo 0)

आप पाएंगे कि वास्तव में सरल कोड आसान कोड की तुलना में अधिक पठनीय है क्योंकि यह केवल एक ही काम करता है। आपको सरल कोड को समझने के लिए दूर जाने और अधिक "एक चीजें" सीखने की आवश्यकता हो सकती है । लेकिन यह हमेशा अधिक पठनीय होना चाहिए।

— एंथोनी मास्टरीन
स्रोत

1

क्या सादगी हमेशा पठनीयता में सुधार करती है?

मैं कहूंगा, शायद थोड़ा विवाद के साथ, बिल्कुल नहीं ।

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

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

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

सादगी

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

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

तुतलाना

फिर भी मुझे 90 के दशक के मध्य के अंत में LISP के साथ एक संक्षिप्त जुनून था (स्वर्गीय)। इसने मेरे "सादगी" के पूरे विचार को बदल दिया।

लिस्प है नहीं सबसे पठनीय भाषा। उम्मीद है कि कोई भी यह नहीं सोचता कि नेस्टेड कोष्ठक के बोटलोड के साथ एक पुनरावर्ती कार्य को आमंत्रित करते समय सीडीआर और सीएआर को निकालना बहुत "पठनीय" है।

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

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

LISP के बाद, मेरे लिए सादगी अतिसूक्ष्मवाद, समरूपता, लचीलापन, कम दुष्प्रभाव, कम लेकिन अधिक लचीले कार्यों के बारे में बन गई जो एक साथ कई तरह के अनंत तरीके से संयोजित होते हैं।

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

अतिसूक्ष्मवाद

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

सुरक्षा

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

शुद्ध कार्य और अपरिवर्तनीय स्थिति मेरे लिए बेहतर हो गई जब भी मैं इसे वहन कर सकता था, भले ही इसका सिंटैक्स:

sword = sharpen(sword)

... मानव सोच से थोड़ा कम सीधा और अलग है:

sharpen(sword)

पठनीयता वी.एस. सादगी

फिर भी, LISP सबसे "पठनीय" भाषा नहीं है। यह कोड के एक छोटे खंड में बहुत सारे तर्क पैक कर सकता है (संभवतः प्रति पंक्ति एक से अधिक मानव विचार)। मैं आदर्श रूप से "पठनीयता" के लिए प्रति पंक्ति एक मानव विचार को प्राथमिकता देता हूं, लेकिन "सादगी" के लिए यह जरूरी नहीं है।

"सरल" की इस तरह की परिभाषा के साथ, कभी-कभी "सरल" वास्तव में "पठनीय" के साथ प्रतिस्पर्धा कर सकता है। यह एक इंटरफेस डिजाइन के दृष्टिकोण से अधिक चीजों पर विचार कर रहा है।

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

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

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

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

0

हमेशा? - हाँ

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

उन क्षेत्रों पर ध्यान केंद्रित करें जहां अवधारणाओं का एक घना समूह है और "चंक" या "संक्षेप" या "सार" करने के तरीके ढूंढें। इसे सरल और अधिक पठनीय बनाने के लिए कोड के माध्यम से दो जोड़े बनाएं।

एक अच्छा अमूर्त मूल्य सोने में वजन के लायक है। एक अच्छा अमूर्त यह सरल बनाता है - और परिणामस्वरूप अधिक पठनीय है।

— S.Lott
स्रोत

मैं यह सोचने में मदद नहीं कर सकता कि आपके डराने वाले उद्धरण वहाँ हैं क्योंकि आप जानते हैं कि "अवधारणा" और "चंक" स्वयं व्यक्तिपरक हैं। एक व्यक्ति एकल अवधारणा तीन अलग-अलग विचारों का एक और व्यक्ति है। व्यक्तिपरक सामान का पूर्ण और उद्देश्य मापना कठिन है।

— स्टीव 314

@ Steve314: डराने वाले उद्धरण? नहीं, en.wikipedia.org/wiki/Chunking सभी को समान लगता है कि वे सरलीकरण के माध्यम से सरलीकरण का वर्णन करते हैं। (गिटार तकनीक को छोड़कर, जो अलग-अलग लगता है।) उद्धरण वहां हैं क्योंकि अमूर्तता, चंकिंग, संक्षेपण आदि के लिए बहुत सारे वैकल्पिक शब्द हैं, अगर मैं सिर्फ एक सभी वस्तुओं को चुनता हूं जो कि अमूर्तता का उपयोग नहीं करते हैं, जैसे कि मंथन। उद्धरण इस बात पर जोर देने के लिए हैं कि यह किसी भी तरह बहस का विषय है। फिर भी। यह स्पष्ट रूप से हर समय किया जाता है और एक प्राकृतिक मानव प्रवृत्ति लगती है।

— एस.लॉट

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

— स्टीव 314

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

— एस.लॉट

हाँ हम करते हैं। मैंने अन्यथा कभी नहीं कहा।

— स्टीव 314

-2

प्रश्न स्टैक ओवरफ्लो पर इस उत्तर की याद दिलाते हैं , विशेष रूप से यह उद्धरण (सादगी के साथ विकल्प)

गुणवत्ता - आप जानते हैं कि यह क्या है, फिर भी आप नहीं जानते कि यह क्या है। लेकिन यह आत्म विरोधाभासी है। लेकिन कुछ चीजें दूसरों की तुलना में बेहतर होती हैं, यानी उनमें गुणवत्ता अधिक होती है। लेकिन जब आप यह कहने की कोशिश करते हैं कि गुणवत्ता क्या है, इसके अलावा जो चीजें हैं, वह सब कुछ खराब हो जाता है! बात करने के लिए कुछ भी नहीं है। लेकिन अगर आप यह नहीं कह सकते कि गुणवत्ता क्या है, तो आप कैसे जानते हैं कि यह क्या है, या आप कैसे जानते हैं कि यह मौजूद है? यदि कोई नहीं जानता कि यह क्या है, तो सभी व्यावहारिक उद्देश्यों के लिए यह बिल्कुल भी मौजूद नहीं है। लेकिन सभी व्यावहारिक उद्देश्यों के लिए यह वास्तव में मौजूद है। ग्रेड के आधार पर और क्या हैं? और लोग कुछ चीजों के लिए किस्मत क्यों भरेंगे और दूसरों को कूड़े के ढेर में फेंक देंगे? जाहिर है कि कुछ चीजें दूसरों की तुलना में बेहतर हैं - लेकिन `` विश्वासघात '' क्या है? - तो आप गोल और गोल, मानसिक पहियों को घूमना और कहीं भी कर्षण प्राप्त करने के लिए कहीं भी नहीं है। गुणवत्ता क्या है? यह क्या है?

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

— KaptajnKold
स्रोत

1

यही कारण है कि मैंने प्रश्न में सरलता को परिभाषित किया।

— रिचर्ड

-2

प्रति पंक्ति एक फ़ंक्शन कॉल सरल है? चलो एक उदाहरण की कोशिश करते हैं!

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

तुम क्या सोचते हो? क्या प्रति पंक्ति एक कॉल वास्तव में सरल है?

— स्टीफन सकल
स्रोत

हाँ। प्रति पंक्ति एक कॉल सरल और मेरे लिए पढ़ना आसान है। हालांकि, पठनीयता है व्यक्तिपरक। (साथ ही, यह सवाल का जवाब देने के करीब भी नहीं आता है।)

— रिचर्ड

हाय स्टीफन, क्या आप इस बारे में विस्तार से सोच सकते हैं कि आप इस प्रश्न का उत्तर कैसे देते हैं? यह स्पष्ट नहीं है कि आप यहाँ क्या इंगित करना चाह रहे हैं।

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

— स्टीफन ग्रॉस

अगर आपको चेन गेटर्स करना है तो आपका कोड पूली डिज़ाइन किया गया है

— विंटर