कोडिंग गाइड: आप अपनी बड़ी स्रोत फ़ाइलों को कैसे विभाजित करते हैं?

Question

जिस परियोजना पर मैं काम कर रहा हूं, वह मुख्य सी # फ़ाइल में 4200 लाइनों को हिट कर चुका है, जो इंटेलिसेन्स को कुछ सेकंड (कभी-कभी 6 या उससे अधिक) लेने का कारण बनता है, जिसके दौरान विजुअल स्टूडियो लॉक हो जाता है। मैं सोच रहा हूं कि कैसे हर कोई अपनी फाइलों को विभाजित करता है और क्या सर्वसम्मति है।

मैंने कुछ गाइड देखने की कोशिश की और Google's C++ guide पाया, लेकिन मैं फ़ंक्शन आकार और फ़ाइल आकार जैसे अर्थशास्त्र के बारे में कुछ भी नहीं देख सका; शायद यह वहां है - मैंने इसे थोड़ी देर तक नहीं देखा है।

तो आप अपनी फाइलों को कैसे विभाजित करते हैं? क्या आप अपने कार्यों को उनके द्वारा किए गए कार्यों से समूहित करते हैं? प्रकार (घटना हैंडलर, निजी/सार्वजनिक) द्वारा? और आप किस आकार सीमा पर कार्यों को विभाजित करते हैं?

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

Answer 1

मुझे लगता है कि आपकी समस्या का उपयोग आपके द्वारा उपयोग किए जाने वाले शब्द के साथ किया गया है: "मुख्य सी # फ़ाइल"।

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

यदि आपके पास पकड़-सभी उपयोगिता वर्ग या अन्य सामान्य विधियां हैं तो आपको उन्हें समान कार्यात्मक भागों में तोड़ना चाहिए।

आम तौर पर मेरी फाइलें कक्षाओं में से एक-एक मैपिंग हैं।

कभी-कभी कक्षाएं बहुत संबंधित हैं, एक ही फ़ाइल में हैं।

यदि आपकी फ़ाइल बहुत बड़ी है तो यह संकेत है कि आपकी कक्षा बहुत बड़ी और बहुत सामान्य है।

मैं अपनी विधियों को आधा स्क्रीन या उससे कम रखने की कोशिश करता हूं। (जब यह कोड होता है तो मैं स्क्रैच से लिखता हूं, यह आम तौर पर 12 लाइन या उससे कम होता है, लेकिन हाल ही में मैं अन्य डेवलपर्स से मौजूदा कोड में काम कर रहा हूं और 100 लाइन फ़ंक्शंस को दोबारा कर रहा हूं ...)

कभी-कभी यह एक स्क्रीन है, लेकिन यह बहुत बड़ा हो रहा है।

संपादित करें:

कार्यों के बारे में अपने आकार सीमा प्रश्न के समाधान के लिए - और मेरे लिए यह आकार के बारे में कम है (हालांकि यह है कि एक समस्या का एक अच्छा संकेत है) केवल एक ही बात कर रहे हैं और प्रत्येक को सरल रखने के बारे में अधिक।

Answer 2

आंशिक कक्षाओं का उपयोग करें। आप मूल रूप से एक ही कक्षा को कई फाइलों में तोड़ सकते हैं।

Answer 3

अपने प्रकारों को विभाजित करें जहां उन्हें विभाजित करना स्वाभाविक है - लेकिन उन प्रकारों के लिए देखें जो बहुत अधिक कर रहे हैं। लगभग 500 लाइनों (जावा या सी #) पर मुझे चिंतित है। लगभग 1000 लाइनों पर मैं इस बात पर कड़ी मेहनत कर रहा हूं कि इस प्रकार को विभाजित किया जाना चाहिए ... लेकिन कभी-कभी यह सिर्फ नहीं होना चाहिए/नहीं होना चाहिए।

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

कभी कभी यह एक ही प्रकार के लिए समझ में आता है एक बहुत तरीकों में से के लिए - जैसे System.Linq.Enumerable रूप में, लेकिन आंशिक वर्गों, ऐसे मामलों में मदद कर सकते हैं (तार्किक समूहों में प्रकार को तोड़ सकता है अगर Enumerable के मामले में, एकत्रीकरण/सेट ऑपरेशंस/फ़िल्टरिंग आदि द्वारा समूहीकरण प्राकृतिक प्रतीत होता है)। यद्यपि मेरे अनुभव में ऐसे मामले दुर्लभ हैं।

Answer 4

प्रक्रियात्मक रूप से कोड न करें, और आप एक फ़ाइल में 4,200 लाइनों के साथ समाप्त नहीं होंगे।

सी # में कुछ SOLID ऑब्जेक्ट उन्मुख डिजाइन सिद्धांतों का पालन करना एक अच्छा विचार है। प्रत्येक वर्ग में बदलने के लिए एक और एकमात्र कारण होना चाहिए। मुख्य विधि को एप्लिकेशन के लिए शुरुआती बिंदु लॉन्च करना चाहिए (और यदि आप स्ट्रक्चर मैप की तरह कुछ उपयोग कर रहे हैं तो अपने निर्भरता इंजेक्शन कंटेनर को कॉन्फ़िगर करें)।

मैं आम तौर पर कोड के 200 से अधिक लाइनों के साथ फ़ाइलों की जरूरत नहीं है, और मैं उन्हें पसंद करते हैं अगर वे के तहत 100

Answer 5

खैर कर रहे हैं, मैं कहना है कि आप में एक बड़ा मुद्दा हो सकता है डर लग रहा है एक धीमी लोड समय से हाथ। आप कसकर युग्मित कोड और रखरखाव/पठनीयता समस्याओं के मुद्दों को मारने जा रहे हैं।

कक्षा फ़ाइलों को छोटी फ़ाइलों में विभाजित करने के बहुत अच्छे कारण हैं (और विभिन्न परियोजनाओं/असेंबली में फ़ाइलों को स्थानांतरित करने के समान अच्छे कारण)।

इस बारे में सोचें कि आपके वर्ग को क्या उद्देश्य प्राप्त करना है। प्रत्येक फ़ाइल में वास्तव में केवल एक ही उद्देश्य होना चाहिए। यदि यह अपने लक्ष्य में बहुत सामान्यीकृत है, उदाहरण के लिए, "शॉपिंग बास्केट लॉजिक युक्त" है, तो आप गलत पथ का नेतृत्व कर रहे हैं।

जैसा कि बताया गया है, "मुख्य सी # फ़ाइल" सिर्फ यह मानता है कि आपके पास बहुत ही प्रक्रियात्मक मानसिकता है।

• जनरल OOP सिद्धांतों
• डोमेन संचालित डिजाइन
• इकाई परीक्षण
• IoC कंटेनरों
: मेरी सलाह, रोक पीछे हटना, और राशि के लिए एक त्वरित निम्न विषयों में से कुछ पर पढ़ा होगा

अपनी खोजों के साथ शुभकामनाएं।

Answer 6

मार्टिन फाउलर की पुस्तक Refactoring मुझे लगता है कि आपको इसके लिए एक अच्छा प्रारंभिक बिंदु देता है। यह "कोड गंध" की पहचान करने और इन "गंध" को ठीक करने के लिए अपने कोड को दोबारा कैसे सुधारने के बारे में निर्देश देता है। प्राकृतिक परिणाम (हालांकि यह प्राथमिक लक्ष्य नहीं है) यह है कि आप छोटे और अधिक रखरखाव योग्य वर्गों के साथ समाप्त होते हैं।

संपादित

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

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

Answer 7

कोई कठोर और तेज़ नियम नहीं हैं, लेकिन एक सामान्य समझौता है कि अधिक, छोटे कार्य एक बड़े कार्य से बेहतर होते हैं, और अधिक छोटी कक्षाएं 1 बड़ी कक्षा से बेहतर होती हैं।

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

जब मैं महसूस करता हूं कि वे 1 से अधिक चीजें करते हैं, जैसे मिश्रित प्रस्तुति और तर्क। एक बड़ी कक्षा एक बड़ी विधि की तुलना में एक समस्या से कम है, जब तक कक्षा 1 चीज करता है।

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

आपको सी # शैली पर पढ़ना चाहिए और वास्तव में उन मुद्दों को समझने के लिए रीफैक्टरिंग करना चाहिए जिन्हें आप संबोधित कर रहे हैं।

Refactoring एक उत्कृष्ट पुस्तक है जिसमें कोड लिखने के लिए युक्तियां हैं ताकि व्यवहार संरक्षित हो लेकिन कोड काम करने के लिए और अधिक स्पष्ट और आसान हो।

Elements of C# Style एक अच्छा मृत पेड़ सी # शैली मार्गदर्शिका है, और यह blog post में अच्छी ऑनलाइन शैली मार्गदर्शिकाओं के कई लिंक हैं।

अंत में, FxCop और StyleCop का उपयोग करने पर विचार करें। ये आपके द्वारा पूछे गए प्रश्नों में मदद नहीं करेंगे, लेकिन आपके कोड के साथ अन्य स्टाइलिस्ट मुद्दों का पता लगा सकते हैं। चूंकि आपने पानी में अपने पैर की अंगुली को डुबो दिया है, इसलिए आप भी कूद सकते हैं।

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

Answer 8

यदि आपके पास कक्षा के भीतर कोड के क्षेत्र हैं, तो partial कीवर्ड और उस फ़ाइल में कक्षा की परिभाषा को तोड़ने का एक आसान तरीका है। मैं आमतौर पर बड़े वर्गों के लिए ऐसा करता हूं।

मैं जिस सम्मेलन का उपयोग करता हूं वह है ClassName_RegionName.cs। उदाहरण के लिए, यदि मैं एक क्लास को तोड़ना चाहता हूं जो डेटाबेस कनेक्शन के लिए स्कीमा का प्रबंधन करता है, और मैंने क्लास डेटाबेस कनेक्शन कहा है, तो मैं स्कीमा कार्यक्षमता के लिए मुख्य वर्ग के लिए डेटाबेसConnection.cs नामक एक फ़ाइल और फिर डेटाबेसकोनक्शन_Schema.cs बनाउंगा।

कुछ वर्गों को बस बड़ा होना है। यह बुरा डिजाइन नहीं है; वे सिर्फ कार्यान्वयन-भारी हैं।

Answer 9

प्रत्येक वर्ग को एक छोटी सी चीज करना चाहिए और इसे अच्छी तरह से करना चाहिए। क्या आपकी कक्षा एक फॉर्म है? तब इसमें इसमें कोई व्यावसायिक तर्क नहीं होना चाहिए।

क्या यह उपयोगकर्ता या राज्य की तरह एक अवधारणा का प्रतिनिधित्व करता है? उसके बाद इसमें कोई ड्राइंग, लोड/सेव, आदि नहीं होना चाहिए ...

प्रत्येक प्रोग्रामर चरणों और स्तरों के माध्यम से जाता है। आप अपने वर्तमान स्तर के साथ एक समस्या को पहचान रहे हैं और आप अगले दृष्टिकोण तक पहुंचने के लिए तैयार हैं।

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

मैं सलाह देता हूं कि वास्तव में ओओ डिज़ाइन कैसे करें। ऐसे कई सिद्धांत हैं जिन्हें आपने शायद सुना है कि समझ में नहीं आता है। कारण यह नहीं है कि वे वर्तमान में प्रोग्रामिंग के तरीके पर लागू नहीं होते हैं।

Lemme एक अच्छा पोस्ट मिलती है ... इन के माध्यम से देखो शुरू करने के लिए:

how-do-i-break-my-procedural-coding-habits

are-there-any-rules-for-oop

object-oriented-best-practices-inheritance-v-composition-v-interfaces

वहाँ भी पदों है कि आप अच्छा OO डिजाइन पुस्तकों के पास भेजेगा । एक "रिफैक्टरिंग" पुस्तक शायद सबसे अच्छी जगहों में से एक है जिसे आप शुरू कर सकते हैं।

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

शुभकामनाएं।

Answer 10

आप छोटे से चीजों को बदलने और समय के साथ धीरे-धीरे बदलने के लिए देख सकते हैं।

• क्या केवल उस कक्षा में उपयोग की जाने वाली सभी विधियां हैं? समर्थन विधियों की तलाश करें, जैसे सत्यापन, स्ट्रिंग मैनिपुलेशन, जिसे सहायक/उपयोग कक्षाओं में स्थानांतरित किया जा सकता है।

• क्या आप किसी भी #region अनुभाग का उपयोग कर रहे हैं? #region में संबंधित विधियों के तार्किक समूह अक्सर अलग-अलग वर्गों में विभाजित होने के लिए खुद को उधार देते हैं।

• क्या कक्षा एक फॉर्म है? फॉर्म नियंत्रण या फॉर्म नियंत्रण के समूहों के लिए उपयोगकर्ता नियंत्रण का उपयोग करने पर विचार करें।

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

Answer 11

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

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

Answer 12

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

Answer 13

क्लासिक पुस्तक "Structured Programming" में डिजस्ट्रा ने एक बार एक खंड लिखा था: "बहुत कुछ करने में हमारी अक्षमता पर।" उनका मुद्दा सरल था। मनुष्य बहुत स्मार्ट नहीं हैं। हम एक समय में अपने दिमाग में कुछ अवधारणाओं को अधिक नहीं जोड़ सकते हैं।

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

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

• Clean Code
• SOLID
• Agile Principles, Patterns, and Pratices in C#

Answer 14

स्प्लिट कोड ताकि प्रत्येक वर्ग/फ़ाइल/समारोह/आदि। केवल एक चीज ™ करता है। The Single Responsibility Principle कक्षाओं में कार्यक्षमता विभाजन के लिए एक अच्छा दिशानिर्देश है।

आजकल, मेरे द्वारा लिखे जाने वाले सबसे बड़े वर्ग लगभग 200 लाइन लंबी हैं, और विधियां अधिकतर 1-10 लाइन लंबी हैं।