अच्छी प्रोग्रामिंग के लिए चेकलिस्ट

इस चेकलिस्ट को उच्च-गुणवत्ता के प्रोग्राम को लिखने में आपकी मदद करनी चाहिए।

राफेल फिंकेल, ८/१७/२००५

  • पहचानकर्ता: सुनिश्चित करें कि आपके सभी पहचानकर्ता अर्थपूर्ण हैं।
  1. एक-अक्षर पहचानकर्ता लगभग सार्थक नहीं हैं
  2. फ्लैग और टेम्प जैसे नाम शायद ही कभी सार्थक होते हैं फ्लैग के बजाय, बूलियन स्थिति को नामकरण करने पर विचार करें, जैसे कि वलुएफाउंड।
  3. मल्टी-वर्ड पहचानकर्ता पर विचार करें, जैसे नामेंडेक्स लंबी पहचानकर्ता (कारण के कारण) बहुत पठनीय होते हैं।
  • बियर लीटरल: 0 और 1 के अलावा अन्य नंबरों से बचें और अपने कार्यक्रम में “” स्ट्रिंग्स को छोड़कर, जब आप स्थिरांक को परिभाषित करते हैं।
  1. सरणी के रूप में एक शाब्दिक पूर्णांक का उपयोग न करें।
  2. एक शाब्दिक पूर्णांक को एक रन पैरामीटर के रूप में उपयोग न करें, जैसे टाइमआउट या पोर्ट नंबर।
  3. मेनू प्रविष्टियों का चयन करने के लिए वास्तविक पूर्णांक का उपयोग न करें।
  4. स्ट्रिंग या कुछ डेटा के आकार को मापने के लिए एक शाब्दिक पूर्णांक का उपयोग न करें; sizeof()और strlen () का उपयोग C और C++ और .length और .size जावा में।
  5. फ़ाइल नाम के लिए एक शाब्दिक स्ट्रिंग का उपयोग न करें। आप वाकई स्ट्रिंग्स को आउटपुट कर सकते हैं, यद्यपि।
  6. विषम डेटा युक्त एक सरणी में सूचक को एक शाब्दिक पूर्णांक का उपयोग न करें।
  7. एक पहचानकर्ता को एक शब्द के रूप में घोषित नहीं करें, जैसे “थर्टी”।
  • मॉड्यूलर: एक प्रोग्राम इंटरैक्टिंग घटकों के बाहर बनाया गया है।
  1. अपने पूरे कोड को main() रूटीन में न डालें।
  2. वास्तव में, कोई भी दिनचर्या नहीं करते हैं बहुत ज्यादा काम करते हैं। यदि यह 50 लाइनों से अधिक लंबा है, तो शायद यह बहुत लंबा है।
  3. यदि आप कई बार कोड डुप्लिकेट करते हैं, तो विचार करें कि क्या कोई लूप बेहतर काम करता है या शायद एक सब-रूटिन।
  4. यदि आप पाते हैं कि आप बहुत गहराई से इंडेंट कर रहे हैं, तो संभवतया जब आप चाहिए तब उप-रूटिन का उपयोग नहीं कर रहे हैं।
  5. लाइब्रेरी रूटिन को फिर से न बदलें (जब तक कि आपकी असाइनमेंट की आवश्यकता न हो)। उदाहरण के लिए, sprintf () और atoi() के बारे में जानने के लिए मैनुअल में देखें।
  6. C और C++ में हैडर फाइलों का उपयोग करें (हैडर फाइल में नाम समाप्त होने वाला नाम है .h) जो सभी फाइलों के बीच निर्यात किए गए सभी उप-रूटिनों की आवश्यकता के अनुसार सभी स्थिरांक को परिभाषित करता है। लेकिन हेडर फाइलों में उप-रूटिनों का शरीर न डालें (इनलाइन उप-रूट के दुर्लभ अपवाद के साथ)
  • प्रारूपण: आपका प्रोग्राम पढ़ने में आसान होना चाहिए।
  1. स्वरूपण और अन्य प्रस्तुति समस्याओं पर स्पष्ट सुझाव के लिए http://geosoft.no/development/javastyle.html पर गौर करें। यह संदर्भ विशेष रूप से जावा पर निर्देशित है, लेकिन इसकी अन्य भाषाओं के मूल्य भी हैं
  2. अपनी सभी पंक्तियों को 80 वर्णों तक सीमित करने का प्रयास करें; कई लोगों को ऐतिहासिक कारणों के लिए 80-कॉलम विंडो में कोड दिखाई देता है।
  3. इंडेंटेशन के लिए दोनों टैब और रिक्त स्थान का उपयोग न करें, क्योंकि सभी पाठ संपादक टैब को बिल्कुल 8 स्थानों के रूप में नहीं मानते हैं।
  4. एक सुसंगत इंडेंटेशन पैटर्न का पालन करें जो प्रोग्राम के नियंत्रण संरचना को दर्शाता है।
  5. अपने प्रोग्राम में बहुत सी रिक्त पंक्तियां मत डालें सबरुलाइन के बीच एक रिक्त पंक्ति पर्याप्त है
  6. विभिन्न ऑपरेटिंग सिस्टम लाइनों को अलग तरीके से समाप्त कर देते हैं यदि आप Win32 (जो \ r \ n का उपयोग करता है), यूनिक्स (जो उपयोग करता है \ n), और मैकोड (जो \ r का उपयोग करता है) के बीच चलते हैं, तो निरंतर समाप्ति विधि का उपयोग करने के लिए अपनी फ़ाइल को पुन: स्वरूपित करें।
  7. अपने स्रोत फ़ाइलों पर निष्पादन योग्य बिट (यूनिक्स) सेट न करें
  • कोडिंग: आप चाहते हैं कि आपके कोडिंग को स्पष्ट, रख-रखाव और कुशल हो, उस क्रम में। यहां कुछ नियम बहुत विशिष्ट हैं; दूसरों को अधिक सामान्य हैं
  1. if वक्तव्य के अनुक्रम का उपयोग न करें जो कि कोई else if नहीं है, केवल एक मैच कर सकता है; else if का उपयोग करें
  2. जब आप पाठ इनपुट को वर्गीकृत करना चाहते हैं, तो संभावित प्रथम वर्णों की गणना न करें।
  3. बिट पैटर्न के निर्माण के लिए गुणा के बजाय शिफ्ट ऑपरेटर्स का उपयोग करें।
  4. स्विच स्टेटमेंट में, हमेशा डिफ़ॉल्ट केस की जांच करें। इसी तरह, यदि-तब-और बयानों के अनुक्रम में, एक अंतिम और अंतिम उपयोग करें।
  5. सभी सिस्टम कॉल विफल हो सकते हैं। हमेशा वापसी कोड की जांच करें, और विफलता की रिपोर्ट करने के लिए perror() का उपयोग करें।
  6. बूलियनों को हमेशा जावा में बुलियन प्रकार, सी ++ में bool, और सी में 0/1 पूर्णांक का उपयोग करना चाहिए। अक्षर टी और एफ का उपयोग न करें, और -1 और 1 का उपयोग न करें।
  7. यदि संभव हो तो डेटा संरचनाओं को इनिशियलाइज़ करने के लिए लूप्स का उपयोग करें।
  8. प्रत्येक वैरिएबल और एक उद्देश्य के लिए एक संरचना के प्रत्येक क्षेत्र का उपयोग करें। उन्हें अधिभार न करें, जब तक ऐसा करने का एक उत्कृष्ट कारण नहीं है।
  9. किसी प्रकार, एक चर, और एक फ़ाइल नाम दोनों के लिए एक ही पहचानकर्ता का उपयोग न करें, भले ही आप कैपिटल अक्षरों को बदलते हैं। यह बहुत भ्रामक है
  10. यदि आप नेटवर्क ट्रांसमिशन से पहले हंटल () या समान रूटीन के साथ डेटा संशोधित कर रहे हैं, तो डेटा को जगह में संशोधित न करें। दूसरा डेटा संरचना बनाएं
  11. ग्लोबल या नॉन-लॉकल वैरिएबल का उपयोग न करें। आप कर सकते हैं सबसे छोटे दायरे में प्रत्येक चर को घोषित करें। वहां नॉन-लॉकल वैरिएबल के वैध उपयोग हैं, लेकिन सुनिश्चित करें कि आपको वास्तव में उनकी आवश्यकता है।
  12. शेल, पर्ल, और पायथन प्रोग्राम में उनके #! होनी चाहिए! फ़ाइल की पहली पंक्ति के रूप में रेखा; अन्यथा, रेखा सिर्फ एक टिप्पणी है
  13. विशेष मामलों को कोडिंग से बचने का प्रयास करें आप अक्सर छद्म डेटा या अन्य डेटा-स्ट्रक्चर विधियों का उपयोग कर सकते हैं जो आपको नियमित मामलों में विशेष मामलों को गुना करने की अनुमति देते हैं।
  • कम्पाइलर: उन्हें गलतियों को खोजने में मदद करें
  1. हमेशा सक्षम सभी चेतावनियों के साथ कम्पाइलर लागू करें। C और C++ के लिए, -वॉल फ़्लैग का उपयोग करें। Java के लिए, उपयोग करें- Xlint: सभी-पुनरावृत्ति, और बेहतर शैली के लिए सुझाव प्राप्त करने के लिए pmd प्रोग्राम का उपयोग करें। पायथन के लिए, -t-W सभी का उपयोग करें।
  2. सभी पर्ल प्रोग्राम को -w फ्लैग के साथ चलना चाहिए और सख्त उपयोग करना चाहिए। सभी पर्ल सीजीआई-बिन स्क्रिप्ट में -T फ्लैग भी होना चाहिए।
  • मेक उपयोगिता: इसका उपयोग करें, और इसे अच्छी तरह से उपयोग करें।
  1. एक मेकफ़ाइल में हमेशा एक “साफ” नुस्खा होना चाहिए, जिसमें सभी फाइलें निकाली जाएं, जिन्हें ऑब्जेक्ट और निष्पादन योग्य फ़ाइलों सहित मेकफ़ाइल में अन्य व्यंजनों के द्वारा पुनर्निर्माण किया जा सके।
  2. यदि आपकी प्रोजेक्ट में एकाधिक स्रोत फ़ाइलें हैं, तो मेसेफाइल को ऑब्जेक्ट (.o) फ़ाइलों को आवश्यकतानुसार तैयार करना चाहिए और उन्हें एक साथ लिंक करना होगा।
  3. मेकअप फाइल लिखी जानी चाहिए ताकि अगर आप पंक्ति में दो बार बना लें, तो दूसरा रन फिर से सम्मिलन नहीं करता।
  4. हर नुस्खा अपने लक्ष्य में निर्दिष्ट फ़ाइल बनाना चाहिए।
  5. प्रत्येक नुस्खा अपनी आवश्यक सूची में निर्दिष्ट प्रत्येक फ़ाइल का उपयोग करना चाहिए।
  6. दोहराव मेकफाइल से बचने के लिए .c.o जैसे लक्ष्य के लिए नियमों का उपयोग करना सीखें
  7. यदि आपके पास सिर्फ एक C या C++ स्रोत फ़ाइल है, तो निष्पादन योग्य फ़ाइल का नाम होना चाहिए (एक्सटेंशन .c या .cpp के बिना)
  8. सुनिश्चित करें कि आप उन .h फ़ाइल को सूचीबद्ध करते हैं, जहां वे आवश्यक हैं। आप के लिए शर्त सूची उत्पन्न करने के लिए मकडपेंड उपयोग करने पर विचार करें।
  • प्रलेखन: यह सिर्फ ग्रेडर के लिए नहीं है यह आपको कार्यक्रम लिखने में भी मदद करता है!
  1. प्रोग्राम लिखते समय दस्तावेज़ जोड़ें। आप हमेशा इसे अपने डिजाइन परिवर्तन के रूप में संशोधित कर सकते हैं।
  2. बाहरी दस्तावेज शामिल करें: एक प्रोग्राम को कैसे संकलित और चलाया जाता है, और इसका क्या मतलब है? बाहरी दस्तावेज एक अलग फ़ाइल में हो सकते हैं; छोटी परियोजनाओं के लिए, यह एकल स्रोत फाइल में एक टिप्पणी हो सकती है।
  3. आंतरिक दस्तावेज शामिल करें: आप किस एल्गोरिदम और डेटा संरचना का उपयोग कर रहे हैं? एक ओवरव्यू एक अलग फ़ाइल में हो सकता है, लेकिन आमतौर पर आंतरिक दस्तावेज़ीकरण विशिष्ट रूटीन, घोषणाओं, और उन चरणों का उल्लेख किया जाता है जो यह वर्णन करता है।
  4. वर्तनी की गलतियों के लिए अपना पूरा प्रोग्राम और दस्तावेज़ देखें गलत वर्तनी वाले काम में घूमने के लिए यह अयोग्य है, और यह विस्तार से बयान करता है।
  5. व्याकरण गलतियों के लिए अपने सभी दस्तावेज (और आउटपुट संदेश) की जांच करें
  6. यदि आप ब्रेसिज़ बंद करने पर थोड़ी टिप्पणी डालते हैं तो प्रोग्राम बहुत अधिक पठनीय हैं उदाहरण के लिए, एक सशर्त को बंद करने वाली ब्रेस की एक टिप्पणी हो सकती है, “यदि मूल्य अच्छा दिखता है”। एक पाश को बंद करने के लिए “प्रत्येक इनपुट लाइन के लिए” एक टिप्पणी हो सकती है एक प्रक्रिया को बंद करने के लिए केवल एक प्रक्रिया का नामकरण करने के लिए एक कसौटी पर टिप्पणी कर सकते हैं। क्लास बंद करने के लिए एक ब्रेस “क्लास” कहकर एक टिप्पणी हो सकती है और फिर क्लास का नाम।

Source: http://cs.engr.uky.edu/~raphael/checklist.html

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s