क्या प्रति फ़ंक्शन कोड की एक इष्टतम संख्या है? [बन्द है]

Question

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

यह मुझे आश्चर्यचकित करता है : क्या प्रति फ़ंक्शन LOCs की एक इष्टतम संख्या मौजूद है? यदि हां, तो यह क्या है, और क्या यह भाषाओं के बीच विचलन करता है?

Comments

अच्छे समय के लिए मिच मैककोनेल चैप्टर 7 सेक्शन 4 द्वारा कोड पूरा वॉल्यूम 2 ​​देखें।

— पीटर टर्नर

@ पेटर - मुझे लगता है कि आपका मतलब है "स्टीव

— मैककॉनेल

हाँ, अजीब बात है कि मैं किताब को देखते हुए लिखूंगा .... वासेंट मिच मैककोनेल प्रेस। बुश के चीफ ऑफ स्टाफ?

— पीटर टर्नर

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

— फ्रैंक शियरर

@Peter टर्नर: H11 ... S15 के माध्यम से S1 और I11 के माध्यम से I1। ऐसा लगता है कि वह रजिस्टरों के साथ अस्थायी चर को भ्रमित कर रहा है। ^ ^

— गैबलिन

Answer 1

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

Comments

हां, अगर हमारे पास काम की एक इकाई है तो मैं नहीं चाहता कि जो हो रहा है उसका जिस्ट पाने के लिए 50 कार्यों के बीच में कदम रखें। यदि आप इस मीट्रिक का उपयोग करके अपने कार्यों को उचित रूप से तोड़ते हैं तो उन्हें आकार में लगभग स्वाभाविक रूप से उचित होना चाहिए।

— ChaosPandion

@ChaosPandion: लेकिन आपके कार्य की इकाई को संभवतः अधिक प्रारंभिक चरणों के अनुक्रम के रूप में व्यक्त किया जा सकता है। यदि आप फ़ंक्शन की समीक्षा कर रहे हैं, तो आप चरणों के अनुक्रम की समीक्षा करेंगे, प्रत्येक एकल चरण के कोड की नहीं।

— विज़ार्ड79

@ लॉरेंजो - अगर ऐसा है तो प्रत्येक चरण कार्य की इकाई बन जाता है। मूल फ़ंक्शन कार्य की इकाइयों का एक उच्च स्तरीय अवलोकन बन जाता है।

— ChaosPandion

हाँ, यह वास्तव में बहुत सच है। हम्म, मुझे फिर से सवाल पूछना चाहिए: क्या कार्यों के लिए एलओसी की एक इष्टतम संख्या है जो केवल एक ही काम करती है, और क्या यह अच्छी तरह से करती है?

— गाब्लिन

@ गेबलिन, कहना मुश्किल है और एलओसी भी भाषा पर निर्भर है, लेकिन यदि आप इस सिद्धांत का पालन करते हैं, तो आमतौर पर आप एक उचित सीमा के भीतर समाप्त होते हैं, 1 ~ 50 कहते हैं।

— ग्रुकस

Answer 2

एक पुराना अंगूठा नियम यह है कि एक फ़ंक्शन स्क्रॉलिंग की आवश्यकता के बिना स्क्रीन पर पूरी तरह से दिखाई देनी चाहिए।

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

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

Comments

औसत निगरानी आकार / रिज़ॉल्यूशन बढ़ने पर यह मीट्रिक उत्तरोत्तर अधिक बेकार हो जाता है।

— एडम लेअर

हमारे प्रोग्रामिंग प्रोफेसर ने इस उदाहरण को दूसरी रात कहा

— cdnicoll

@ अन्ना: ठीक है, मेरा मॉनिटर उच्च रेस है, लेकिन टूलबार / पैलेट / पैनल की संख्या में भी वृद्धि हुई है। और फिर, अब मैं 14 pt पिच फ़ॉन्ट का उपयोग कर सकता हूं! :)

— जादूगर 79३

एक टर्मिनल के 24 x 80 आकार में परिवर्तन नहीं होता है।

— वैकल्पिक

बकवास, नियम की बात यह है कि "क्या आप इसे बिना स्क्रॉल किए देख सकते हैं"। एक बड़े मॉनिटर के साथ आप इस नियम का उल्लंघन किए बिना अपने फ़ंक्शन में अधिक हो सकते हैं, इसका मतलब यह नहीं है कि बड़े मॉनिटरों को केवल छोटे कार्यों को देखने की अनुमति है (हालांकि आपके आईडीई के पास सभी टूलबार और संपत्ति खिड़कियां हैं, यह संभवतः अभी भी सही है: - ))

— gbjbaanb

Answer 3

वहां कोई नहीं है।

स्क्रीन बड़ी, फॉन्ट साइज छोटी हो रही हैं। अंगूठे के नियम इतने अच्छे से काम नहीं करते हैं जब लोगों के अलग-अलग आकार के अंगूठे होते हैं।

संक्षिप्त रखें। यदि आपका कार्य कई कार्य करता है तो इसे छोटे लोगों में तोड़ना एक अच्छा विचार है।

Comments

कम से कम आप कर सकते हैं मुझे बताएं कि आपको क्यों लगता है कि मेरा उत्तर उपयोगी नहीं है।

— जोश के

मुझे लगता है कि किसी को h1 टैग के उपयोग से नाराज था ।

— ChaosPandion

@चेओस: यह आवश्यक उत्तर है।

— जोश के

शायद मैं थोड़ा बहुत सूक्ष्म था लेकिन मेरा आशय यह था कि आपके उत्तर को वोट करने का कोई उचित कारण नहीं है। जिसने भी काम किया उसके पास ऐसा करने के लिए कुछ यादृच्छिक व्यक्तिगत कारण थे। वे बस सोच सकते हैं कि जोश एक भयानक नाम है।

— ChaosPandion

Answer 4

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

डिफ़ॉल्ट रूप से, एक ब्राउज़र बहुत बड़ा नहीं है। स्क्रॉल करने से पहले आपको 5 या 6 लाइनों को फिट करना होगा। स्क्रॉलिंग, ज़ाहिर है, थोड़ा परेशान है।

तो स्मॉलटाक में पर्यावरण आपको "लघु" लिखने के लिए प्रोत्साहित करता है, जिसकी लंबाई लगभग 6 पंक्तियों की है। (यह आम तौर पर बहुत है; स्मालटाक एक बहुत अच्छी भाषा है।)

Answer 5

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

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

"अन्यथा हमारे पास कई कार्य होंगे, जिनमें से सभी में केवल एक पंक्ति या दो कोड होते हैं।"

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

Answer 6

उत्तर 42 का है ।

नोट करने के लिए महत्वपूर्ण: कोई भी फफूंद कभी भी एसआरपी का उल्लंघन नहीं कर सकती है , या आपको स्पैनिश पूछताछ का सामना करना पड़ता है ।

कुछ संकेत कैसे लाइनों के ammount को कम करने के लिए:

• क्या व्यक्तिगत अनुभागों को चिह्नित करने वाली टिप्पणियां हैं? उन वर्गों के कार्य होने चाहिए।
• क्या कारखाने-बिल्डर के बाहर अन्य चेन या स्विच स्टेटमेंट हैं? जिम्मेदारियों को विभाजित करने में मदद के लिए आपके डिज़ाइन को कुछ बेहतर डिज़ाइन पैटर्न की आवश्यकता हो सकती है।
• क्या आपके कार्यों का परीक्षण करना आसान है? अपने कार्यों को परीक्षण करना आसान बनाएं, वे अलग हो जाएंगे।
• क्या यह जटिल है और सिग्थ (1000 लाइन राक्षसों) में कोई जमीन नहीं है? स्क्रैप रीफैक्टरिंग करें - यह रिफ्लेक्टर है और कोड जिम्मेदारियों के बारे में शिक्षित होने की उम्मीद में इसे न बचाएं।

Comments

N को उम्मीद है कि स्पैनिश ... आह बेजर , मैं यहाँ थोड़ा लेट हूँ।

— 1

Answer 7

यहाँ कुछ सुराग दिए गए हैं:

• यदि आपको फ़ंक्शन के उद्देश्य और उपयोग की व्याख्या करते हुए टिप्पणी लिखने में परेशानी हो रही है, तो यह बहुत लंबा है।

• यदि आप फ़ंक्शन में कोड के एक भाग की गतिविधि की व्याख्या करते हुए टिप्पणी लिखने के लिए ललचाते हैं, तो फ़ंक्शन बहुत लंबा है।

• यदि आप किसी अन्य फ़ंक्शन से कोड पेस्ट कर रहे हैं, तो वे दोनों बहुत लंबे हैं (उस कोड को एक अलग फ़ंक्शन के रूप में निकालें)।

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

• यदि आपको किसी फ़ंक्शन को पढ़ते समय नोट्स लेने की आवश्यकता है, तो यह बहुत लंबा है।

कार्यों के 'टन' होने से, प्रत्येक केवल एक या दो लाइनें लंबी होती हैं, जरूरी नहीं कि यह एक बुरी चीज हो। मैंने पाया कि उन छोटे कार्यों का पुन: उपयोग किया गया था जो कि मुझे शुरू में उम्मीद थी।