जावा में प्रति वर्ग कितनी लाइनें हैं? [बन्द है]

Question

आपके अनुभव में, जावा में एक वर्ग के लिए कोड की कितनी लाइनें बहुत अधिक हैं, इसके लिए अंगूठे का एक उपयोगी नियम क्या है?

स्पष्ट होने के लिए, मुझे पता है कि किसी विशेष वर्ग में क्या होना चाहिए और क्या नहीं होना चाहिए, इसके लिए उपयोग करने के लिए लाइनों की संख्या वास्तविक मानक के करीब भी नहीं है। वर्गों को उचित ओओपी दर्शन (एनकैप्सुलेशन, आदि) को ध्यान में रखते हुए डिजाइन किया जाना चाहिए। उस ने कहा, अंगूठे का एक नियम विचार को प्रतिबिंबित करने के लिए एक उपयोगी प्रारंभिक बिंदु प्रदान कर सकता है (यानी "" हम्म, इस वर्ग में कोड की n लाइनें हैं; यह संभवतः अपठनीय है और इनकैप्सुलेशन का घटिया काम कर रहा है, इसलिए मैं यह देखना चाहता हूं कि क्या यह चाहिए कुछ बिंदु पर रिफ्लेक्ट किया जाए ")।

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

यहां प्रति फ़ंक्शन लाइनों के बारे में एक गैर-डुप्लिकेट प्रश्न है ।

Comments

मैंने एक हजार से अधिक लाइनों के साथ कक्षाएं देखी हैं, मुझे नहीं लगता कि "बहुत सारे" जैसी कोई चीज है।

— महमूद होसाम

यह बहुत अधिक है जब यह किसी भी अधिक संकलन नहीं होगा। गंभीरता से, यह केवल बहुत से है जब वर्ग बहुत अधिक भिन्न चीजें कर रहा है।

— बेरिन लोरिट्श

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

— एसटी।

स्ट्रिंग के एक टुकड़े के लिए इंच की सही संख्या के समान है।

— मैट

30 वोटों के साथ एक प्रश्न, ~ 24k बार देखा गया, (सामूहिक रूप से) ~ 75 वोटों के साथ 10 उत्तर। "मुख्य रूप से राय-आधारित के रूप में बंद" स्टैक एक्सचेंज में आपका स्वागत है :) एसई संस्कृति में कुछ बदलने की जरूरत है ...

— जेबी।

Answer 1

कुछ दिलचस्प मीट्रिक:

            जूनट फिटनेस टेस्टएनजीएम टैम जडपेंडेड चींटी टॉमकैट
            ----- -------- ------ --- ------- --- ------
अधिकतम 500 498 1450 355 668 2168 5457
माध्य 64.0 77.6 62.7 95.3 128.8 215.9 261.6
मिनट 4 6 4 10 20 3 12
सिग्मा 75 76 110 78 129 261 369
फाइलें 90 632 1152 69 55 954 1468
कुल लाइनें 5756 49063 72273 6575 7085 206001 384026

मैं FitNesse को एक बेंचमार्क के रूप में उपयोग करता हूं क्योंकि मुझे इसे लिखने के लिए बहुत कुछ करना था। FitNesse में औसत वर्ग 77 लाइनों लंबा है। 498 लाइनों में से कोई भी लंबा नहीं है। और मानक विचलन 76 लाइनें हैं। इसका मतलब है कि वर्गों के विशाल बहुमत 150 से कम लाइनें हैं। यहां तक ​​कि टॉम्कट, जिसमें 5000 से अधिक लाइनों में एक वर्ग है, अधिकांश वर्गों में 500 से कम लाइनें हैं।

इसे देखते हुए हम शायद नीचे रहने के लिए एक अच्छी दिशानिर्देश के रूप में 200 लाइनों का उपयोग कर सकते हैं।

Comments

यदि कक्षा की एक ही ज़िम्मेदारी है, तो इसके 200-500 से ऊपर जाने की संभावना बहुत पतली है। अन्य संबंधित जिम्मेदारियों को संभालने के लिए आम तौर पर "आंतरिक कक्षाएं" होती हैं । उदाहरण के लिए, Tomcat 5000+ लाइन क्लास वास्तव में एक दर्जन आंतरिक कक्षाओं के साथ 1 मुख्य वर्ग हो सकता है। यह जावा में असामान्य नहीं है जहां आपके पास अनुरोध करने वाले हैंडलर और ऐसे हैं।

— बेरिन लोरिट्श

ये मेट्रिक्स वास्तव में कैसे प्राप्त किए जाते हैं? बस जानना चाहते हैं

— SANđошƒа

मैं आमतौर पर कार्यों से संबंधित जुड़े प्रश्न पर इस उत्तर की ओर अधिक झुकूंगा : प्रोग्रामर.स्टैकएक्सचेंज. com/a/9452/100669 एलओसी एक तरह का अप्रासंगिक है, सिवाय इसके कि शायद एक बहुत ही सामान्य नियम अंगूठे का केवल यह सोचना शुरू कर दें कि क्या हो सकता है आगे चीजों को तोड़ने में सक्षम हो। और मैं नेस्टेड क्लासेज की बात से सहमत हूं। बहरहाल, 500 शायद एक सामान्य चेतावनी संकेत के करीब है।

— Panzercrisis

@ Sain.com/ошƒаӽ github.com/AlDanial/cloc

— फायरफिल

Answer 2

मेरे लिए, इस संदर्भ में कोड की लाइनें अप्रासंगिक हैं। यह सब विभिन्न कारणों की संख्या के बारे में है जो मैं इसे बदलने के लिए इस वर्ग में आऊंगा।

अगर मैं एक व्यक्ति को मान्य करने के लिए नियमों को बदलना चाहता हूं, तो मैं इस वर्ग में आऊंगा, मैं एक आदेश को मान्य करने के लिए नियमों को बदलने के लिए एक ही वर्ग में नहीं आना चाहता, और न ही मैं यहां बदलना चाहता हूं जहां मैं बदलूं एक व्यक्ति बनी रहें।

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

Comments

200 के बारे में सही लगता है एक बहुत ही मोटे अनुमान के रूप में। जैसा कि आप कहते हैं, न कि वह चीज जिसकी आप पहले चिंता करते हैं।

— स्टीव

जावा के बारे में सुखद बात यह है कि जब LOCs की गिनती होती है तो मैं गेटर्स / सेटर्स को अनदेखा कर देता हूं।

— MrFox

@ मॉर्फॉक्स: मैं असहमत हूं। यदि आपकी कक्षा में पर्याप्त गेटर्स हैं और LOC डेटा को तिरछा करने के लिए बसता है, तो इसके विरुद्ध "क्या यह वर्ग बहुत कुछ कर रहा है?" सवाल। हालांकि, एक समझौते के रूप में मैं नेटबैन पाने वाले को तैयार करूंगा / कम से कम 1 लाइन / लाइन से अधिक बायलर-प्लेट के लिए सम्मान से बाहर होना चाहिए।

— ब्रायन

Answer 3

मुझे खेद है, लेकिन मुझे बहुत आश्चर्य है कि कई उत्तर बताते हैं कि यह "वास्तव में कोई फर्क नहीं पड़ता"। यह बहुत MUCH मायने रखता है कि एक कक्षा में कितनी लाइनें हैं। क्यों? अच्छा जावा कोड लिखने में इन सिद्धांतों पर विचार करें ...

• testability
• एकजुटता
• युग्मन
• understandability

उन में बहुत सी पंक्तियों वाली कक्षाएं उन सभी सिद्धांतों का सबसे अधिक उल्लंघन करेंगी।

उन लोगों के लिए जिन्होंने यह कहा है कि "वास्तव में कोई फर्क नहीं पड़ता" ... आपके लिए उस वर्ग को 5000+ पंक्तियों की कोशिश करने और समझने में कितना मज़ा आया है? या, इसे संशोधित करने के लिए? यदि आप कहते हैं कि यह मजेदार है, तो आपको दर्द के प्रति एक अजीब समानता मिली है ...

मैं कहूंगा कि किसी भी वर्ग के पास 1000 से अधिक लाइनें हैं , कम से कम यह सवाल किया जाना चाहिए कि वे ऊपर के सिद्धांतों का उल्लंघन कैसे कर सकते हैं और संभवत: कई "ऑफ-शूट" कक्षाओं में पार कर गए हैं।

मेरी टिप्पणियाँ मार्टिन फाउलर, जोशुआ बलोच और मिसको हेवरी जैसे लेखकों को पढ़ने और अध्ययन करने पर आधारित हैं। वे अच्छे जावा कोड लिखने के लिए परामर्श करने के लिए उत्कृष्ट संसाधन हैं।

अगले आदमी को करो (जो कि आप कुछ वर्षों में हो सकते हैं) एक एहसान करते हैं और उन वर्गों को लिखने का प्रयास करते हैं जिनके पास अधिक लाइनों के बजाय कम है।

Comments

मैं सभी सहमत हैं कि 5000+ है लगता नहीं आम तौर पर एक अच्छा संकेत (नेस्टेड वर्गों की गिनती नहीं), लेकिन उन्हें लगता है जैसे कि यह एक पक्ष प्रभाव या वास्तविक समस्या से कुछ की अधिक है। बेशक, कुछ लोग अत्यधिक क्रिया कर रहे हैं और चर को घोषित करने और शुरू करने के लिए अत्यधिक संख्या में लाइनों का उपयोग करते हैं और ऐसे - और उन्हें रोकने की आवश्यकता है। यही कारण है कि करता है यह कम पठनीय हैं। लेकिन अगर यह वर्ग संरचना से संबंधित है, तो समस्या एलओसी नहीं है; यह तथ्य यह है कि किसी ने अभी शुरू करने के लिए चीजों को बहुत अच्छी तरह से नहीं तोड़ रहा है, और एलओसी उसी का एक दुष्प्रभाव है।

— पैंजरक्रिसिस

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

— जैक्सबी 10

Answer 4

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

एक और चीज जो आप देख सकते हैं वह है एक वर्ग में सार्वजनिक कार्यों की संख्या। यह एक चेतावनी संकेत भी हो सकता है।

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

Comments

+1: लाइनों की तरह गूंगी चीजों को न मापें। साइक्लोमैटिक कॉम्प्लेक्सिटी और फ़ीचर काउंट्स (तरीकों की संख्या) लाइनों को अधिक अर्थ देते हैं।

— एस.एल.टी.

हां और ना। अत्यधिक संख्या में लाइनें अक्सर खराब डिजाइन का एक लक्षण है, और इस प्रकार एक लाल झंडा है कि वर्ग की संभावना को फिर से तैयार करने की आवश्यकता होती है।

— jwenting

@jwenting हाँ, यह वही है जो मुझे मिल रहा था। मैं बहुत सारी पंक्तियाँ जानता हूँ! = ज़रूरत है कि वे फिर से तैयार हो जाएँ, लेकिन लगभग सभी वर्ग जो मैं काम कर रहा हूँ, वास्तव में खराब डिज़ाइन की वजह से रिफैक्ट होने की ज़रूरत है।

— माइकल मैकगोवन

Answer 5

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

भौतिक सीमाओं के अनुसार आपके पास (स्रोत: क्लास फ़ाइल प्रारूप Java5 ) हो सकता है:

• 65,536 स्थिरांक, इंटरफेस लागू, फ़ील्ड, विधियाँ, और विशेषताएँ - प्रत्येक। नोट: इससे पहले कि आप अन्य वस्तुओं में से किसी को चलाने से पहले आप निरंतर स्थान से बाहर चला जाएगा । नोट 2: विशेषताएँ वर्ग फ़ाइल निर्माण हैं - '@ एट्रिब्यूट' मार्कर (यानी डिबग जानकारी और बाइट कोड को एक विधि के लिए अलग-अलग विशेषताओं के रूप में संग्रहीत किया जाता है) के साथ भ्रमित नहीं होना चाहिए।
• प्रत्येक विधि उत्पन्न बाइट कोड के 4GB (32 बिट्स) हो सकती है। नोट: 1.5 से पहले के जावा संस्करण में प्रत्येक विधि के लिए उत्पन्न बाइट कोड का केवल 64KB (16 बिट्स) हो सकता है।

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

Comments

एकल जिम्मेदारी के लिए +1 :) @ क्या आप अपने सॉफ़्टवेयर में इसे सख्ती से लागू करते हैं?

— आदित्य पी।

हाँ। चाल जिम्मेदारियों को इस तरह से विभाजित करना है जो समझ में आता है।

— बेरिन लोरिट्श

आह, अच्छी पुरानी 64KB सीमा। यह देखने के लिए कि आपके JSP बहुत जटिल हैं या नहीं, यह देखने के लिए अच्छा लिथुमस टेस्ट, क्योंकि वे आपके सभी स्थिर html :) के लिए बहुत सारे

— प्रिंटल

जावा 5 के रूप में, उन्होंने इसे 4GB तक बढ़ा दिया है। अब कोई चिंता नहीं।

— बेरिन लोरिट्श

Answer 6

सही उत्तर 42 है। सिर्फ मजाक करना।
दरअसल, प्रति वर्ग अधिकतम अनुशंसित लाइनें 2000 लाइनें हैं।

1999 से "जावा कोड कन्वेंशन" ने इसे इस तरह से कहा है:
2000 लाइनों से अधिक लंबी फाइलें बोझिल हैं और इसे टाला जाना चाहिए।

जावा का आविष्कार होने के बाद से सूर्य / ओरेकल कोडिंग सम्मेलनों के बाद, मैंने प्रति वर्ग लाइनों पर अंगूठे के इस नियम को उचित पाया है। आपके जावा कोड का 99% हिस्सा होना चाहिए ... और अगर यह 2000 से अधिक हो जाता है, तो बस एक TODO को यह कहते हुए शीर्ष पर रखें कि कक्षा को काम करने की आवश्यकता है।

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

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html#3043

Comments

दरअसल, उनमें से ज्यादातर @LluisMartinez

— Xtreme बाइकर

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

— निकोलस

Answer 7

साफ कोड:

कक्षाएं छोटी होनी चाहिए!

कक्षाओं का पहला नियम यह है कि उन्हें छोटा होना चाहिए। कक्षाओं का दूसरा नियम यह है कि उन्हें इससे छोटा होना चाहिए। नहीं, हम फ़ंक्शंस चैप्टर से ठीक उसी टेक्स्ट को दोहराने नहीं जा रहे हैं। लेकिन जब यह डिजाइनिंग कक्षाओं की बात आती है, तो फ़ंक्शंस के साथ, छोटा प्राथमिक नियम है। कार्यों के साथ, हमारा तात्कालिक प्रश्न हमेशा "कितना छोटा है?"

** कार्यों के साथ हमने भौतिक रेखाओं की गिनती करके आकार को मापा। कक्षाओं के साथ हम एक अलग माप का उपयोग करते हैं। हम जिम्मेदारियां गिनाते हैं। **

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

फिर:

• बस यह सुनिश्चित करें कि आपके तरीके केवल एक ही काम करते हैं।
• फिर सुनिश्चित करें कि कक्षा में बहुत अधिक जिम्मेदारियां नहीं हैं।

आप एक प्रबंधनीय आकार के एक वर्ग के साथ समाप्त हो जाएंगे।

Comments

यदि Clean Codeआपके उत्तर के शीर्ष पर रॉबर्ट सी। मार्टिन की पुस्तक है (जो यह करता है!), तो मुझे आपको कहना होगा और मेरे पास यह आम है; उस पुस्तक ने मुझे इस प्रश्न के लिए प्रेरित किया। मुझे लगता है कि यह जवाब यह सब कहता है

— SANđошӽа

Answer 8

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

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

Answer 9

एक बेहतर मीट्रिक का उपयोग करके देखें।

एक उदाहरण एबीसी मेट्रिक है । यह इस बात का एक मापक है कि कोड द्वारा कितना काम किया जा रहा है, उससे कहीं अधिक कोड है।

Answer 10

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