कोड स्मेल एक क्लासिक हैं।

यह गंध करता है क्योंकि ऐसे कई उदाहरण हैं जहां इसे संपादित या बेहतर किया जा सकता है।

इनमें से अधिकतर गंध कुछ गलत होने का संकेत हैं। इसलिए, उन्हें अपने आप ठीक करने की आवश्यकता नहीं है ... (हालांकि, आपको इसे देखना चाहिए।)

पिछला कोड बदबू आ रही है

आप पिछले सभी कोड गंध (भाग i - XXIX) यहां पा सकते हैं

आगे है...

कोड स्मेल 146 - टिप्पणियाँ प्राप्त करें

टिप्पणियाँ एक कोड गंध हैं। गेटर्स एक और कोड गंध हैं। अंदाज़ा लगाओ?

टीएल; डीआर: गेटर्स का प्रयोग न करें। गेटर्स पर टिप्पणी न करें

समस्या

• दुर्व्यवहार करने वाले टिप्पणी करें
• पठनीयता
• टिककर खेल

समाधान

1. गेटर टिप्पणियां हटाएं
2. गेटर्स को हटा दें

प्रसंग

कुछ दशक पहले तक हम हर तरीके पर टिप्पणी किया करते थे। तुच्छ भी।

टिप्पणी में केवल एक महत्वपूर्ण डिजाइन निर्णय का वर्णन होना चाहिए।

नमूना कोड

गलत

 pragma solidity >=0.5.0 <0.9.0; contract Property { int private price; function getPrice() public view returns(int) { /* returns the Price */ return price; } }

सही

 pragma solidity >=0.5.0 <0.9.0; contract Property { int private _price; function price() public view returns(int) { return _price; } }

खोज

• [x] अर्ध-स्वचालित

हम यह पता लगा सकते हैं कि क्या कोई विधि गेट्टर है और उसकी कोई टिप्पणी है।

अपवाद

फ़ंक्शन को एक टिप्पणी की आवश्यकता होती है, जो गलती से एक प्राप्तकर्ता है और टिप्पणी एक डिज़ाइन निर्णय से संबंधित है

टैग

• टिप्पणियाँ

निष्कर्ष

गेटर्स पर टिप्पणी न करें।

वे कोई वास्तविक मूल्य नहीं जोड़ते हैं और आपके कोड को ब्लोट करते हैं।

रिश्ते

कोड स्मेल 05 - अपशब्दों पर टिप्पणी करें

कोड गंध 68 - गेटर्स

कोड स्मेल 01 - एनीमिक मॉडल

क्रेडिट

Unsplash पर Reimond de Zuñiga द्वारा फ़ोटो

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

रॉबर्ट मार्टिन

सॉफ्टवेयर इंजीनियरिंग महान उद्धरण

कोड स्मेल 147 - बहुत सारी विधियाँ

प्रोटोकॉल इकट्ठा करने के लिए उपयोग कक्षाएं बहुत अच्छी हैं।

टीएल; डीआर: अपनी कक्षाओं में आकस्मिक प्रोटोकॉल न जोड़ें

समस्या

• पठनीयता
• एकल उत्तरदायित्व उल्लंघन
• खराब सामंजस्य
• उच्च युग्मन
• कम पुन: प्रयोज्य

समाधान

1. अपनी कक्षा तोड़ो
2. एक्सट्रैक्ट क्लास

रिफैक्टरिंग

रिफैक्टरिंग 007 - एक्सट्रैक्ट क्लास

प्रसंग

हम पाते हैं कि प्रथम श्रेणी में एक प्रोटोकॉल डालते हैं।

वह कोई समस्या नहीं है।

हमें सिर्फ रिफैक्टर करने की जरूरत है।

नमूना कोड

गलत

 public class MyHelperClass { public void print() { } public void format() { } // ... many methods more // ... even more methods public void persist() { } public void solveFermiParadox() { } }

सही

 public class Printer { public void print() { } } public class DateToStringFormatter { public void format() { } } public class Database { public void persist() { } } public class RadioTelescope { public void solveFermiParadox() { } }

खोज

• [एक्स] स्वचालित

अधिकांश लिंटर विधियों को गिनते हैं और हमें चेतावनी देते हैं।

रिश्ते

कोड स्मेल 124 - डायवर्जेंट चेंज

कोड स्मेल 143 - डेटा क्लंप

कोड स्मेल 94 - बहुत अधिक आयात

कोड स्मेल 22 - हेल्पर्स

कोड स्मेल 34 - बहुत सारी विशेषताएँ

और जानकारी

रिफैक्टरिंग गुरु

टैग

• एकजुटता
• ब्लोटर्स

निष्कर्ष

छोटी और पुन: प्रयोज्य वस्तुओं के पक्ष में वर्गों और प्रोटोकॉल को विभाजित करना एक अच्छा अभ्यास है।

क्रेडिट

Unsplash पर Marcin Simonides द्वारा फोटो

कोई भी कोड इतना बड़ा, टेढ़ा या जटिल नहीं है कि रखरखाव इसे खराब न कर सके।

गेराल्ड एम. वेनबर्ग

कोड स्मेल 148 - ToDos

हम अपने भविष्य के लिए कर्ज खरीदते हैं। यह लौटाने का समय है।

टीएल; डीआर: अपने कोड में TODO न छोड़ें। उन्हें ठीक करें!

समस्या

• तकनीकी ऋण
• पठनीयता
• आत्मविश्वास की कमी

समाधान

1. अपने TODO को ठीक करें

प्रसंग

हम अपने कोड में TODO का सामना करते हैं। हम उन्हें गिनते हैं।

हम इसे शायद ही कभी संबोधित करते हैं।

हमने तकनीकी ऋण देना शुरू कर दिया।

फिर हम कर्ज + ब्याज चुकाते हैं।

कुछ महीनों के बाद, हम मूल ऋण से अधिक ब्याज का भुगतान करते हैं।

नमूना कोड

गलत

 public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { // TODO: Implement close door and cover it } }

सही

 public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { this.isOpened = false; } }

खोज

• [एक्स] स्वचालित

हम TODO की गिनती कर सकते हैं।

टैग

• तकनीकी ऋण

निष्कर्ष

हम TODO की गिनती कर सकते हैं।

ज्यादातर लिंटर करते हैं।

हमें उन्हें कम करने के लिए नीति की आवश्यकता है।

यदि हम टीडीडी का उपयोग कर रहे हैं, तो हम लापता कोड को तुरंत लिख देते हैं।

इस संदर्भ में, TODO केवल तभी मान्य होते हैं जब यात्रा के खुले रास्तों को याद रखने के लिए डेप्थ फ़र्स्ट डेवलपमेंट करते हैं।

और जानकारी

• क्या आपको ToDos लगाना चाहिए?
• टूटी हुई विंडोज थ्योरी

क्रेडिट

अनस्प्लैश पर ईडन कॉन्स्टैंटिनो द्वारा फोटो

किसी प्रोजेक्ट का पहला 90% पूरा करने के बाद, आपको अन्य 90% पूरा करना होगा।

माइकल अब्राश

कोड स्मेल 149 - वैकल्पिक चेनिंग

हमारा कोड अधिक मजबूत और सुपाठ्य है। लेकिन हम गलीचा के नीचे न्यूल छुपाते हैं।

टीएल; डीआर: नल और अपरिभाषित से बचें। यदि आप उनसे बचते हैं तो आपको वैकल्पिक विकल्पों की कभी आवश्यकता नहीं पड़ेगी।

समस्या

• अशक्त
• अगर प्रदूषणकारी

समाधान

1. शून्य हटाओ
2. अपरिभाषित से निपटें

प्रसंग

वैकल्पिक श्रृंखलन , वैकल्पिक, सहसंयोजन, और कई अन्य समाधान कुख्यात अशक्तताओं से निपटने में हमारी सहायता करते हैं।

एक बार हमारा कोड परिपक्व, मजबूत और शून्य के बिना उनका उपयोग करने की कोई आवश्यकता नहीं है।

नमूना कोड

गलत

 const user = { name: 'Hacker' }; if (user?.credentials?.notExpired) { user.login(); } user.functionDefinedOrNot?.(); // Seems compact but it is hacky and has lots // of potential NULLs and Undefined

सही

 function login() {} const user = { name: 'Hacker', credentials: { expired: false } }; if (!user.credentials.expired) { login(); } // Also compact // User is a real user or a polymorphic NullUser // Credentials are always defined. // Can be an instance of InvalidCredentials // Assuming we eliminated nulls from our code if (user.functionDefinedOrNot !== undefined) { functionDefinedOrNot(); } // This is also wrong. // Explicit undefined checks are yet another code smell

खोज

• [एक्स] स्वचालित

यह एक भाषा विशेषता है।

हम इसका पता लगा सकते हैं और इसे हटा सकते हैं।

टैग

• शून्य

निष्कर्ष

कई डेवलपर्स अशक्त व्यवहार के साथ कोड को प्रदूषित करने में सुरक्षित महसूस करते हैं।

वास्तव में, यह NULL का इलाज न करने से ज्यादा सुरक्षित है।

अशक्त मूल्य , सत्य और मिथ्या भी कोड गंध हैं।

हमें उच्च लक्ष्य रखने और क्लीनर कोड बनाने की जरूरत है।

अच्छा : अपने कोड से सभी नल हटा दें।

खराब : वैकल्पिक श्रृंखलन का उपयोग करें।

कुरूप : अशक्तता का इलाज बिल्कुल नहीं।

रिश्ते

कोड स्मेल 145 - शॉर्ट सर्किट हैक

कोड गंध 12 - अशक्त

कोड गंध 69 - बिग बैंग (जावास्क्रिप्ट हास्यास्पद कास्टिंग)

और जानकारी

• वैकल्पिक श्रृंखलन संदर्भ

अशक्त: द बिलियन डॉलर मिस्टेक

कष्टप्रद आईएफएस से हमेशा के लिए कैसे छुटकारा पाएं

वाट?

क्रेडिट

अनस्प्लैश पर एंजिन आक्यूर्ट द्वारा फोटो

वह जो राक्षसों से लड़ता है वह ध्यान रख सकता है कि कहीं वह राक्षस न बन जाए। और यदि आप लंबे समय तक रसातल में देखते हैं, तो रसातल भी आपको देखता है।

नीत्शे

कोड गंध 150 - समान तुलना

प्रत्येक डेवलपर विशेषताओं की समान रूप से तुलना करता है। वे गलत हैं।

टीएल; डीआर: निर्यात और तुलना न करें, बस तुलना करें।

समस्या

• एनकैप्सुलेशन ब्रेक
• कोड दोहराव
• सूचना उल्लंघन छुपा रहा है
• नृविज्ञान उल्लंघन

समाधान

1. तुलना को एक विधि में छुपाएं

प्रसंग

हमारे कोड में विशेषता तुलना का अत्यधिक उपयोग किया जाता है।

हमें व्यवहार और जिम्मेदारियों पर ध्यान देने की जरूरत है।

अन्य वस्तुओं के साथ तुलना करना एक वस्तु की जिम्मेदारी है। हमारा अपना नहीं।

समयपूर्व अनुकूलक हमें बताएंगे कि यह कम प्रदर्शनकारी है।

हमें उनसे वास्तविक प्रमाण मांगना चाहिए और अधिक बनाए रखने योग्य समाधान के विपरीत होना चाहिए।

नमूना कोड

गलत

 if (address.street == 'Broad Street') { if (location.street == 'Bourbon St') { // 15000 usages in a big system // Comparisons are case sensitive

सही

 if (address.isAtStreet('Broad Street') { } // ... if (location.isAtStreet('Bourbon St') { } // 15000 usages in a big system function isAtStreet(street) { // We can change Comparisons to // case sensitive in just one place. }

खोज

• [x] अर्ध-स्वचालित

हम सिंटैक्स ट्री का उपयोग करके विशेषता तुलना का पता लगा सकते हैं।

आदिम प्रकारों के लिए कई अन्य गंधों के साथ अच्छे उपयोग हो सकते हैं।

टैग

• कैप्सूलीकरण

निष्कर्ष

हमें जिम्मेदारियों को एक ही स्थान पर रखने की जरूरत है।

तुलना करना उनमें से एक है।

यदि हमारे कुछ व्यावसायिक नियम बदलते हैं, तो हमें एक बिंदु को बदलने की आवश्यकता है।

रिश्ते

कोड स्मेल 63 - फ़ीचर ईर्ष्या

कोड गंध 101 - बूलियंस के खिलाफ तुलना

कोड गंध 122 - आदिम जुनून

क्रेडिट

Unsplash पर Piret Ilver द्वारा फोटो

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

माइकल पंख

अगला लेख: 5 और कोड गंध।