मुझे फ़ंक्शन को कब तोड़ना चाहिए?

Question

एक मुख्य समारोह और सहायक कार्यों में एक लंबे समारोह को तोड़ने के लिए समझदार है।

मुझे पता है कि मॉड्यूल के बाहर केवल मुख्य समारोह कहा जाएगा, लेकिन इसकी लंबी लंबाई भयभीत साबित हो सकती है।

पाठ्यपुस्तकों ने लाइनों की संख्या पर एक सीमा डाली, लेकिन मुझे लगता है कि यह बहुत कठोर है।

पीएस मैं पायथन में प्रोग्रामिंग कर रहा हूं और इनकमिंग, संदेशों को संसाधित करने की आवश्यकता है। फ़ंक्शन संदेश युक्त एक ट्यूपल देता है लेकिन पाइथन के आंतरिक डेटा प्रकारों में। तो आप प्रत्येक संदेश प्रकार के लिए कुछ हद तक स्वतंत्र कोड देख सकते हैं।

डुप्लिकेट प्रश्न

When is a function too long?

Answer 1

मैं तुम्हें समस्या के दूसरे छोर से इस बारे में जाने की जरूरत है लगता है। नीचे सोचो। काम की छोटी इकाइयों की पहचान करें, जितना संभव हो सके छोटे, और इस तरह अपना कोड लिखना शुरू करें। जब आप ऊपर-नीचे कोड करते हैं और संरचित दृष्टिकोण नहीं रखते हैं तो आप केवल स्पेगेटी-कोड समस्याओं में भाग लेंगे।

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

मुझे नहीं लगता कि किसी विधि में कोड की लाइनों के लिए हार्ड नंबर होना चाहिए, लेकिन अच्छी तरह से लिखित कोड में निचली परतों में 5 से 10 लाइनों और 20 से 30 लाइनों के साथ विधियां नहीं हैं व्यापार तर्क में। आपको किसी प्रकार का मीट्रिक देने के लिए।

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

व्यक्तिगत रूप से मैं एक समारोह तोड़ता हूं अगर यह कुल लाइन या कुल प्रसंस्करण समय बचाता है।

मैं परेशान नहीं है, तो मैं केवल एक बार मुख्य समारोह प्रति सहायक चलाने

Answer 7

मुद्दा यह है कि प्रिंसिपल में विशेषीकृत कार्य करना बेहतर होता है। लेकिन जहां कोई सीमा निर्धारित करता है 1) पर कुछ निर्भर करता है) कुछ भाषाओं में "सामान्य" प्रोग्रामिंग शैली। (कोई यह देख सकता है कि ऑब्जेक्ट-ओरिएंटेड लैंगुग सी या 2 की तरह कम प्रक्रियाओं से कम होते हैं) यह प्रोग्रामिंग के आपके तरीके पर निर्भर करता है। हर हार्ड सीमा पर सवाल उठाया जाना चाहिए। IMHO। कुल मिलाकर कार्यक्रमों के कुछ "प्राकृतिक" वितरण 3) मुझे लगता है कि किसी को अपने दिमाग में क्या रखना चाहिए यह है कि एक कार्य को एक निश्चित कार्य करना चाहिए उदाहरण के लिए कुछ फ़ंक्शन इसे पार करने के लिए आमतौर पर किसी फ़ंक्शन से अधिक लंबा होता है एक संरचना में क्षेत्र। या वापस आना इस बात पर विचार करें कि विंडोज एपीआई में इवेंट लूप कैसा दिख सकता है। इसलिए सभी सुझाव देते हैं कि लंबी विधियों के लिए अच्छे कारण हो सकते हैं ...

Answer 8

यदि कोई स्वतंत्र कोड है (आपके मामले में प्रत्येक संदेश प्रकार के लिए निर्दिष्ट है) तो उन क्षेत्रों को तोड़ा जाना चाहिए।

Answer 9

आकार महत्वपूर्ण नहीं है। मेरे आकार से फैसला करें, क्या आपको करना है? - योड

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

Answer 10

यदि आपने इसे नहीं लिखा है और यह पहले से ही उत्पादन में है: कभी नहीं !!! यदि आप इसे तोड़ते हैं, तो आप इसे तोड़ने की संभावना रखते हैं, यह इतना आसान है।

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

Answer 11

अपने घटक टुकड़ों में एक लंबा कार्य तोड़ने के कई कारण हैं। सबसे महत्वपूर्ण है:

• पठनीयता
• रख-रखाव
• कोड स्पष्टता/आशय

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

Answer 12

फ़ैक्सफ़ोल्ड पेपर पर मुद्रित होने पर कभी भी ऐसा फ़ंक्शन न लिखें, जो आपके से लंबा है।

Answer 13

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

Answer 14

मुझे अंगूठे का नियम पसंद है कि अगर आप अच्छा इसके लिए डोमेन-प्रासंगिक नाम के बारे में सोच सकते हैं तो आपको सबफंक्शन को तोड़ना चाहिए।

जब कोई उप-फ़ंक्शन की परिभाषा को देखने के बिना शीर्ष-स्तरीय फ़ंक्शन को समझ सकता है, तो संभवतः आपने शुद्ध लाभ प्राप्त कर लिया है। (लेकिन जब आप इसे बहुत दूर तोड़ते हैं, तो आपके नाम डोमेन के बजाय आपके कार्यान्वयन कलाकृतियों का जिक्र करना शुरू करते हैं)