एक अतिरिक्त चर होने की लागत क्या है? अधिकांश भाषाओं में, संकलित और व्याख्यायित दोनों भाषाओं में कोई नहीं।
इसका क्या फायदा है?
इसी तरह से एक अलग विधि के लिए गुप्त बूलियन अभिव्यक्ति निकालने के लिए, आप डुप्लिकेट कोड के जोखिम को कम कर रहे हैं , लेकिन एक अलग विधि के मामले में थोड़ा कम है। यदि सशर्त अभिव्यक्ति को स्वयं विधि के अंदर पुन: उपयोग किया जाता है, तो आप चर का पुन: उपयोग करने में सक्षम होंगे; यदि अभिव्यक्ति एक अलग विधि में प्रकट होती है, तो आप नहीं करेंगे।
ध्यान दें कि जब तक आपकी प्रोग्रामिंग भाषा आपको अपरिवर्तनीय स्थानीय चर रखने की अनुमति नहीं देती है या आपके पास स्टाइल-वार करने का एक तरीका है, कि कोई भी चर पुन: असाइन नहीं किया जाता है, तो दीर्घकालिक रूप से इस तरह के रिफैक्टिंग जोखिम भरे हो सकते हैं। यदि चर का मान बदल गया है, तो कोड के बारे में तर्क करना बहुत मुश्किल हो सकता है।
आप कोड के साथ सिंक से बाहर निकलने के प्रलेखन के जोखिम को कम कर रहे हैं । डेवलपर्स टिप्पणियों से अधिक आसानी से चर और विधियों के नाम अपडेट करते हैं। इस प्रकार, कोड को देखना असामान्य नहीं है जैसे:
// Find if the user is an actual author in order to allow her to edit the message.
if (currentUser.isAdministrator || (message.author == currentUser && !message.locked))
अभिव्यक्ति संभवतः के साथ शुरू हुई if (message.author == currentUser), और फिर लॉक किए गए संदेशों और प्रशासकों के मामले को संभालने के लिए विकसित हुई, जिन्हें लेखक होने की ज़रूरत नहीं है और बंद सामान के बारे में परवाह नहीं है; हालाँकि, टिप्पणी में उन परिवर्तनों में से कोई भी प्रतिबिंबित नहीं हुआ है।
दोनों लाभ विशेष रूप से महत्वपूर्ण नहीं हैं, लेकिन अतिरिक्त चर की कम लागत को देखते हुए, आप वास्तव में उनका उपयोग करने पर विचार कर सकते हैं।
ध्यान दें कि यदि आपकी बूलियन अभिव्यक्ति अत्यधिक जटिल हो जाती है: ool
- इसे एक अलग विधि से निकालें , और:
- इसे कई सरल बूलियन अभिव्यक्तियों में प्रतिबिंबित करें।
ऊपर दिया गया उदाहरण है:
class Message
{
...
public boolean canBeEditedBy(User user)
{
...
if (user.isAdministrator) {
return true;
}
return this.author == user && !this.locked;
}
}
...
if (message.canBeEditedBy(currentUser)) // See? Much more readable now!
{
...
}
¹ स्रोत: ज्यादातर व्यावसायिक सॉफ्टवेयर विकसित करने वाले मेरे साथियों का मेरा अपना अवलोकन; YMMV। एक वास्तविक शोध अलग-अलग परिणाम दिखा सकता है। व्यक्तिगत रूप से, मुझे लगता है कि जब डेवलपर्स कोड पढ़ते हैं, तो वे कोड पर ध्यान केंद्रित कर रहे हैं , और टिप्पणियां दस्तावेज हैं, कोड नहीं; इसलिए, वे आमतौर पर टिप्पणियों को नहीं पढ़ते हैं, इसलिए उन्हें उनसे अपडेट करने की उम्मीद करना मुश्किल होगा।
Simple अत्यधिक जटिल सीमा को एक सरल सूत्र के साथ परिभाषित किया गया है: यदि आपके कोड की समीक्षा करने वाले आधे डेवलपर्स आपकी हत्या का इरादा व्यक्त करते हैं, तो दहलीज तक पहुंच जाती है। ऊपर बूलियन अभिव्यक्ति काफी सरल है, जिसे पुन: निर्माण करने की आवश्यकता होती है; हालाँकि, एक पंक्ति में चार भाग if ((a && b) || (c && d))इसे संभावित रूप से परिष्कृत कर सकते हैं। ध्यान दें कि यदि अभिव्यक्ति समतल है, तो भागों की संख्या ज्यादातर अप्रासंगिक है: if (a || b || c || d || ... || z)पर्याप्त पठनीय है।