कोड पठनीयता क्यों मायने रखती है?

यह स्पष्ट है कि स्पष्ट (और सही) उत्तर "क्योंकि कोड न केवल लिखा जाना है, बल्कि पढ़ा भी है"। यह उत्तर शायद ही पूरी पोस्ट के लायक हो, लेकिन लेखक केवल इसी तक सीमित नहीं है।

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

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

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

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

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

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

आइए बारीकियों पर चलते हैं। यह वह है जो मैं कोड पठनीयता में सुधार करने के लिए महत्वपूर्ण मानता हूं।

1. संगति।

मैं बिना किसी समस्या के लगभग किसी भी शैली में कोड पढ़ सकता हूं; अनुकूलन करना सीखना था। अगर मुझे लगता है कि मुझे कोड पढ़ने की आवश्यकता है, तो मुझे सहमत होना होगा कि इसकी शैली मेरे पसंदीदा से भिन्न हो सकती है। यह केवल एक चीज़ के लिए - कोड के लिए अनुकूलित करना असंभव है, जैसे कि एक पांच वर्षीय बच्चे द्वारा लिखा गया था, जिसने अभी QWERTY से Dvorak में स्विच किया था। चाहे आप खुद स्टाइल चुनें या इसे आप पर थोपें - पूरे प्रोजेक्ट में इसके साथ रहें।

2. संगति।

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

3. स्थान जोड़ें।

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

4. पोस्ट बैनर टिप्पणी!

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

5. मैजिक नंबर का इस्तेमाल न करें।

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

6. बुद्धिमानी से अपने नाम चुनें।

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

7. एक श्रृंखला में न लिखें।

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

8. सीमा रेखा और फ़ाइल आकार।

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

9. स्कोप स्पष्ट करें।

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

10. टिप्पणी।

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

अंत में, मैं ध्यान देता हूं कि कुछ कोड को अपठनीय बनाने की आवश्यकता है। हां, तुम्हारी आंखें तुम्हें धोखा नहीं देतीं। कोड जो हैक, खराब प्रथाओं या वर्कअराउंड पर बनाया गया है, उसे खराब तरीके से पढ़ा जाना चाहिए। मेरा सबसे अच्छा उदाहरण टाइप कास्टिंग है। अक्सर वस्तुओं के उदाहरणों को कुछ प्रकारों तक कम करने की आवश्यकता होती है - यह मानक अभ्यास है, लेकिन यह अनुशंसित नहीं है। थोड़ा कम पठनीय रूप में रूपांतरण लिखना पाठक को रोकने और यह सुनिश्चित करने का एक अच्छा तरीका है कि यह एक गलती नहीं है। यह इटैलिक में कुछ हद तक पाठ जैसा है, जिसे पढ़ना कठिन है और जो इस तरह से खड़ा है। इसी तरह, वर्कअराउंड और हैक्स को बाहर खड़ा होना चाहिए। TODO और FIXME मार्कर एक अच्छी शुरुआत है; वास्तव में, अगर कोड में कहीं पर एक बैनर टिप्पणी होनी चाहिए, तो यह यहाँ है - ज्ञात समस्याओं को कोड से बाहर रहने दें। (मुख्य बात उन्हें ठीक करने के लिए नहीं भूलना है! - लगभग। प्रति)

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