किस बिंदु / सीमा पर कोड फ़ाइल बहुत बड़ी है?

Question

मुझे 2-3k लाइन की बहुत सारी फाइलें मिल रही हैं, और यह वास्तव में महसूस नहीं करता है कि उन्हें इतना बड़ा होना चाहिए।

स्रोत कोड फ़ाइल को "बहुत बड़ा" कहने के लिए एक अच्छा मानदंड क्या है ?, एक स्रोत कोड फ़ाइल में अधिकतम कितनी लाइनें होनी चाहिए?

Comments

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

— gnat

कुछ संकलक स्रोत कोड आकार पर अजीब सीमाएं रखते थे: अधिकतम लाइन की लंबाई या लाइनों की अधिकतम संख्या। जब कंपाइलर शिकायत करता है, तो यह एक ऑब्जेक्टिव इंडिकेटर है जो कोड बहुत बड़ा है (या यह अपग्रेड करने का समय है)।

— मौविसील

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

— अंबोज़ बिज्जक

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

— जुह_ ३१'१

"क्या वह स्रोत कोड है?" "नहीं, यह मेकफाइल है, स्रोत कोड ट्रकों में पीछे है"।

— mckenzm

Answer 1

एक आदर्श मॉडल के रूप में, मैं निम्नलिखित मानदंडों का उपयोग करता हूं (मार्टिन बेकेट ने एक समान तर्क के साथ, यानी तार्किक संरचना के संदर्भ में सोचने के लिए और कोड की पंक्तियों के संदर्भ में नहीं):

नियम 1

फ़ाइल प्रति एक वर्ग (C ++ में: एक वर्ग -> एक शीर्ष लेख और एक कार्यान्वयन फ़ाइल)।

नियम २

सात को उन वस्तुओं की संख्या माना जाता है जो हमारे मस्तिष्क को भ्रमित किए बिना एक ही समय में निरीक्षण कर सकते हैं। 7 से ऊपर हम जो देखते हैं उसका अवलोकन रखना मुश्किल होता है। इसलिए: प्रत्येक वर्ग में 7-10 से अधिक विधियां नहीं होनी चाहिए। एक वर्ग जिसके पास 10 से अधिक विधि है वह संभवतः बहुत जटिल है और आपको इसे विभाजित करने का प्रयास करना चाहिए। बंटवारा एक बहुत प्रभावी तरीका है क्योंकि हर बार जब आप एक वर्ग को विभाजित करते हैं तो आप प्रत्येक व्यक्ति वर्ग की जटिलता को कम से कम 2 के कारक से कम करते हैं।

नियम ३

एक विधि निकाय जो एक या दो स्क्रीन में फिट नहीं होता है वह बहुत बड़ा है (मेरा मानना ​​है कि एक स्क्रीन / संपादक विंडो लगभग 50 लाइनें है)। आदर्श रूप से, आप पूरी विधि एक विंडो में देख सकते हैं। यदि यह मामला नहीं है, तो आपको केवल छिपे हुए तरीके को भूलकर, ऊपर और नीचे स्क्रॉल करने की आवश्यकता है। इसलिए, यदि आपको पूरी विधि बॉडी को पढ़ने के लिए एक से अधिक स्क्रीन को ऊपर या नीचे स्क्रॉल करना है, तो आपका तरीका संभवतः बहुत बड़ा है और आप आसानी से अवलोकन खो सकते हैं।

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

इन बहुत मोटे अनुमानों को एक साथ रखना:

• स्रोत फ़ाइल के प्रति अधिकतम एक वर्ग।
• प्रति कक्षा में अधिकतम 10 सार्वजनिक विधि।
• प्रति कक्षा में अधिकतम 10 निजी पद्धति।
• प्रति विधि अधिकतम 100 लाइनों पर।

तो एक स्रोत फ़ाइल जो 2000 से अधिक लाइनों की है शायद बहुत बड़ी है और बहुत गड़बड़ होने लगी है।

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

वैसे भी, मेरे अनुभव में एक फ़ाइल अपठनीय होने लगती है जब उपरोक्त मापदंडों में से एक का सम्मान नहीं किया जाता है (उदाहरण के लिए एक 300 लाइन विधि बॉडी जो छह स्क्रीन तक फैलती है, या कोड की 5000 लाइनों के साथ एक स्रोत फ़ाइल)।

Comments

मैं 10 से अधिक लाइनों के तरीकों के लिए भी प्रयास करूँगा ... पठनीयता / समझ के साथ मदद करता है कि विधि क्या कर रही है और जटिलता को कम करती है जो आसानी से बड़े तरीकों से हो सकती है ...

— ज़ैक मैकॉम्बर

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

— hasen

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

— जैक्सबी

@JacquesB 7 आइटम आमतौर पर असंबंधित जानकारी के 7 टुकड़ों का संकेत है। यदि आपका मस्तिष्क जानकारी को संबद्ध या समूहित कर सकता है, तो वास्तविक अर्थों में यह सूचना का 1 टुकड़ा है जिसे आप याद करने का प्रयास कर सकते हैं, तो अधिक हो सकता है (वास्तव में "वर्णमाला" एक प्रतीक है, सभी 26 अक्षर नहीं)। एक बेहतर उदाहरण एक 7 अंकों की संख्या को याद करने की कोशिश कर रहा होगा जो आपको फोन पर पेन और पेपर उपलब्ध किए बिना बताया गया था। विधियाँ स्पष्ट रूप से मनमानी संख्याएँ नहीं हैं, लेकिन यदि वे विधियाँ आपके कोडिंग के लिए प्रासंगिक हैं, तो आप 7 के बाद उम्मीद कर सकते हैं, आपको सही ढंग से याद करने से पहले इसकी तलाश करनी होगी।

— नील

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

— जैक्सबी

Answer 2

नहीं - कोड की लाइनों के संदर्भ में नहीं। चालक को तार्किक समूह होना चाहिए। उदाहरण के लिए निश्चित रूप से एक बड़ी फ़ाइल में कई कक्षाएं नहीं होनी चाहिए

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

Comments

सैकड़ों तरीकों के साथ एक वर्ग वर्ग ईर्ष्या, सामंजस्य की कमी, खराब डिजाइन, एकल जिम्मेदारी सिद्धांत का उल्लंघन, आदि का लक्षण नहीं होगा?

— ट्यूलेंस कोरडोवा

@ user1598390: आमतौर पर, लेकिन हमेशा नहीं।

— whatsisname

@ user1598390 - आम तौर पर कह सकते हैं कि gis / 3D मॉडलिंग में आपके बहुत सारे ऑपरेशन हो सकते हैं, और फिर उन्हें 2d, 3D, 4d, 3D + सिग्नल के लिए अधिभारित किया जाता है, फिर फ्लोट / डबल / पूर्णांक आदि - टेम्पलेट थोड़ी सी मदद करते हैं लेकिन प्रभावकारिता के लिए बहुत सारे ऑपरेशन अक्सर एक सुंदर वर्ग उत्तराधिकार से बेहतर होते हैं

— मार्टिन बेकेट

@ tp1 - और आप एक छोटे से फ़ॉन्ट का उपयोग करते हैं ताकि वे उतना स्थान न लें?

— मार्टिन बेकेट

@ tp1 यार, मुझे क्षमा करें, मेरा वास्तव में कोई अनादर नहीं है, लेकिन जो भी आपके साथ काम करता है, उसके लिए मुझे खेद है। यदि आपके पास 1200 कक्षाएं हैं, तो एक निर्देशिका सम्मेलन का उपयोग करें, यदि आपके पास बहुत सारी निर्देशिकाएं हैं, तो उन्हें स्वतंत्र मॉड्यूल / पुस्तकालयों में विभाजित करें।

— ड्यूकफैगमिंग

Answer 3

जब इसमें कोड अप्राप्य हो जाता है। अर्थात: यदि आप जिस विधि / वर्ग / कार्य को देख रहे हैं (और संपादित / डीबग करना है) कोड को देखकर आप यह नहीं बता सकते हैं कि क्या है, और यदि ऐसा है, तो यह कहाँ है।

आपकी आईडीई / संपादक की पसंद और विशेषताएं इस ऊपरी सीमा की वास्तविक मात्रा को प्रभावित करेंगी, हालांकि। कोड फोल्डिंग , फंक्शन / मेथड लिस्टिंग, और लुकअप इस विकास परिदृश्य को प्रस्तुत करने वाले क्षण को स्थगित कर देगा ।

लेकिन जब यह होता है, तो इसे विभाजित करने का समय आ गया है।

Answer 4

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

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

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

इसलिए, जब तक बग फिक्स अनुपात (सभी कमिट के लिए बग फिक्स का अनुपात) बड़ी फ़ाइलों के लिए कम है, स्थिति सहनीय है। कृपया git logइसके लिए प्रयास करें और त्रुटियों के संबंध में कितने कमिट हैं। या एक उपकरण का उपयोग करें जो स्वचालित रूप से विश्लेषण और कल्पना कर सकता है, जैसे सॉफ्टग्राम ।

Answer 5

इस पर विचार करें Metaphor। जब कोड लंबाई की बात आती है, तो मुझे लगता है कि हमें निम्नलिखित पर विचार करना चाहिए:

The Cat in The Hat (50 pp.)

तथा

Lord of The Rings (1,178 pp.)

कुछ भी गड़बड़ नहीं है Lord of the Rings। यह एक शानदार किताब है। The Cat in the Hatएक बेहतरीन किताब भी है। दोनों को 5 साल के बच्चों द्वारा समझा जा सकता है, लेकिन केवल एक सामग्री के कारण बेहतर अनुकूल है।

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

हम में से अधिकांश विधानसभा कोड नहीं लिख रहे हैं । लेकिन हमारे कोड की जड़ विधानसभा है। 10000 लाइनों की असेंबली के माध्यम से खोज करना अजगर की 10000 लाइनों की तुलना में कठिन है, अगर यह सही तरीके से किया जाता है।

लेकिन कुछ काम के लिए 500 से 1000 लाइन लिखने की आवश्यकता होती है। कोड के साथ हमारा लक्ष्य स्वच्छ कोड की 300 लाइनों को लिखना होना चाहिए।

डेवलपर्स के रूप में, हम "लॉर्ड ऑफ द रिंग्स" लिखना चाहते हैं। जब तक हमें एक बग नहीं मिलता है और हम चाहते हैं कि हम "कैट इन द हैट" लिख रहे हैं। अहंकार की माप कोडिंग मत करो। बस चीजों को साधारण तरीके से काम करें।

डेवलपर्स दस्तावेज़ कोड नहीं करना चाहते हैं, (मुझे व्यक्तिगत रूप से दस्तावेज़ कोड पसंद है, मैं वह स्वार्थी नहीं हूं)। इसलिए ऐसा कोड न लिखें, जिसे केवल आप समझ सकें / पढ़ सकें। Cat in the Hatकोड लिखें ।

हम सभी जानते हैं कि आप जेआरआर टोलकेन (आपके सिर में) हैं। याद रखें कि आपके पास बग फ्री कोड साबित करने के लिए कुछ नहीं होगा।

रूपक का एक और कारण।

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

हर किसी को रिबासिंग पसंद होती है।

-> किसी ने कभी नहीं कहा!

टीएल; डीआर पठनीयता पर ध्यान केंद्रित। अपने कोड और सहायक को कई लाइनों और फाइलों पर फैलाएं जितना आप कर सकते हैं। एक ही फाइल में 8 या 9 कक्षाएं न फेंके, यह कोड को पढ़ने के लिए कठिन और बनाए रखने के लिए कठिन बनाता है। यदि आपके पास एक बड़ी शर्त कोड या लूप है, तो भाषा को समर्थन देने पर उन्हें लैम्ब्डा में बदलने पर विचार करें। यूटिलिटी फ़ंक्शंस को कोड पठनीयता बढ़ाने के लिए एक महान एवेन्यू माना जाना चाहिए। भारी घोंसले से बचें।

Comments

एक नीच नहीं, लेकिन आपकी सादृश्य मुझ पर एक सा है। क्या आप कह रहे हैं कि अपने कोड को कई लाइनों में फैलाना बेहतर है, और प्रत्येक पंक्ति में कम शब्द हैं?

— चारा

कई लाइनों और फाइलों पर कोड और हेल्पर फैलाएं जितना आप कर सकते हैं। पठनीयता पर ध्यान दें। एक फ़ाइल में 8 या 9 कक्षाएं न फेंकें। यह कोड को पढ़ने के लिए कठिन और बनाए रखने के लिए कठिन बनाता है। यदि आपके पास एक बड़ी शर्त कोड या लूप है। उन्हें उपयोगिताओं में बदल दें। भारी घोंसले से बचें। कृपया मुझे बताएं कि क्या यह इसे समझाने में मदद करता है।

— GetBackerZ

शायद आपको इसे अपने उत्तर में संपादित करना चाहिए, क्योंकि इससे आपका मतलब स्पष्ट हो जाएगा।

— चारा

मैंने जैकी ब्राउन के लिए स्क्रिप्ट का उपयोग मॉड्यूलर z / OS COBOL कार्यक्रमों के लिए एक यार्डस्टिक के रूप में किया था। आप जानते हैं, कॉकटेल पार्टी के लिए दावत ...

— mckenzm

"जब भी हम कर सकते हैं एक 5 साल की उम्र के लिए समझ में आता है।" - वास्तविक दुनिया की समस्याओं के लिए जो बिलों का भुगतान करते हैं, यह शायद ही कभी संभव है, और गलत काम के लिए लक्ष्य कर रहा है

— whatsisname