2011-01-14 24 views
6

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

मुझे अच्छी तरह से पता है कि यह आपके कार्यों/विधियों को यथासंभव छोटा रखने के लिए अच्छा प्रोग्रामिंग अभ्यास है। फिर भी आप वास्तव में कैसे जानते हैं कि कोई फ़ंक्शन बहुत लंबा है या नहीं? वैकल्पिक रूप से, क्या कभी भी कार्यों को तोड़ना कभी संभव है?

पहली प्रोग्रामिंग भाषा जो मैंने सीखा (एप्पलॉफ्ट बेसिक के अलावा, जो गिनती नहीं है ...) 6502 असेंबली भाषा थी, जहां गति और अनुकूलन सब कुछ है। ऐसे मामलों में जहां कुछ चक्र गणना आपके पूरे कार्यक्रम के समय को खराब कर देती हैं, अक्सर स्मृति स्थान सेट करना या किसी अन्य सबराउटिन पर कूदने के बजाय सीधे पंजीकरण करना बेहतर होता है। पूर्व ऑपरेशन में 3 या 4 चक्र लग सकते हैं, जबकि पूरी तरह से बाद वाले को दो या तीन बार लग सकते हैं।

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

विशेष रूप से, मान लीजिए कि (फिर से सी ++ का उपयोग करते हुए) हम एक निजी वर्ग विधि ऐसा ही कुछ है डालते हैं निम्नलिखित:

int Foo::do_stuff(int x) { 
    this->x = x; 
    // various other operations on x 
    this->y = this->x; 
} 

मैं कुछ तर्क देखा है कि, कम से कम, आपरेशन के प्रत्येक सेट करना चाहिए अपना स्वयं का कार्य हो। उदाहरण के लिए, do_stuff() सिद्धांत को set_x (int x) में नामित किया जाना चाहिए, कक्षा सदस्य x पर किए गए संचालन के सेट के लिए एक अलग फ़ंक्शन लिखा जाना चाहिए, और तीसरे फ़ंक्शन को वर्ग सदस्य के अंतिम मान को असाइन करने के लिए लिखा जाना चाहिए एक्स से वर्ग सदस्य वाई। लेकिन मैंने अन्य तर्क देखा है कि प्रत्येक ऑपरेशन का अपना कार्य होना चाहिए।

मेरे लिए, यह गलत लगता है। फिर, मैं एक आंतरिक परिप्रेक्ष्य से चीजों को देख रहा हूँ; प्रत्येक विधि कॉल स्टैक पर एक पता दबा रहा है, इसके संचालन कर रहा है, फिर subroutine से लौट रहा है। यह अपेक्षाकृत सरल कुछ के लिए बहुत अधिक ओवरहेड की तरह लगता है।

क्या इस तरह की चीज़ के लिए सबसे अच्छा अभ्यास है या क्या यह व्यक्तिगत निर्णय के लिए अधिक है?

उत्तर

8

6502 असेंबली के दिनों के बाद से, दो चीजें हुई हैं: कंप्यूटर बहुत तेज हो गए हैं, और कंपाइलर्स (जहां उचित हो) बेहतर हो गए हैं।

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

इसके बजाय, अपने कार्यों काफी छोटा होने के लिए बनाने के बारे में सोचना शुरू करते हैं:

  • समझ में आता है,
  • परीक्षण योग्य,
  • फिर से प्रयोग करने योग्य है, शायद, जहां कि उचित है।

यदि बाद में, आप पाते हैं कि आपका कुछ कोड पर्याप्त तेज़ी से नहीं चल रहा है, तो इसे अनुकूलित करने के तरीके पर विचार करें।

नोट: अनुकूलन संकलक करने के लिए संकेत करने के लिए समारोह इनलाइन स्थानांतरित करने के लिए हो सकता है, तो आप अभी भी प्रदर्शन हिट के बिना ऊपर फायदे मिलता है।

+0

धन्यवाद, यह निश्चित रूप से सहायक है। सी ++ मेरी पहली गैर-असेंबली भाषा का मतलब नहीं है, लेकिन चूंकि मैंने कभी भी किसी भी चीज में औपचारिक प्रशिक्षण नहीं लिया है, इसलिए मैंने सोचा कि कोडिंग प्रथाओं पर कुछ प्रतिक्रिया प्राप्त करना सर्वोत्तम है। – xobicvap

+1

+1 यह कहने के लिए कि चक्र होने की चिंता न करें जब तक कि यह कोई समस्या न हो। सभी बुराईयो की जड़ समयपूर्व इष्टतमीकरण है। – riwalk

5

फ़ंक्शन को तोड़ने का निर्णय लेने के बारे में सबसे महत्वपूर्ण बात यह नहीं है कि फ़ंक्शन कितना कार्य करता है। यह आपकी कक्षा के एपीआई को निर्धारित करने के बारे में है।

हम Foo::set_x, Foo::twiddle_x, और Foo::set_y में Foo::do_stuff तोड़ने मान लीजिए। क्या यह कभी भी इन परिचालनों को अलग-अलग करने के लिए समझ में आता है? क्या कुछ बुरा होगा यदि मैं x को बिना किसी सेटिंग के जोड़ता हूं? क्या मैं पर कॉल किए बिना set_y पर कॉल कर सकता हूं? इन्हें अलग-अलग तरीकों से तोड़कर, उसी वर्ग के भीतर भी निजी विधियां, आप यह कह रहे हैं कि वे कम से कम संभावित रूप से अलग-अलग ऑपरेशन हैं।

अगर ऐसा नहीं है, तो हर तरह से उन्हें एक समारोह में रहते हैं।

+1

+1। राज्य/वस्तुओं की आविष्कार और स्थिरता बनाए रखना रखरखाव सॉफ्टवेयर की कुंजी है। –

+0

यह वही लाइनों के साथ काफी सुंदर है जो मैं सोच रहा था, लेकिन मैं यह सुनिश्चित करना चाहता था। उपरोक्त उदाहरण का उपयोग करके, एक फ़ंक्शन में जो मैं वर्तमान में लिख रहा हूं, set_x के बिना set_y के लिए कभी भी कोई कारण नहीं है और twiddle_x को पहले कहा जा रहा है। अन्य (गैर-ओओपी) भाषाओं से आने के बाद, मैं वास्तव में * encapsulation की सराहना करता हूं कि यह मुझे अपने सिर में परिभाषित करने में मदद करता है कि कैसे एक विशेष चर बदलना चाहिए और इसे बदलने का अधिकार क्या है। मैं इसके साथ * बहुत * ओवरबोर्ड जाने का थोड़ा डर रहा हूं। इन दिशानिर्देशों की मदद करनी चाहिए। – xobicvap

0

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

हालांकि अगर हम अन्य चिंताओं एक तरफ रख दिया है, वहाँ स्पष्ट इनलाइन बयान कर रहे हैं, और अधिक महत्वपूर्ण बात यह संकलक अनुकूलन है कि अक्सर तुच्छ फ़ंक्शन कॉल के साथ शामिल भूमि के ऊपर के सबसे निकाल सकते हैं। कंपाइलर एक अविश्वसनीय रूप से स्मार्ट ऑप्टिमाइज़िंग मशीन है, और अक्सर हम फ़ंक्शन कॉल को अधिक बुद्धिमान ढंग से व्यवस्थित कर सकते हैं।

+0

मैं सहमत हूं, हालांकि शैतान के वकील को खेलने के लिए मैं यह कहना चाहूंगा कि मुझे लगता है कि कम से कम असेंबली भाषा का ज्ञान निश्चित रूप से सहायक है जिसमें कम से कम कुछ विचार है कि सीपीयू स्तर पर चीजें कैसे काम करती हैं। उसी समय, मैं असेंबली प्रोग्रामिंग को याद नहीं करता हूं। पठनीयता एएसएम कोड में वस्तुतः zilch है, न केवल शब्दावली के कारण। – xobicvap

+0

@ubtng, सहमत हुए, मैं इसके विपरीत को लागू करने का इरादा नहीं था। मेरा मुद्दा यह था कि जब लोग ड्राइंग बोर्ड में जाते हैं, तो प्राथमिकता सूची पर फ़ंक्शन अपघटन उच्च नहीं होता है। जहां तक ​​मैं चिंतित हूं, असेंबली महान है! अपठनीय, लेकिन महान! – davin

3

मुझे अच्छी तरह पता है कि यह आपके कार्य/तरीकों संभव

मैं छोटे करने के लिए अपने कार्यों refactor करने के लिए उपरोक्त मानदंडों का उपयोग नहीं होता जितना संक्षिप्त रखने के लिए अच्छा प्रोग्रामिंग अभ्यास हूँ। नीचे मैं क्या उपयोग

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

अन्य good practices for Method Design

  1. ग्राहक कुछ भी मॉड्यूल क्या कर सके
  2. सिद्धांत का उल्लंघन नहीं करते यह सुनिश्चित नहीं है कम से कम के विस्मय
  3. के रूप में जल्द ही फास्ट रिपोर्ट त्रुटियाँ विफल
  4. देखभाल के साथ अधिभार
  5. उपयोग उचित पैरामीटर और लौटें प्रकार
  6. उपयोग लगातार पैरामीटर तरीके पार आदेश
  7. बचें लांग पैरामीटर सूचियाँ
  8. बचें वापसी मान असाधारण प्रसंस्करण
2

मांग Clean Code: A Handbook of Agile Software Craftsmanship पढ़ने के बाद, जिस पर लगभग हर टुकड़ा छुआ इस पृष्ठ पर सलाह के बारे में मैंने कम लिखना शुरू कर दिया। छोटे कार्यों के लिए नहीं बल्कि पठनीयता और टेस्टेबिलिटी में सुधार करने के लिए, उन्हें एक ही स्तर पर अबास्ट्रक्शन पर रखें, उन्हें केवल एक चीज करें, आदि

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

संबंधित मुद्दे