Swift-style-guide: कोष्ठक का विवेकपूर्ण उपयोग अनावश्यक कोष्ठकों को छोड़ने को समाप्त करता है

को निर्मित 14 जून 2017 · 6टिप्पणियाँ · स्रोत: raywenderlich/swift-style-guide

हमने हाल ही में इस स्टाइल गाइड को अपनाने का फैसला किया है, लेकिन निम्नलिखित कथन ने हमें कुछ सिरदर्द दिया:

बड़े भावों में, वैकल्पिक कोष्ठक कभी-कभी कोड को अधिक स्पष्ट रूप से पढ़ सकते हैं।

सटीक होने के लिए, _बड़ा अभिव्यक्ति_ बहुत व्यक्तिपरक है और एक डेवलपर जो सशर्त बयानों के आसपास कोष्ठक रखने के आदी है, वह जोर देगा कि कोष्ठक का उपयोग पठनीयता को बढ़ाएगा। एक न्यूनतम के रूप में, मैं कोष्ठक के किसी भी उपयोग के खिलाफ तर्क दूंगा यदि यह सशर्त कथन के अर्थ को नहीं बदलता है।

कोई विचार?

स्रोत

samkim102

सबसे उपयोगी टिप्पणी

मैं @designatednerd से सहमत हूं। व्यक्तिगत रूप से, मैं अभिव्यक्ति के आसपास कोष्ठक का उपयोग करना भी पसंद करता हूं। मैं भी एक न्यूनतावादी हूं लेकिन मेरा मानना है कि कोड लोगों के लिए पठनीय और स्पष्ट होना चाहिए; अन्यथा, संकलक वास्तव में परवाह नहीं करता है। जिस तरह से मैं इसे देखता हूं वह यह है कि मुझे = बाद एक साधारण असाइनमेंट देखने की उम्मीद है, उदाहरण के लिए let thing = foo । उसके बाद एक कोष्ठक, हालांकि, एक दृश्य संकेत है कि असाइनमेंट कहीं बाद में होता है, शायद पंक्ति के अंत में:

let thing = ( /* some short or long logic here, skip it */ ) ? foo : bar

moayes 14 जून 2017

👍3 ❤1

सभी 6 टिप्पणियाँ

जिन जगहों पर मैंने उन्हें देखा है उनमें से बहुत से यह स्पष्ट कर रहे हैं कि एक समानता जांच का उपयोग एकल बूलियन के रूप में किया जा रहा है:

let thing = thingA == thingB
// vs. 
let thing = (thingA == thingB)

वहां संचालन का क्रम यह स्पष्ट करता है कि thing एक बूलियन है जिसका मूल्य " thingA बराबर होगा thingB , लेकिन इसके साथ दृष्टिगत रूप से पार्स करने में बहुत अधिक समय लगता है दूसरे की तुलना में पहला विकल्प।

यह यौगिक कथनों के साथ भी सहायक होता है, हालांकि कभी-कभी वे संचालन के क्रम को स्पष्ट करने के लिए भी आवश्यक होते हैं:

if thingC && (thingD || thingE) { ...

असल में, यह ज्यादातर स्कैनेबिलिटी के बारे में है: यदि आप इसे पढ़ने के लिए पार्स करने में एक सेकंड भी अधिक समय लेते हैं, तो यह पुराना वास्तविक हो जाता है। और अगर जूनियर डेवलपर्स को यह सोचने में अधिक समय लगता है कि क्या हो रहा है, तो यह आपदा का द्वार खोल सकता है।

designatednerd 14 जून 2017

👍2

let thing = ( /* some short or long logic here, skip it */ ) ? foo : bar

moayes 14 जून 2017

👍3 ❤1

@ samkim102 अगर मैं आपके प्रश्न को सही ढंग से पढ़ता हूं, तो आप उन मामलों के बारे में नहीं पूछ रहे हैं जिन्हें अन्य टिप्पणियों ने संबोधित किया है, बल्कि इसके बजाय, if कथन की स्थिति के आसपास माता-पिता के उपयोग के बारे में पूछ रहे हैं।

अगर ऐसा है, तो कृपया मुझे यह समझने में मदद करें कि कैसे और स्पष्ट रूप से कहा जाए कि उस मामले में माता-पिता का उपयोग नहीं किया जाना चाहिए। गाइड का वर्तमान शब्दांकन मुझे स्पष्ट नहीं लगता।

rcritz 26 अक्तू॰ 2018

अवलोकन: नियम को केवल कोष्ठक का उपयोग करने के लिए कहा जा सकता है जब यह स्पष्टता को बढ़ावा देता है। मेरा मानना है कि मूल दिशानिर्देश को रोकने के लिए वहां रखा गया था:

// go for a Sunday drive
if (day.isSunday) {
   vehicle.drive()
}

दूसरी ओर, यदि आप शामिल अन्य ऑपरेटरों की पूर्वता को जानने के कारण कोष्ठक से दूर हो रहे हैं, तो आप शायद अपने स्वयं के भले के लिए बहुत चतुर हैं।

rayfix 15 नव॰ 2018

समस्या, जैसा कि मैं इसे समझता हूं, यह है कि कुछ लोगों को लगता है कि सभी मामलों में स्पष्टता के लिए माता-पिता की आवश्यकता होती है। स्पष्ट रूप से, if और switch कथनों में अधिकांश मामलों में यह सच नहीं है। असाइनमेंट स्टेटमेंट में उपयोग, जैसा कि अन्य टिप्पणीकारों ने उल्लेख किया है, एक अस्पष्ट दलदल है। "स्पष्टता को बढ़ावा देता है" एक व्यक्तिपरक मानदंड है, जो यहां की स्थिति में मदद नहीं करता है।

यदि मुझे अगले सप्ताह में मूल लेखक से अधिक जानकारी नहीं मिलती है, तो मैं गतिविधि की कमी के कारण इसे बंद करने जा रहा हूँ।

rcritz 18 नव॰ 2018

प्रतिक्रिया के अभाव में बंद कर दिया गया।

rcritz 31 जन॰ 2019

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Swift-style-guide: कोष्ठक का विवेकपूर्ण उपयोग अनावश्यक कोष्ठकों को छोड़ने को समाप्त करता है

सबसे उपयोगी टिप्पणी

सभी 6 टिप्पणियाँ

संबंधित मुद्दों