4 अभिव्यक्तियों के साथ टर्नरी ऑपरेटर का उपयोग

Question

क्या यह स्वीकार्य कोडिंग अभ्यास है?

public class MessageFormat { 
    private static final Color DEFAULT_COLOR = Color.RED; 

    private Color messageColor = DEFAULT_COLOR; 

    public MessageFormat(Person person) { 
     Color color = person.getPreferredColor(); 
     messageColor = (color != null) ? color : messageColor; // this line 
    } 
} 

या मैं बेहतर बंद क्लासिक के साथ जा रहा हूँ ...

if (color != null) { 
    messageColor = color; 
} 

Answer 1

का उपयोग करें? ऑपरेटर कोड को और अधिक पठनीय बनाने के लिए सीमित होना चाहिए। एक उत्कृष्ट उदाहरण:

a = sprintf("There are %i green bottle%s on the wall.", i, (i==1?"":"s")); 

इस मामले में कोड अगर आप इसके बारे 5 यदि/बाकी लाइनों में तोड़ दिया कम से पढ़े जा सकेंगे।

मैं आम तौर पर पूरे ऑपरेटर के चारों ओर ब्रैकेट डालता हूं ताकि इसे पढ़ने पर मैं मानसिक रूप से इसे एक मान के रूप में पार्स कर सकूं।

messageColor = (color != null ? color : messageColor); 

एक और प्रकार

messageColor = color || messageColor; 

कौन सा कुछ भाषाओं में मूल्यांकन करेंगे है करने के लिए "रंग, जब तक रंग का मूल्यांकन" गलत "है, जो messageColor के मामले मूल्य में। मेरी राय में इस के रूप में बचा जाना चाहिए यह लोगों को भ्रमित कर सकते हैं।

सबसे महत्वपूर्ण बात तो अगले व्यक्ति अपने कोड को पढ़ने के (भले ही आप है) कम से कम संज्ञानात्मक भूमि के ऊपर है अनुरूप होना है।

Answer 2

मुझे (मैं पायथन के त्रिगुट ऑपरेटर एक बहुत का उपयोग करें) के लिए ठीक लग रहा है, लेकिन शैली मुद्दा इस तरह आम तौर पर बहुत ही व्यक्तिपरक है । अगर प्रोजेक्ट में कोडिंग स्टाइल दस्तावेज़ है, तो आप इसे देखना चाहेंगे।

Answer 3

मैं दूसरा पसंद करता हूं क्योंकि यह आपके स्पष्ट अर्थ को स्पष्ट रूप से व्यक्त करता है: यदि आप शून्य नहीं हैं तो आप केवल रंग बदलना चाहते हैं। पहली विधि यह इतना स्पष्ट नहीं बनाती है।

Answer 4

टर्नरी ऑपरेटर का उपयोग अक्सर अन्य कोडिंग मानकों के साथ एक संवेदनशील समस्या होता है। इसका उपयोग शायद आपकी साइट पर कोडिंग मानकों द्वारा निर्धारित किया जाता है।

हालांकि, इस विशिष्ट स्थिति में मैं निश्चित रूप से दूसरे विकल्प की सिफारिश करता हूं; न केवल यह अधिक स्पष्ट है, लेकिन टर्नरी ऑपरेटर का उपयोग यहां पूरी तरह से अनावश्यक है। संदेश को स्वयं को असाइन करने की कोई आवश्यकता नहीं है, इसलिए इस विशेष स्थिति में टर्नरी ऑपरेटर का एकमात्र फ़ंक्शन कोड obfuscation है।

Answer 5

टर्नरी ऑपरेटर अक्सर दुर्व्यवहार करते हैं क्योंकि उनके द्वारा उत्पादित कोड चालाक और कॉम्पैक्ट लगता है।

वास्तव में वे कोड को कम पठनीय और अधिक त्रुटि प्रवण बनाते हैं। जब भी संभव हो यह उचित है

if (<condition>) { 
    <action> ; 
} 

एक त्रिगुट वाक्य रचना के बजाय

की लंबी संस्करण का उपयोग करने के लिए।

Answer 6

सी प्रोग्रामर के बीच टर्नरी ऑपरेटर अधिक आम है। सी में यदि आप नियंत्रण संरचनाओं से बचते हैं तो आप अक्सर बेहतर पाइपलाइनिंग प्राप्त कर सकते हैं, क्योंकि गलत होने के लिए कोई शाखा पूर्वानुमान नहीं है। मुझे संदेह है कि आप जावा में कोई प्रदर्शन अंतर देखेंगे, और if-null-then-असाइन पैटर्न टर्नरी से कहीं अधिक आम है। हालांकि, यदि आप मौजूदा कोडबेस बनाए रखते हैं, तो मौजूदा कोड के अनुरूप रहने के लिए आमतौर पर सबसे अच्छा होता है।

यदि आप इसे स्वयं कर रहे हैं, तो आप defaultIfNull, firstNonNull या coalesce फ़ंक्शन लिख सकते हैं जो कोड को और भी संक्षिप्त बना सकता है। Apache Commons Lang includes a defaultIfNull function.

कुछ भाषाओं में ||= ऑपरेटर शामिल है, जो उन भाषाओं में डिफ़ॉल्ट मानों के लिए सामान्य मुहावरे है।

Answer 7

आपके मामले में, मैं 'क्लासिक' कार्यान्वयन पसंद करूंगा, क्योंकि मेरे लिए यह समझना तेज़ है कि अगर आप व्यक्ति को पसंदीदा पसंद करते हैं तो आप केवल एक नया रंग उपयोग करना चाहते हैं।

मैं कभी कभी विधि में इसका इस्तेमाल कॉल अगर मैं NPEs से बचना चाहते हैं, लेकिन मैं आमतौर पर अगले refactorings में से एक में कोड के उन बदसूरत टुकड़े elimate;)

Answer 8

पठनीयता, समझ आदि में आसानी में ही कर रहे हैं इस मामले (मेरा मतलब है, आओ ...)। मुझे पहले उदाहरण में नकल और स्पष्ट आत्म असाइनमेंट पसंद नहीं है; यह कुछ ऐसा अनुवाद करेगा:

if (colour != null) {messageColour = colour;} 
    else {messageColour = messageColour;}; 

जो थोड़ा बेवकूफ है।

मैं आमतौर पर एक पंक्ति में दूसरा लिखता हूं, लेकिन यह व्यक्तिगत फैंसी रेस का सवाल है। कोडिंग शैली दिशा निर्देशों:

if (colour != null) {messageColour = colour;}; 

संपादित आप देख रहे हैं के बाद से सर्वोत्तम प्रथाओं के लिए (अब मैं कर रहा हूँ 8 साल पहले की तुलना में अधिक स्वच्छंद)

:

// Use default visibility by default, especially in examples. 
// Public needs a reason. 
class MessageFormat { 
    static final Color DEFAULT_COLOR = Color.RED; 

    // Strongly prefer final fields. 
    private final Color messageColor; 

    // Protect parameters and variables against abuse by other Java developers 
    MessageFormat (final Person person) { 
     // Use Optionals; null is a code smell 
     final Optional<Color> preferredColor = person.getPreferredColor(); 
     // Bask in the clarity of the message 
     this.messageColor = preferredColor.orElse(DEFAULT_COLOR); 
    } 
}