अपने कोड के बदबूदार हिस्सों को कैसे खोजें [भाग XXIX]

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

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

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

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

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

आगे है...

कोड स्मेल 141 - IEngine, AVehicle, ImplCar

क्या तुमने कभी जंगली में एक IEngine देखा है?

टीएल; डीआर: अपनी कक्षाओं में उपसर्ग या प्रत्यय न लगाएं

समस्या

• पठनीयता
• द्विभाजन दोष
• कार्यान्वयन नाम

समाधान

1. उपसर्गों और प्रत्ययों को हटा दें
2. वे जो करते हैं उसके बाद अपनी वस्तुओं का नाम दें

प्रसंग

कुछ भाषाओं में डेटा प्रकार, सार वर्ग या इंटरफेस से संबंधित सांस्कृतिक सम्मेलन होते हैं। ये नाम हमारे मॉडलों को संज्ञानात्मक अनुवादों के साथ लोड करते हैं जिनका पालन करना कठिन होता है।

हमें किस करना चाहिए।

नमूना कोड

गलत

 public interface IEngine { void Start(); } public class ACar { } public class ImplCar { } public class CarImpl { }

सही

 public interface Engine { void Start(); } public class Vehicle { } public class Car { }

खोज

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

यदि हमारे पास थिसॉरस है, तो हम अजीब नामों की ओर इशारा कर सकते हैं।

अपवाद

सी # में, इंटरफ़ेस के नाम पर "आई" रखना एक आम बात है क्योंकि इसके बिना, आप यह नहीं बता सकते कि यह एक इंटरफ़ेस या कक्षा है या नहीं।

यह एक भाषा गंध है।

टैग

• नामकरण

निष्कर्ष

अपने मॉडलों के लिए वास्तविक नामों का उपयोग करें।

रिश्ते

कोड गंध 130 - पताImpl

और जानकारी

• नाम में क्या रखा है: भाग II पुनर्वसन

क्रेडिट

अनस्प्लैश पर टिम मॉसहोल्डर द्वारा फोटो

कुछ लोग, जब किसी समस्या का सामना करते हैं, सोचते हैं "मुझे पता है, मैं रेगुलर एक्सप्रेशंस का उपयोग करूँगा।" अब उनके सामने दो दिक्कतें हैं।

जेमी ज़विंस्की

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

कोड स्मेल 142 - कंस्ट्रक्टर्स में प्रश्न

डोमेन ऑब्जेक्ट्स में डेटाबेस तक पहुँचना एक कोड गंध है। इसे कंस्ट्रक्टर में करना एक दोहरी गंध है।

टीएल; डीआर: कंस्ट्रक्टर्स को ऑब्जेक्ट्स बनाना चाहिए (और शायद इनिशियलाइज़ करना चाहिए)।

समस्या

• युग्मन
• दुष्प्रभाव

समाधान

1. आकस्मिक दृढ़ता से आवश्यक व्यावसायिक तर्क को अलग करें।
2. दृढ़ता कक्षाओं पर, कन्स्ट्रक्टर/विनाशकों के अलावा अन्य कार्यों में प्रश्न चलाएं।

प्रसंग

विरासत कोड पर, डेटाबेस व्यावसायिक वस्तुओं से सही ढंग से अलग नहीं होता है।

कंस्ट्रक्टर्स का कभी भी साइड इफेक्ट नहीं होना चाहिए।

एकल जिम्मेदारी सिद्धांत के अनुसार, उन्हें केवल वैध वस्तुओं का निर्माण करना चाहिए

नमूना कोड

गलत

 public class Person { int childrenCount; public Person(int id) { childrenCount = database.sqlCall("SELECT COUNT(CHILDREN) FROM PERSON WHERE ID = " . id); } }

सही

 public class Person { int childrenCount; // Create a class constructor for the Main class public Person(int id, int childrenCount) { childrenCount = childrenCount; // We can assign the number in the constructor // Accidental Database is decoupled // We can test the object } }

खोज

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

हमारे लिंटर कंस्ट्रक्टर पर SQL पैटर्न ढूंढ सकते हैं और हमें चेतावनी दे सकते हैं।

टैग

• युग्मन

निष्कर्ष

मजबूत सॉफ़्टवेयर डिज़ाइन करते समय चिंताओं को अलग करना महत्वपूर्ण है, और युग्मन हमारा मुख्य शत्रु है।

और जानकारी

• युग्मन: एकमात्र सॉफ्टवेयर समस्या

क्रेडिट

<span> अनस्प्लैश पर कैलम हिल द्वारा फोटो </span>

मेरा विश्वास अभी भी है, अगर आपको डेटा संरचनाएं और उनके आविष्कार सही मिलते हैं, तो अधिकांश कोड खुद ही लिखेंगे।

पीटर ड्यूश

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

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

कुछ वस्तुएं हमेशा साथ रहती हैं। हम उन्हें विभाजित क्यों नहीं करते?

टीएल; डीआर: एकजुट आदिम वस्तुओं को एक साथ यात्रा करें

समस्या

• खराब सामंजस्य
• डुप्लीकेट कोड
• सत्यापन जटिलता
• पठनीयता
• रख-रखाव

समाधान

1. एक्सट्रैक्ट क्लास
2. छोटी वस्तुओं का पता लगाएं

प्रसंग

यह गंध आदिम जुनून की दोस्त है।

यदि दो या अधिक आदिम वस्तुओं को एक साथ चिपकाया जाता है, व्यापार तर्क दोहराया जाता है और उनके बीच नियम होते हैं, तो हमें आपत्ति की मौजूदा अवधारणा को खोजने की आवश्यकता होती है।

नमूना कोड

गलत

 public class DinnerTable { public DinnerTable(Person guest, DateTime from, DateTime to) { Guest = guest; From = from; To = to; } private Person Guest; private DateTime From; private DateTime To; }

सही

 public class TimeInterval { public TimeInterval(DateTime from, DateTime to) { // We should validate From < To From = from; To = to; } } public DinnerTable(Person guest, DateTime from, DateTime to) { Guest = guest; Interval = new TimeInterval(from, to); } // Even Better... public DinnerTable(Person guest, Interval reservationTime) { Guest = guest; Interval = reservationTime; }

खोज

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

सामंजस्य पैटर्न के आधार पर जांच कुछ लिंटरों में उपलब्ध है।

टैग

• एकजुटता

निष्कर्ष

समूह व्यवहार सही जगह पर और आदिम डेटा को छुपाएं।

रिश्ते

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

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

कोड गंध 27 - साहचर्य सारणियाँ

और जानकारी

• रिफैक्टरिंग गुरु
• विकिपीडिया

क्रेडिट

अनस्प्लैश पर डायनामिक वैंग द्वारा फोटो

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

एरिक इवांस

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

कोड स्मेल 144 - फंजिबल ऑब्जेक्ट्स

हमने एनएफटी के बारे में बहुत कुछ सुना है। अब, हम फंजिबल अवधारणा में महारत हासिल करते हैं।

टीएल; डीआर: मैपर का सम्मान करें। वास्तविक दुनिया में फंजिबल को फंगिबल बनाएं और इसके विपरीत।

समस्या

• द्विभाजन दोष
• ओवर डिजाइन

समाधान

1. अपने डोमेन पर वैकल्पिक तत्वों की पहचान करें
2. उन्हें विनिमेय के रूप में मॉडल करें

प्रसंग

विकिपीडिया के अनुसार:

फंगिबिलिटी एक अच्छे या कमोडिटी की संपत्ति है, जिसकी अलग-अलग इकाइयाँ अनिवार्य रूप से विनिमेय हैं और जिसका प्रत्येक भाग दूसरे भाग से अप्रभेद्य है।

सॉफ्टवेयर में, हम फंगिबल ऑब्जेक्ट्स को दूसरों के साथ बदल सकते हैं।

वास्तविक वस्तुओं के साथ अपनी वस्तुओं की मैपिंग करते समय, हम कभी-कभी आंशिक मॉडल के बारे में भूल जाते हैं और डिज़ाइन पर निर्माण करते हैं।

नमूना कोड

गलत

 public class Person implements Serializable { private final String firstName; private final String lastName; public Person(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } } shoppingQueueSystem.queue(new Person('John', 'Doe'));

सही

 public class Person { } shoppingQueueSystem.queue(new Person()); // The identity is irrelevant for queue simulation

खोज

• [एक्स] मैनुअल

यह एक अर्थपूर्ण गंध है।

हमें यह जांचने के लिए मॉडल को समझने की जरूरत है कि यह सही है या नहीं।

टैग

• ओवर डिजाइन

निष्कर्ष

जो प्रतिमोच्य है उसे प्रतिमोच्य बनाएं और इसके विपरीत।

आसान लगता है लेकिन डिजाइन कौशल और आकस्मिक जटिलता से बचने की आवश्यकता होती है।

क्रेडिट

अनस्प्लैश पर एंड्री मेटेलेव द्वारा फोटो

लोग सोचते हैं कि कंप्यूटर विज्ञान जीनियस की कला है, लेकिन वास्तविक वास्तविकता इसके विपरीत है, बहुत से लोग छोटे पत्थरों की दीवार की तरह एक दूसरे पर निर्माण करने वाली चीजें कर रहे हैं।

डोनाल्ड नुथ

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

पठनीयता शॉर्टकट के रूप में बूलियन मूल्यांकन का उपयोग न करें।

टीएल; डीआर: साइड इफेक्ट कार्यों के लिए बूलियन तुलना का उपयोग न करें।

समस्या

• पठनीयता
• दुष्प्रभाव

समाधान

1. शॉर्ट सर्किट को IFs में बदलें

प्रसंग

स्मार्ट प्रोग्रामर इस सुधार के लिए कोई पुख्ता सबूत न होने पर भी हैकी और अस्पष्ट कोड लिखना पसंद करते हैं।

समयपूर्व अनुकूलन हमेशा पठनीयता को नुकसान पहुँचाता है।

नमूना कोड

गलत

 userIsValid() && logUserIn(); // this expression is short circuit // Does not value second statement // Unless the first one is true functionDefinedOrNot && functionDefinedOrNot(); // in some languages undefined works as a false // If functionDefinedOrNot is not defined does // not raise an error and neither runs

सही

 if (userIsValid()) { logUserIn(); } if(typeof functionDefinedOrNot == 'function') { functionDefinedOrNot(); } // Checking for a type is another code smell

खोज

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

हम जाँच सकते हैं कि क्या कार्य अशुद्ध हैं और शॉर्ट सर्किट को IF में बदल सकते हैं।

कुछ वास्तविक लिंटर हमें इस समस्या से आगाह करते हैं

टैग

• समयपूर्व अनुकूलन

निष्कर्ष

स्मार्ट दिखने की कोशिश न करें।

हम अब 50 के दशक में नहीं हैं।

एक टीम डेवलपर बनें।

रिश्ते

कोड स्मेल 140 - शॉर्ट सर्किट मूल्यांकन

कोड स्मेल 06 - बहुत चालाक प्रोग्रामर

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

क्रेडिट

Unsplash पर Michael Dziedzic द्वारा फोटो

एक कंप्यूटर एक बेवकूफ मशीन है जिसमें अविश्वसनीय रूप से स्मार्ट चीजें करने की क्षमता है, जबकि कंप्यूटर प्रोग्रामर अविश्वसनीय रूप से बेवकूफ चीजें करने की क्षमता वाले स्मार्ट लोग हैं। संक्षेप में, वे एक परिपूर्ण मेल हैं।

बिल ब्रायसन

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