कई बार बड़े कार्यक्रमों को लिखने के दौरान मैंने सवाल किया है कि कोड को किसी फ़ंक्शन या विधि में डालने के लिए कितने कॉपी और पेस्ट होते हैं और अंगूठे का एक अच्छा नियम क्या है? मैं चार लाइनों के अंगूठे के नियम का उपयोग कर रहा हूं या अधिक से अधिक दो बार दिखाई दे रहा हूं, फिर मैं एक सरल फ़ंक्शन / विधि बनाता हूं जिसमें वह कोड होता है। क्या आप बेहतर अभ्यास के बारे में सोच सकते हैं या कोई संकेत दे सकते हैं? यह सामान्य डिज़ाइन पैटर्न प्रश्न के बजाय अधिक है तो भाषा विशिष्ट प्रश्न।
जवाबों:
मैं कोड को दस्तावेज करने के तरीके के रूप में आंशिक रूप से फ़ंक्शन का उपयोग करता हूं। एक फ़ंक्शन को सार्थक नाम से कॉल करने से कोड को समझना आसान हो जाता है। कुछ मामलों में भी एक पंक्ति के साथ एक फ़ंक्शन समझ में आता है।
उदाहरण के लिए, "क्लीन कोड" में, रॉबर्ट सी। मार्टिन निम्नलिखित उदाहरण देते हैं: आप कौन सा बल्कि देखेंगे? यह:
// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
(employee.age > 65))
या यह?
if (employee.isEligibleForFullBenefits())
मैं हमेशा उसके साथ सहमत नहीं हूं, लेकिन इस मामले में मैं करता हूं। कोड पठनीय होना चाहिए, न केवल जब आप इसे लिखते हैं और आप हर विवरण को जानते हैं, बल्कि 9:00 बजे भी जब आपको किसी और के कोड में कीड़े को ठीक करना होगा। एक लंबी स्थिति में घूरने और सभी दोहरे नकारात्मक प्रभावों का पता लगाने की कोशिश नहीं की जाती है। यदि आप केवल इस पर एक नाम रख सकते हैं (न केवल स्थितियां, बल्कि आपके द्वारा लिखा गया प्रत्येक कोड), तो यह बहुत सरल हो जाता है।
मुझे कभी किसी फ़ंक्शन में कुछ डालने का पछतावा नहीं है, और यदि आप प्रदर्शन के बारे में चिंतित हैं, तो पहले प्रोफ़ाइल करें।
एक व्यापक गलतफहमी है कि फ़ंक्शन कॉल केवल दोहराए जाने वाले कोड सेगमेंट से बचने के लिए किए जाने चाहिए। मेरे अंगूठे का नियम यह है कि किसी भी तार्किक इकाई का कार्य एक फ़ंक्शन में किया जाना चाहिए, तब भी जब इसे केवल एक ही स्थान पर उपयोग किया जाता है। यह आमतौर पर एक बेहतर पठनीयता की ओर जाता है, और आपको स्व-दस्तावेजीकरण कोड लिखने की अनुमति देता है, जहाँ फ़ंक्शन नाम टिप्पणियों की जगह लेते हैं और आपको यह बताते हुए अतिरिक्त टिप्पणियां लिखने की आवश्यकता नहीं है कि आप क्या कर रहे हैं।
यदि यह एक से अधिक स्थानों में उपयोग किया जाता है, और
फिर इसे एक फ़ंक्शन या विधि बनाएं। मेरे अनुभव में, बार-बार कोड के लंबे टुकड़े, स्वाभाविक रूप से इन श्रेणियों में से एक में गिरेंगे (आमतौर पर पहले एक, लेकिन फिर श्रेणियां बहुत अधिक होती हैं;)। बेशक, इंटरफ़ेस में जो कुछ भी होना है, वह भी अपने आप में एक फ़ंक्शन / विधि है।
float x, int yऔर double density, तो उन गणनाओं को एक सी फ़ंक्शन के रूप में सेट करना कोड को दोहराए जाने की तुलना में मुश्किल हो सकता है, क्योंकि आपको सभी तीन मूल्यों को प्राप्त करने का एक तरीका तैयार करना होगा। यदि दोहराया अभिकलन स्वयं तुच्छ हैं, तो कभी-कभी केवल इनलाइन छोड़ना बेहतर होता है।
लगभग हमेशा, खासकर यदि प्रत्येक डुप्लिकेट वैचारिक दृष्टिकोण से एक ही ऑपरेशन का प्रतिनिधित्व करता है। यदि यह उसी तरह से किया जाता है, लेकिन विभिन्न प्रकारों पर, एक सामान्य कार्यान्वयन करें।
एकमात्र कारण यह नहीं है कि मैं सोच सकता हूं कि रखरखाव में से एक है: कभी-कभी कुछ दोहराव की कीमत पर भी, अलग-अलग चीजों के बीच निर्भरता बनाने से बचने के लिए यह अधिक सुविधाजनक हो सकता है।
" रिफैक्टिंग " के लिए एक खोज आपको इस बहुत ही सामान्य प्रक्रिया के लिए उद्योग "सर्वोत्तम प्रथाओं" के लिए कई संसाधनों तक ले जाएगी। कुछ हद तक प्रसिद्ध लेख, वंस एंड ओनली एक बार एक महान ऐतिहासिक संदर्भ है जो यह बताता है कि आपके प्रश्न द्वारा उठाए गए चिंताओं के लिए "सर्वोत्तम प्रथाओं" के रूप में कुछ दृश्य क्या हैं। इसके अलावा, और भी सामान्य अवधारणा को डोन्ट रिपीट योरसेल्फ (DRY) के रूप में जाना जाता है । अपने प्रश्न के उत्तर की गहराई से सेट के लिए, मार्टिन फाउलर के महान क्लासिक, रिफ़ैक्टरिंग: मौजूदा कोड के डिज़ाइन में सुधार करना , जो कि रीफ़ैक्टरिंग के लिए सबसे अच्छी ज्ञात सलाह में से कुछ को कवर करता है , जिसे आप सहज ज्ञान के साथ पूरा करने की कोशिश कर रहे हैं। !
यदि कोड एक ही बार में एक से अधिक बार दोहराया जाता है और दोहराया अनुभाग निकट भविष्य में नहीं बदलेगा, तो मैं इसे एक फ़ंक्शन में तोड़ देता हूं।
यह दोहराया कोड के सामंजस्य की प्रकृति पर निर्भर करता है। यदि कोड का दोहराया अनुभाग एक विशिष्ट कार्य कर रहा है, तो यह एक विधि में बनाए जाने के लिए एक उत्कृष्ट उम्मीदवार है, आंशिक रूप से DRY सिद्धांत के कारण, आंशिक रूप से क्योंकि यदि फ़ंक्शन को अनुकूलित या सही करने की आवश्यकता है, तो केवल एक खंड है से निपटने के लिए कोड की।
यदि एसोसिएशन संयोग है, तो इसे विधि में बनाने के बजाय कोड को दोहराना बेहतर है। यदि आपको उस स्निपेट के उपयोगों में से एक को संतुष्ट करने के लिए कोड अनुक्रमों में से किसी एक के बीच में कुछ जोड़ने की आवश्यकता है, यदि यह एक विधि में है, तो आप जो परिवर्तन करते हैं, वह उस पद्धति के अन्य उपयोगों को प्रभावित कर सकता है।
कोड सामंजस्य की अवधारणा पर विकिपीडिया लेख देखें ।
आपको संरचित प्रोग्रामिंग भावना और एक वर्ग के तरीकों में कार्यों के बीच अंतर करना होगा।
आपके उदाहरण में, आपने जो दिखाया है वह एक विधि है जैसे कि इन-लाइन को कोडित नहीं किया जाना चाहिए।
आपको यह देखने के लिए एक स्ट्रिंग को मान्य करना पड़ सकता है कि यह संख्या है या नहीं, इस मामले में, आप एक फ़ंक्शन का उपयोग करते हैं और अधिकांश पूर्ववर्ती उत्तर लागू होते हैं।
यह भेद विशेष रूप से बड़ी परियोजनाओं में महत्वपूर्ण है।
जितना आप कर सकते हैं, कंप्यूटिंग एल्गोरिदम (कि शुद्ध प्रोग्रामिंग फ़ंक्शन हैं) से व्यावसायिक नियमों (कि विधियां) को अलग करने का प्रयास कर सकते हैं।