एक युवा डेल्फी डेवलपर की आज्ञा

एक समय, मुझे युवा डेवलपर्स की देखरेख करने का काम सौंपा गया था। यह एक संक्षिप्त सिफारिश के साथ शुरू करने का निर्णय लिया गया था। नतीजा आपके सामने है।

1 छोटा और स्पष्ट नहीं

1. कोड पढ़ें!
   
2. एक ऐसा कोड लिखें जो अन्य सभी के लिए पढ़ना आसान हो
   
3. टिप्पणी में लिखें कोड क्या नहीं है, लेकिन क्यों
   
4. चेतावनी और संकेत संकलन त्रुटियों की तुलना में अधिक खतरनाक हैं - परियोजना को समाप्त किए बिना बनाया गया है
   

2 विकास चक्र

1. नेता द्वारा टास्क सेटिंग
   
2. निर्णय लेना
   
3. समाधान की समीक्षा करें
   
4. समाधान कार्यान्वयन
   
5. कोड समीक्षा
   
6. संस्करण नियंत्रण प्रणाली में प्लेसमेंट
   

3 स्रोत कोड डिजाइन

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

4 टिप्पणियाँ

• प्रक्रियाओं, वर्गों, आदि की घोषणा से पहले टिप्पणी की पहली पंक्ति। उनका उद्देश्य स्पष्ट करना चाहिए। निम्नलिखित पंक्तियाँ कार्यान्वयन की कुछ विशेषताओं का वर्णन करती हैं।
  
• आभासी तरीकों पर टिप्पणियों को कॉल की परिस्थितियों का वर्णन करना चाहिए, न कि कार्यान्वयन - इसे वारिसों में ओवरलैप किया जा सकता है।
  
• प्रक्रियाओं और विधियों के शरीर में टिप्पणियों का वर्णन नहीं किया जाना चाहिए कि ऑपरेटर क्या कर रहा है या ब्लॉक कर रहा है, लेकिन इसके लिए GOAL को इंगित करना चाहिए जिसके लिए यह (ऑपरेटर) उपयोग किया जाता है।
  
  1. इसके कार्यान्वयन के साधनों की तुलना में लक्ष्य बहुत कम बदलते हैं
     
  2. आप समझ सकते हैं कि इससे क्या कोड बनता है, यह समझें कि WHY कोड अवास्तविक है।
     

5 नाम चयन

• कक्षाएं - एक कंपनी नाम (एसएमएस) के रूप में अनिवार्य उपसर्ग टी और वैकल्पिक के साथ एक एकल संज्ञा, यदि समान नाम और एक परियोजना (ZVK, योजना) के साथ एक पुस्तकालय वर्ग है, अगर वर्ग हमारी कई परियोजनाओं में शामिल नहीं हो सकता है।
  
• इंटरफेस - उपसर्ग I के साथ संज्ञा
  
• प्रक्रियाएं - क्रिया।
  
• कार्य - मूल्य और बहुवचन - संग्रह लौटाते समय एकवचन संज्ञा। गेट उपसर्ग का उपयोग बाहरी डेटा प्राप्त करने के लिए संपत्तियों और कार्यों के तरीकों को पढ़ने के लिए किया जाता है, तार्किक कार्यों के लिए उपसर्ग है, फ़ंक्शन बनाने के लिए उपसर्ग बनाएँ। क्रियाओं को क्रिया करने के लिए कहा जाता है (और केवल परिणाम प्राप्त करने के लिए नहीं) को प्रक्रिया कहा जाता है, क्योंकि वे वास्तविक हैं।
  
• गुण एक विलक्षण संज्ञा है, जो सरणी गुणों के अपवाद के साथ है। पूर्णांक सूचकांक के साथ सरणी गुणों के लिए, प्रत्यय गणना के साथ एक उपग्रह संपत्ति को परिभाषित किया गया है। ईवेंट प्रॉपर्टी को पहले, पहले या बाद के साथ प्रीफ़िक्स किया जाना चाहिए। पढ़ने और लिखने के गुणों के लिए तरीके अनिवार्य हैं और उपसर्ग सेट करें।
  
• आभासी विधियाँ - सार्वजनिक विधियों के लिए उपसर्ग संरक्षित और बिना उपसर्ग के साथ एक क्रिया।
  
• वर्चुअल विधि का नाम इसके कॉल के उद्देश्य को दर्शाता है, न कि कार्यान्वयन के लिए।
  

6 संचालक

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

7 एनकैप्सुलेशन

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

8 त्रुटि से निपटने

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

डेल्फी में त्रुटि से निपटने के लिए व्यापक स्रोत

9 डिबगिंग

• आपको संकलक के सभी चेतावनियों और संकेतों से पूरी तरह से छुटकारा पाना चाहिए, ज़ाहिर है, उन्हें बंद करके नहीं।
  

समस्या निवारण के संदर्भ में डेल्फी परियोजना सेटिंग्स
लॉग फाइल कैसे पढ़ें
विस्तार से पहुंच का उल्लंघन
आपको हमेशा Free के बजाय FreeAndNil का उपयोग क्यों करना चाहिए

10 संसाधन लीक

• सबरूटीन के भीतर उपयोग किए गए किसी भी संसाधन के रिसाव की संभावना को प्रयास के साथ समाप्त कर दिया जाता है..बिना, जबकि संसाधन को कोशिश करने से तुरंत पहले पकड़ लिया जाता है, और अंत में रिलीज किया जाता है।
  
• बनाने (कैप्चर करने) फ़ंक्शन में संसाधन रिसाव की संभावना को try..except की मदद से समाप्त किया जाता है, जबकि संसाधन पर कब्जा कोशिश से पहले किया जाता है, और रिलीज को बढ़ाने के अलावा जारी किया जाता है।
  
• कंस्ट्रक्टर में रिसोर्स लीक होने की संभावना ऑब्जेक्ट के क्षेत्रों में कैप्चर किए गए रिसोर्स को रेफरेंस को ध्यान में रखकर खत्म की जाती है और एक डिस्ट्रक्टर लिखकर जो आंशिक रूप से इनिशियलाइज्ड ऑब्जेक्ट को सही तरीके से डिलीट करता है। यह उस ऑर्डर के कारण है जिसमें ऑब्जेक्ट डेल्फी में बनाया गया था।
  

1. मेमोरी ऑब्जेक्ट के लिए आवंटित की जाती है और शून्य से भर जाती है
   
2. कंस्ट्रक्टर प्रगति पर है
   
3. यदि एक अपवाद को पिछले चरण पर फेंक दिया जाता है, तो विध्वंसक को कहा जाता है, कब्जा की गई मेमोरी को मुक्त कर दिया जाता है, और अपवाद अतिरेक है।
   

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

संसाधन लीक के लिए खोजें
लीक की तलाश जारी है

11 विरासत, रचना, कार्यान्वयन, विस्तार

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

12 इंटरफेस

• इंटरफेस का उपयोग करते समय लीक के बारे में कोई चिंता नहीं है।
  
• इंटरफ़ेस को लागू करने वाले तरीके गैर-आभासी होने चाहिए और सार्वजनिक नहीं, आमतौर पर संरक्षित होते हैं।
  
• किसी भी इंटरफ़ेस में कम से कम तीन विधियाँ शामिल हैं - QueryInterface, AddRef और Release।
  
• इन विधियों को अंतर्निहित रूप से लागू किया जाता है: इंटरफ़ेस के लिंक को कास्टिंग के रूप में पहला ऑपरेशन के साथ, दूसरा और तीसरा इंटरफ़ेस के लिए एक नया लिंक बनाकर और हटा (या दृश्यता क्षेत्र को छोड़कर)।
  
• टोब्जेक्ट के वंशजों के साथ इंटरफेस लागू करते समय, आपको उपरोक्त तीनों विधियों को लागू करना होगा।
  
• निम्नलिखित वर्गों के वंशजों में QueryInterface, AddRef, और Release के डिफ़ॉल्ट कार्यान्वयन हैं:
  
  • TInterfacedObject क्लास इंटरफेस के लिए कोई लिंक नहीं होने पर स्वचालित विलोपन को लागू करता है, इसलिए इसके वंशजों को निर्माण के तुरंत बाद इंटरफ़ेस लिंक पर डाल दिया जाना चाहिए।
    
  • TComponent लागू इंटरफेस के लिंक को अनदेखा करता है और केवल मैन्युअल रूप से हटा दिया जाता है, इसलिए आपको यह सुनिश्चित करने की आवश्यकता है कि इसके वंश को हटाने के बाद इंटरफेस के लिए कोई झूलने वाले लिंक नहीं हैं।
    
  
  

13 दृश्य घटक

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

14 मॉड्यूल

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

15 अनावश्यक निर्भरता को दूर करना

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