यह गंध करता है क्योंकि ऐसे कई उदाहरण हैं जहां इसे संपादित या सुधार किया जा सकता है।
इनमें से अधिकतर गंध कुछ गलत होने का संकेत मात्र हैं। वे अनिवार्य रूप से निश्चित नहीं हैं ... (हालांकि आपको इसे देखना चाहिए।)
चलो जारी रखते है...
बूलियन से तुलना करते समय, हम जादुई कास्टिंग करते हैं और अप्रत्याशित परिणाम प्राप्त करते हैं।
TL; DR: सत्य से तुलना न करें। या तो आप सच्चे हैं, या झूठे हैं या आपको तुलना नहीं करनी चाहिए
कई भाषाओं ने बूलियन क्रॉसिंग डोमेन को मान दिया है।
#!/bin/bash if [ false ]; then echo "True" else echo "False" fi # this evaluates to true since # "false" is a non-empty string if [ false ] = true; then echo "True" else echo "False" fi # this also evaluates to true
#!/bin/bash if false ; then echo "True" else echo "False" fi # this evaluates to false
लिंटर स्पष्ट तुलना और चेतावनियों की जांच कर सकते हैं।
कई गैर-बूलियन को बूलियन के रूप में उपयोग करना एक सामान्य उद्योग प्रथा है। बूलियन का उपयोग करते समय हमें बहुत सख्त होना चाहिए।
कोड गंध 69 - बिग बैंग (जावास्क्रिप्ट हास्यास्पद कास्टिंग)
Unsplash . पर माइकल हेल्ड द्वारा फोटो
यदि यह काम नहीं करता है, तो इससे कोई फर्क नहीं पड़ता कि यह कितनी तेजी से काम नहीं करता है।
- मिच रावेरा
नेस्टेड IFs और Elses को पढ़ना और परीक्षण करना बहुत कठिन है
TL; DR: नेस्टेड IFs से बचें। और भी बेहतर: सभी IFs से बचें
प्रक्रियात्मक कोड में, जटिल नेस्टेड आईएफएस देखना बहुत आम है। यह समाधान ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग की तुलना में स्क्रिप्टिंग से अधिक संबंधित है।
if (actualIndex < totalItems) { if (product[actualIndex].Name.Contains("arrow")) { do { if (product[actualIndex].price == null) { // handle no price } else { if (!(product[actualIndex].priceIsCurrent())) { // add price } else { if (!hasDiscount) { // handle discount } else { // etc } } } actualIndex++; } while (actualIndex < totalCounf && totalPrice < wallet.money); } else actualIndex++; } return actualIndex; }
foreach (products as currentProduct) addPriceIfDefined(currentProduct) addPriceIfDefined() { //Several extracts }
चूंकि कई लिंटर पेड़ों को पार्स कर सकते हैं, हम घोंसले के स्तर के लिए संकलन-समय की जांच कर सकते हैं।
अंकल बॉब की सलाह के बाद, हमें कोड क्लीनर को छोड़ देना चाहिए जितना हमने पाया।
इस समस्या को रिफैक्टर करना आसान है।
कोड गंध 03 - कार्य बहुत लंबे हैं
कोड गंध 36 - स्विच/केस/elseif/else/if कथन
सॉफ्टवेयर इंजीनियरिंग का उद्देश्य जटिलता को नियंत्रित करना है, न कि उसे बनाना।
- पामेला ज़वेस
अपने स्वयं के एक्सेसर विधियों को कॉल करना एक अच्छा इनकैप्सुलेशन विचार प्रतीत हो सकता है। लेकिन यह नहीं है।
टीएल; डीआर: निजी इस्तेमाल के लिए भी सेटर्स और गेटर्स का उपयोग न करें
90 के दशक में डबल एनकैप्सुलेशन का उपयोग करना एक मानक प्रक्रिया थी।
हम निजी इस्तेमाल के लिए भी कार्यान्वयन विवरण छिपाना चाहते थे।
यह एक और गंध छिपा रहा था जब बहुत सारे कार्य डेटा संरचना और आकस्मिक कार्यान्वयन पर निर्भर करते हैं।
उदाहरण के लिए, हम किसी वस्तु के आंतरिक प्रतिनिधित्व को बदल सकते हैं और उसके बाहरी प्रोटोकॉल पर भरोसा कर सकते हैं।
लागत/लाभ इसके लायक नहीं है।
contract MessageContract { string message = "Let's trade"; function getMessage() public constant returns(string) { return message; } function setMessage(string newMessage) public { message = newMessage; } function sendMessage() public constant { this.send(this.getMessage()); // We can access property but make a self call instead } }
contract MessageContract { string message = "Let's trade"; function sendMessage() public constant { this.send(message); } }
हम गेटर्स और सेटर्स का अनुमान लगा सकते हैं और जांच सकते हैं कि क्या उन्हें एक ही वस्तु से बुलाया गया है।
आकस्मिक कार्यान्वयन की रक्षा के लिए डबल एनकैप्सुलेशन एक ट्रेंडी विचार था, लेकिन यह संरक्षित से अधिक उजागर हुआ।
Unsplash . पर रे हेनेसी द्वारा फोटो
उस अवधारणा को समाहित करें जो भिन्न होती है।
- एरिच गामा
बूलियन के खिलाफ जोर देने से त्रुटि ट्रैकिंग अधिक कठिन हो जाती है।
टीएल; डीआर: जब तक आप बूलियन की जांच नहीं कर रहे हैं, तब तक सत्य का दावा न करें
बूलियन का दावा करते समय हमारे परीक्षण इंजन हमारी बहुत मदद नहीं कर सकते हैं।
वे बस हमें बताते हैं कि कुछ विफल रहा।
त्रुटि ट्रैकिंग अधिक कठिन हो जाती है।
<? final class RangeUnitTest extends TestCase { function testValidOffset() { $range = new Range(1, 1); $offset = $range->offset(); $this->assertTrue(10 == $offset); // No functional essential description :( // Accidental description provided by tests is very bad } } // When failing Unit framework will show us // // 1 Test, 1 failed // Failing asserting true matches expected false :( // () <-- no business description :( // // <Click to see difference> - Two booleans // (and a diff comparator will show us two booleans)
<? final class RangeUnitTest extends TestCase { function testValidOffset() { $range = new Range(1, 1); $offset = $range->offset(); $this->assertEquals(10, $offset, 'All pages must have 10 as offset'); // Expected value should always be first argument // We add a functional essential description // to complement accidental description provided by tests } } // When failing Unit framework will show us // // 1 Test, 1 failed // Failing asserting 0 matches expected 10 // All pages must have 10 as offset <-- business description // // <Click to see difference> // (and a diff comparator will help us and it will be a great help // for complex objects like objects or jsons)
कुछ लिंटर हमें चेतावनी देते हैं कि क्या हम इस स्थिति को सेट करने के बाद बूलियन के खिलाफ जाँच कर रहे हैं।
हमें इसे और अधिक विशिष्ट जांच में बदलने की जरूरत है।
अपने बुलियन दावे को फिर से लिखने का प्रयास करें और आप विफलताओं को बहुत तेज़ी से ठीक कर देंगे।
कोड गंध 101 - बूलियन के खिलाफ तुलना
Unsplash . पर जोएल डी वीरेन्ड द्वारा फोटो
मैंने अंत में सीखा है कि 'ऊपर की ओर संगत' का क्या अर्थ है। इसका मतलब है कि हमें अपनी सभी पुरानी गलतियों को रखना होगा।
- डेनी वैन टैसेलो
पेशेवर और सार्थक नामों का प्रयोग करें
TL; DR: अनौपचारिक या आक्रामक न हों
हमारे पेशे का एक रचनात्मक पक्ष है।
कभी-कभी हम ऊब जाते हैं और मजाकिया बनने की कोशिश करते हैं।
function erradicateAndMurderAllCustomers(); // unprofessional and offensive
function deleteAllCustomers(); // more declarative and professional
हमारे पास निषिद्ध शब्दों की एक सूची हो सकती है।
हम उन्हें कोड समीक्षाओं में भी देख सकते हैं।
नाम प्रासंगिक हैं, इसलिए स्वचालित लिंटर के लिए यह एक मुश्किल काम होगा।
नामकरण परंपराएं सामान्य होनी चाहिए और इसमें सांस्कृतिक शब्दजाल शामिल नहीं होना चाहिए।
अपने कोड में चीजों को नाम देने के तरीके में पेशेवर बनें।
एक वेरिएबल को एक मूर्खतापूर्ण नाम देकर कॉमेडियन बनने की कोशिश न करें।
आपको प्रोडक्शन कोड लिखना चाहिए ताकि भविष्य के सॉफ्टवेयर डेवलपर्स (यहां तक कि आप भी) आसानी से समझ सकें।
Unsplash . पर स्टीवर्ट मुनरो द्वारा फोटो
यह 'उपयोगकर्ता बेवकूफ हैं, और कार्यक्षमता से भ्रमित हैं' जीनोम की मानसिकता एक बीमारी है। अगर आपको लगता है कि आपके उपयोगकर्ता बेवकूफ हैं, तो केवल बेवकूफ ही इसका इस्तेमाल करेंगे।
- लिनुस टॉर्वाल्ड्स
सॉफ्टवेयर इंजीनियरिंग महान उद्धरण
और अभी के लिए बस इतना ही…
अगला लेख 5 और कोड गंधों की व्याख्या करेगा!