स्वच्छ प्रोग्रामर मैनिफेस्टो या रॉबर्ट मार्टिन की शॉर्ट कोड बुक सारांश

यह लेख रॉबर्ट मार्टिन की स्वच्छ संहिता पुस्तक का एक सारांश है और स्वच्छ संहिता कैसी होनी चाहिए, इसकी मेरी समझ है। परीक्षण, टीडीडी, वास्तुकला क्या होनी चाहिए आदि पर कोई खंड नहीं हैं। यहाँ सब कुछ बस के बारे में है कि क्लीन कोड क्या होना चाहिए।

हां, शायद क्लीन कोड का विषय पहले से ही हैक किया गया है, लेकिन फिर भी, हर कोई इससे परिचित नहीं है और इसके अलावा, मुझे मेरे लेख में शामिल सामग्री के एनालॉग्स नहीं मिले हैं।

संपूर्ण

कोई सही तरीका और उपाय नहीं है। एक है जो एक विशिष्ट कार्य के लिए सबसे उपयुक्त है।

किसी समस्या को हल करते समय, उन सभी मामलों को पुन: पेश करने का प्रयास करें जो इस कार्य को प्रभावित कर सकते हैं और कार्य को बिल्कुल सभी मामलों को ध्यान में रखते हुए कार्यान्वित कर सकते हैं।

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

किसी कार्य को रिलीज़ करने से पहले, यह जांचें कि क्या वह सही तरीके से काम करता है। क्या इसमें कोई त्रुटि हैं। यह उन कमिटों पर भी लागू होता है जो आपकी शाखा में भेजी जाती हैं। सबसे आदर्श परिदृश्य वह है जिसमें कोई भी उस कार्यक्षमता में त्रुटि नहीं पा सकता है जिसे आपने विकसित किया था।

हमेशा इस बारे में सोचें कि आप अपने कोड को सरल, क्लीनर और अधिक पठनीय कैसे बना सकते हैं।

• किसी कार्य के क्या मामले हो सकते हैं?
• क्या मैंने सब कुछ ध्यान में रखा है?
• क्या गलत हो सकता है?
• क्या संयुक्त हो सकता है?
• क्या कोई समान कार्यक्षमता है?
• यहाँ क्या अतिरेक है?
• इसे आसान कैसे बनाया जाए?
• इसे और अधिक पठनीय कैसे बनाया जाए?
• इसे कैसे स्पष्ट किया जाए?

साफ कोड

स्वच्छ और अच्छा कोड कैसे लिखें? यह किताब लिखने जैसा है। पहले आप एक मसौदा तैयार करते हैं और फिर इसे उस स्थिति में कंघी करते हैं जिसमें आप इसे पढ़कर प्रसन्न होंगे। हमेशा याद रखें कि आपके कोड को एक कहानी बतानी होगी ताकि पाठक उसे समझ सके।

एक इकाई को समझा जाता है - एक इंटरफ़ेस, एक वर्ग, एक विधि, एक चर, एक वस्तु, आदि।

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

नाम और विभाग

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

कार्यों

• कार्य छोटा और कॉम्पैक्ट होना चाहिए।
• फ़ंक्शंस बहुत कम और बहुत कॉम्पैक्ट होना चाहिए।
• एक पंक्ति में अधिकतम 20 रेखाएँ और 150 वर्ण, यदि यह फिट नहीं है, तो आपको अलग होने की आवश्यकता है।
• एक फ़ंक्शन को केवल एक ऑपरेशन करना होगा।
  
  • उसे अच्छा करना चाहिए और उसे कुछ और नहीं करना चाहिए।
  • यदि कोई फ़ंक्शन केवल उन कार्यों को करता है जो अमूर्तता के समान स्तर पर हैं, तो फ़ंक्शन एक ऑपरेशन करता है।
  • यह निर्धारित करने के लिए कि क्या कोई फ़ंक्शन एक से अधिक ऑपरेशन करता है, उससे एक और फ़ंक्शन निकालने का प्रयास करें, जो कार्यान्वयन का एक सरल सुधार नहीं होगा।
• स्विच-केस के माध्यम से लंबे विकल्पों के साथ कोई भी सशर्त बयान, यदि-और बिना विभाजन के संयुक्त रूप से विभाजित किया जाना चाहिए, संभवतः कार्यान्वयन के साथ कक्षाओं में, और कार्यान्वयन का विकल्प आधार वर्ग, कारखाने, या किसी और को स्थानांतरित कर सकता है।
• यदि, और, जबकि, आदि। एक फ़ंक्शन में एक कॉल होना चाहिए। यह अधिक पठनीय, स्पष्ट और आसान होगा।
• किसी फ़ंक्शन के लिए इनपुट तर्कों की आदर्श संख्या = 0. यदि तीन से अधिक इनपुट तर्क हैं, तो आपको विचार करना चाहिए कि उनसे कैसे छुटकारा पाना है, उदाहरण के लिए, इन तर्कों के लिए एक वर्ग बनाएं।
• अधिक इनपुट तर्क, अधिक कठिन फ़ंक्शन को समझा जाता है।
• जिस फ़ंक्शन को तर्क वितर्क पास किया जाता है, जिस पर फ़ंक्शन का संचालन निर्भर करता है, यह इंगित करता है कि फ़ंक्शन एक से अधिक ऑपरेशन करता है। ऐसे कार्यों को दो में विभाजित किया जाना चाहिए और उन्हें उच्च स्तर कहा जाना चाहिए।
• एक फ़ंक्शन जो इनपुट तर्क को संशोधित करता है, उसे बदले हुए ऑब्जेक्ट का संदर्भ देना चाहिए, और न केवल इसे वापस किए बिना संशोधित करना चाहिए। String transform(String text)
• यदि फ़ंक्शन को इनपुट तर्क को बदलना होगा, तो उसे उसके स्वामी ऑब्जेक्ट की स्थिति को बदलने दें।
• यदि फ़ंक्शन के इनपुट तर्क को बदलना नहीं चाहिए (और कोड में आगे उपयोग किया जाता है), तो आपको तर्क के मूल्य को कॉपी करना चाहिए और फ़ंक्शन के अंदर कॉपी के साथ काम करना चाहिए।
• वापसी नल के बजाय, खाली ऑब्जेक्ट - Collection.empty() या एक null ऑब्जेक्ट - EmptyObject() का उपयोग करना बेहतर है।
• हमेशा गैर-स्थिर कार्यों का उपयोग करने का प्रयास करें। यदि यह संभव नहीं है, तो स्थैतिक का उपयोग करें।
• यदि एक कोड है जिसे एक के बाद एक का पालन करना चाहिए, तो पहले फ़ंक्शन के परिणाम को दूसरे में पास करें ताकि कोई कॉल के अनुक्रम को न बदले।
• के बजाय बहुरूपता का उपयोग करें / या तो या स्विच / मामले या कब।
• नकारात्मक परिस्थितियों से बचें।

टिप्पणियाँ

• यदि आप किसी फ़ंक्शन या चर का उपयोग कर सकते हैं तो टिप्पणियों का उपयोग न करें।
• बुरे कोड पर टिप्पणी न करें - इसे फिर से लिखें। यह स्पष्ट करने योग्य नहीं है कि बुरे कोड में क्या होता है, इसे स्पष्ट और समझने योग्य बनाना बेहतर है।
• टिप्पणियों का उपयोग कुछ जानकारी, परिणामों के बारे में चेतावनी देने के लिए किया जा सकता है, लेकिन यह समझाने के लिए नहीं कि कोड कैसे काम करता है।
• TODO और FIXME का उपयोग उन मामलों में करें जहां आपको यह ध्यान देने की आवश्यकता है कि कोड को सुधारने की आवश्यकता है, लेकिन अब इसके लिए कोई संसाधन नहीं हैं।
• उपयोग //region REGIONNAME //endregion REGIONNAME , और यदि आप उपयोग करते हैं, तो सोचें कि क्या क्षेत्र को संस्थाओं में विभाजित करना संभव है।
• दस्तावेज़ कोड जो जटिल लेकिन साफ ​​है।
• पुराने टिप्पणी वाले कोड को मत छोड़ो। यदि आवश्यक हो, तो आप इसे प्रतिबद्ध इतिहास में पा सकते हैं।
• टिप्पणियाँ संक्षिप्त और स्पष्ट होनी चाहिए। सूचना टिप्पणियों में अधिक जानकारी नहीं होनी चाहिए। सब कुछ संक्षिप्त और बिंदु तक होना चाहिए।

प्रारूपण और नियम

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

ऑब्जेक्ट और डेटा संरचनाएं

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

कक्षाएं

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

हैंडलिंग में त्रुटि

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

सीमाओं

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

अंतभाषण

यह लेख क्लीन कोड लिखने के लिए केवल दिशानिर्देश प्रदान करता है। बेशक, उनकी उपेक्षा की जा सकती है। आपको बस यह समझने की जरूरत है कि आपके किसी भी निर्णय के पक्ष में तर्क होना चाहिए।