सर्वोत्तम प्रथाओं: कई छोटे कार्यों/विधियों, या तार्किक प्रक्रिया घटकों के साथ बड़े कार्यों inline?

Question

क्या यह कई छोटी विधियों (या फ़ंक्शंस) लिखना बेहतर है, या उन छोटी प्रक्रियाओं के तर्क/कोड को बस उस स्थान पर लिखना जहां आप छोटी विधि कहलाते थे? कोड को तोड़ने के बारे में क्या एक छोटे से समारोह में भले ही समय के लिए इसे केवल एक स्थान से बुलाया जाए?

यदि कोई विकल्प कुछ मानदंडों पर निर्भर करता है, तो वे क्या हैं; प्रोग्रामर को एक अच्छा निर्णय कॉल कैसे करना चाहिए?

मुझे आशा है कि उत्तर आम तौर पर कई भाषाओं में लागू किया जा सकता है, लेकिन यदि आवश्यक हो, तो दिए गए उत्तर किसी भाषा या भाषाओं के लिए विशिष्ट हो सकते हैं। विशेष रूप से, मैं एसक्यूएल (फ़ंक्शन, नियम और संग्रहीत प्रक्रियाओं), पर्ल, PHP, जावास्क्रिप्ट और रूबी के बारे में सोच रहा हूं।

Answer 1

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

फाउलर का Refactoring इस विषय के बारे में सब कुछ है, और मैं अत्यधिक अनुशंसा करता हूं।

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

Answer 2

जैसा कि आप हमेशा कह सकते हैं: यह निर्भर करता है। यह एक विधि के कार्य को नामकरण और परिभाषित करने का एक और सवाल है। प्रत्येक विधि को एक (अधिक नहीं) अच्छी तरह परिभाषित कार्य करना चाहिए और उन्हें पूरी तरह से करना चाहिए। विधि का नाम कार्य को इंगित करना चाहिए। यदि आपकी विधि को DoAandB नाम दिया गया है() अलग-अलग विधियां DoA() और DoB() होना बेहतर हो सकता है। यदि आपको सेटअप टास्क, executeTask, FinishTask जैसी विधियों की आवश्यकता है, तो उन्हें गठबंधन करने में उपयोगी हो सकता है।

कुछ बिंदु जो संकेत मिलता है, अलग अलग तरीकों की एक मर्ज उपयोगी हो सकता है:

• एक विधि अन्य तरीकों के उपयोग के बिना अकेले नहीं किया जा सकता।
• आपको कुछ आश्रित तरीकों को सही क्रम में कॉल करने के लिए सावधान रहना होगा।

कुछ बिंदु जो संकेत मिलता है, कि विधि का एक splitup उपयोगी हो सकता है:

• मौजूदा पद्धति की कुछ पंक्तियों में स्पष्ट स्वतंत्र कार्य है।
• बड़ी विधि का यूनिट-परीक्षण समस्याग्रस्त हो जाता है। यदि स्वतंत्र तरीकों के लिए परीक्षण लिखना आसान होता है, तो बड़ी विधि को विभाजित करें।

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

Answer 3

अंगूठे के कुछ नियम:

• कार्य क्या छोटे में स्क्रीन पर
• तोड़ कार्यों प्रदर्शित किया जा सकता है अगर यह कोड अधिक पठनीय बनाता है से अधिक का नहीं होना चाहिए।

Answer 4

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

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

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

Answer 5

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

Answer 6

मैं प्रत्येक कार्य को एक काम करता हूं, और केवल एक चीज करता हूं, और मैं तर्क के बहुत से स्तरों को घोंसला नहीं करने का प्रयास करता हूं। एक बार जब आप अपना कोड में फ़ंक्शंस नाम से तोड़ना शुरू कर देते हैं, तो यह पढ़ने के लिए बहुत आसान हो जाता है, और व्यावहारिक रूप से स्वयं-दस्तावेज।

Answer 7

विधि का आकार सीधे इसके cyclomatic complexity से जुड़ा हुआ है।

मुख्य लाभ विधि छोटे का आकार (कई छोटे तरीकों में एक बड़ा विधि विभाजित जिसका अर्थ है) रखा जाना चाहिए:

• बेहतर इकाई परीक्षण
• बेहतर डिबगिंग (कम cyclomatic जटिलता की वजह से) एक अधिक स्पष्ट स्टैक ट्रेस (एक विशाल विधि के भीतर एक त्रुटि के बजाय)

Answer 8

मुझे लगता है कि कई छोटी विधियां कोड को पढ़ने, बनाए रखने और डीबग करने में आसान बनाती हैं।

जब मैं एक इकाई के माध्यम से पढ़ रहा हूं जो कुछ व्यावसायिक तर्क लागू करता है, तो मैं प्रवाह का बेहतर अनुसरण कर सकता हूं यदि मुझे प्रक्रिया का वर्णन करने वाली विधि कॉल की एक श्रृंखला दिखाई देती है। अगर मुझे इस बात की परवाह है कि विधि कैसे लागू की गई है, तो मैं कोड में देख सकता हूं।

यह अधिक काम की तरह लगता है लेकिन यह अंततः समय बचाता है।

एक कला है, मुझे लगता है कि यह जानने के लिए कि क्या encapsulate करना है। हर किसी के पास राय का थोड़ा सा अंतर होता है। अगर मैं इसे शब्दों में डाल सकता हूं तो मैं कहूंगा कि प्रत्येक विधि को एक चीज करना चाहिए जिसे पूर्ण कार्य के रूप में वर्णित किया जा सके।

Answer 9

मैं आमतौर पर छोटे कार्यों में विभाजित कार्यों के लिए जाता हूं जो प्रत्येक एक एकल, परमाणु कार्य करता है, लेकिन केवल तभी यह कार्य करने के लिए पर्याप्त जटिल है।

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

Answer 10

हर बार छोटे तरीके।

वे आत्म दस्तावेज़ीकृत (एर, अगर अच्छी तरह से नाम)

वे प्रबंधनीय भागों में समस्या टूट कर रहे हैं - आप KeepingItSimple हैं।

आप ओओ तकनीकों का अधिक आसानी से (और जाहिर है) व्यवहार में प्लग का उपयोग कर सकते हैं। बड़ी विधि परिभाषा द्वारा अधिक प्रक्रियात्मक और इतनी कम लचीली है।

वे इकाई परीक्षण योग्य हैं। यह हत्यारा है, तो आप बस नहीं इकाई परीक्षण कुछ विशाल विधि है कि कार्यों की एक लोड करता है

Answer 11

कुछ मैं कोड पूरा किताब से सीखा जा सकता है:

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

आशा इस