अगर यह दोनों नहीं हो सकता है तो क्या मेरा कोड DRY या पठनीय होना चाहिए?

Question

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

मेरा सबसे हालिया उदाहरण: मेरा कार्यक्रम इनपुट लेता है, और कठोर प्रारूप दिशानिर्देशों के कारण, यह आसानी से निर्धारित कर सकता है कि इनपुट एन्क्रिप्ट किया जाना चाहिए या डिक्रिप्ट किया जाना चाहिए। सरल करने के लिए, एक बार एन्क्रिप्शन कुंजी और संदेश परिवर्तित होने / संगत होने के लिए उत्पन्न होने के बाद, यह एन्क्रिप्टेड संदेश से कुंजी को हटाने या एक अनएन्क्रिप्टेड संदेश में कुंजी को जोड़ने की बात है, वांछित आउटपुट प्राप्त करने के लिए (एन्क्रिप्शन के रूप में कुंजी के बारे में सोचो) संदेश + एन्क्रिप्शन = कोड; कोड - एन्क्रिप्शन = संदेश)। DRY स्थिति मुझसे कहती है कि मुझे अपने एन्क्रिप्टेड संदेश को अपने अनएन्क्रिप्टेड संदेश से अलग तरीके से परिवर्तित करना चाहिए ताकि जो फ़ंक्शन एन्क्रिप्शन कुंजी लेता है और संदेश पर लागू होता है उसे कभी भी भेद करने की आवश्यकता नहीं होती है। मैंने पाया है कि इसका मतलब है कि फ़ंक्शन में स्टेटमेंट्स पर कुछ नेस्टेड हैं, लेकिन तर्क ठोस प्रतीत होता है। हालाँकि, यह कोड आसानी से पढ़ने योग्य नहीं है।

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

क्या मुझे पठनीय कोड, या संक्षिप्त कोड की ओर झुकना चाहिए? या क्या मैंने इस कार्यक्षमता को प्राप्त करने और दोनों सिद्धांतों को संतुष्ट करने का एक और तरीका याद किया है? क्या यह उस पैमाने के साथ एक स्थिति है जिसमें किसी को परियोजना के उद्देश्य पर विचार करना चाहिए और उस उद्देश्य की पूर्ति के लिए सर्वोत्तम निर्णय लेने चाहिए?

अब तक, मैं संक्षिप्त, जोर देने योग्य कोड पर DRY कोड पर जोर देता हूं।

Comments

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

— जिमी हॉफ

कुछ वास्तविक कोड उदाहरण मदद कर सकते हैं, मुझे संदेह है कि आप कुछ 3 तरीके याद कर रहे हैं जैसे कि उच्च क्रम वाले कार्यों में सूखा और पठनीय कोड

— jk।

नकल नहीं है। कंसाइस वी। पठनीय और डीआरवाई वी। पठनीय दो बहुत अलग तुलनाएं हैं। संक्षिप्त नहीं होने से DRY का न होना कहीं अधिक खतरनाक है।

— djechlin

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

— KChaloux 20:10

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

— आरोन कुरत्जल्स

Answer 1

DRY एक दिशानिर्देश है, धर्म नहीं। जो लोग इसे डीआरवाई के बिंदु से ऊपर ले जाते हैं, वे इसे बहुत दूर ले गए हैं।

और सबसे पहले, प्रयोग करने योग्य कोड सर्वोपरि है। यदि कोड उपयोगी और उपयोगी नहीं है, तो यह नहीं है ... और इसे पहले स्थान पर लिखने का कोई मतलब नहीं है।

दूसरे, किसी दिन, किसी को अपना कोड बनाए रखना होगा। यदि आपका कोड मेंटेनेंस योग्य नहीं है, तो वे आपके नाम को कोसते हुए आपके "सुंदर" घने, संक्षिप्त, DRY डिज़ाइन को तोड़ देंगे। यह मत करो। मैं वह व्यक्ति रहा हूं और हर बार मुझे कोड एनोटेशन में एक निश्चित नाम दिखाई देता है, मैं कांप जाता हूं।

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

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

Comments

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

— lutze

@lutze मैं एक पर्ल और कभी-कभी माणिक कोडर हूं और निश्चित रूप से वहां के चतुर कोड को लिखने के प्रलोभन को समझ सकता हूं। इस उत्तर के एक पूर्व-पोस्ट संस्करण में शामिल था लैरी वॉल ऑन हब्रीस का एक उद्धरण - मेरा मानना ​​है कि कोड के साथ काम करते समय यह एक बहुत ही महत्वपूर्ण गुण है जो कुछ दिन बनाए रखा जाएगा। भाषाओं की संभावित समस्वरता के कारण कभी-कभी चालाक घने कोड की कोशिश करने के बजाय अधिक कोड लिखने के लाभ को प्राप्त करना मुश्किल होता है ... जब तक आपको इसे बनाए रखना होगा।

Answer 2

मुझे यकीन नहीं है कि आप DRY को समझने वाले सवाल पर आधारित हैं। DRY कोड संक्षिप्त के समान नहीं है। अक्सर यह विपरीत है।

यहाँ, मुझे यकीन नहीं है कि इस उदाहरण के लिए कौन सी बड़ी बात है। एन्क्रिप्ट करने के लिए एक फ़ंक्शन बनाएं, डिक्रिप्ट करने के लिए एक फ़ंक्शन, सामान्य कार्यक्षमता के लिए हेल्पर्स (मिक्स बाइट्स), और इनपुट लेने और एन्क्रिप्ट / डिक्रिप्ट निर्धारित करने के लिए एक सरल फ्रंट एंड ... खुद को दोहराते हुए नहीं।

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

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

Comments

महान बिंदु, मैंने वास्तव में संक्षिप्त कोड के लक्ष्य के साथ DRY सिद्धांत को थोड़ा संयोजित किया था।

— lutze

Answer 3

मैं आपके विशिष्ट मामले से अपरिचित हूं, लेकिन कुछ सामान्य दिशानिर्देश दे सकता हूं।

दोनों पठनीयता और सूखी का उद्देश्य है रख-रखाव ।

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

दुर्भाग्य से, DRY को अक्सर गलत समझा जाता है। यह आंशिक रूप से है क्योंकि यह बहुत सरल लगता है, लेकिन बहुत सी सरल चीजों की तरह यह भी अच्छा हो सकता है ... जटिल।

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

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

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

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

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

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

मैं अपनी टीम के अन्य सदस्यों के अनुभव स्तर पर भी विचार करता हूं। मैं अनुभवहीन डेवलपर्स के साथ "फैंसी" सार से बचता हूं, लेकिन अधिक परिपक्व समूहों के साथ मान्यता प्राप्त डिजाइन पैटर्न का लाभ उठाता हूं।

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

Comments

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

— lutze

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

— KChaloux

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

— सुपरकैट

Answer 4

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

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

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

Answer 5

हालांकि मैं निश्चित रूप से इस समस्या का कारण नहीं हूं कि मेरा अनुभव यह है कि जब आप DRY और पठनीयता को परस्पर विरोधी पाते हैं तो कहते हैं कि यह समय कुछ ठीक करने का है।

Answer 6

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

Comments

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

— gnat

Answer 7

मेरे करियर में बहुत बहुत कम बार मैंने एक वैध मामला पाया है जो DRY के खिलाफ पठनीयता को कम करता है। पहले इसे पठनीय बनाओ। चीजों को अच्छी तरह से नाम दें। यदि आवश्यक हो तो कॉपी और पेस्ट करें।

अब वापस कदम रखें और आपके द्वारा बनाई गई समग्रता को देखें, जैसे कि एक कलाकार अपनी पेंटिंग को देखने के लिए पीछे हट रहा है। अब आप पुनरावृत्ति को ठीक से पहचान सकते हैं।

बार-बार कोड को या तो अपनी विधि में रिफैक्ट किया जाना चाहिए, या अपनी कक्षा में निकाला जाना चाहिए।

कोड को दोहराना एक अंतिम उपाय होना चाहिए। यदि आप बार-बार कोड के दायरे को सीमित करते हैं, तो पठनीय और पहले DRY पढ़ें।