Swift-style-guide: गार्ड स्टेटमेंट स्टाइलिंग

को निर्मित 13 सित॰ 2016 · 9टिप्पणियाँ · स्रोत: raywenderlich/swift-style-guide

नमस्ते,

मुझे बहुत सारे असंगत guard स्टेटमेंट दिखाई दे रहे हैं। क्या हम स्टाइलगाइड में guard स्टेटमेंट के लिए एक सेक्शन जोड़ सकते हैं?

सुझाव:

एक कथन:

guard let name = json["name"] as? String else {
    return nil
}

बहु कथन:

guard let name = json["name"] as? String,
    let coordinatesJSON = json["coordinates"] as? [String: Double],
    let latitude = coordinatesJSON["lat"],
    let longitude = coordinatesJSON["lng"],
    let mealsJSON = json["meals"] as? [String]
else {
    return nil
}

स्रोत

gokselkoksal

👍4

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

मैंने ऐप्पल से शुरुआती प्रारूप उधार लिया लेकिन फिर मैंने अपनी कोड शैली भी बदल दी। यदि आप तुरंत लौट रहे हैं तो वन-लाइनर का उपयोग करना उचित है।

यहाँ नया संस्करण है:

एकल:

guard let name = json["name"] as? String else { return nil }

बहु:

guard let name = json["name"] as? String,
    let coordinatesJSON = json["coordinates"] as? [String: Double],
    let latitude = coordinatesJSON["lat"],
    let longitude = coordinatesJSON["lng"],
    let mealsJSON = json["meals"] as? [String]
else { return nil }

मुझे लगता है कि else कई let s होने पर अपनी लाइन के योग्य है।

gokselkoksal 23 नव॰ 2016

👍11 👎2

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

मुझे यह सुझाव पसंद है.... मॉड्यूल 2-स्पेस 4-स्पेस इंडेंटेशन:]

rayfix 14 सित॰ 2016

इसके बारे में दूसरे विचार करना शुरू करें। मैंने पुस्तकालयों के लेखकों से बहुत सारे स्विफ्ट कोड देखे हैं कि मैं वास्तव में एक लाइनर के रूप में गार्ड करने की प्रशंसा करता हूं। कोई विचार @ जेआरजी-डेवलपर @eskerber @jawwad @gregheo ?

संभावित समझौता: उपरोक्त प्रारूप का उपयोग करके सभी उदाहरण दिखाएं लेकिन उस पर कानून न बनाएं।

rayfix 23 नव॰ 2016

यहाँ मेरे विचार हैं:

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

guard let strongSelf = self else { return nil }

मेरा तर्क यह है कि विधि का मुख्य उद्देश्य जो कुछ भी है उसके लिए यह _not_ आम तौर पर महत्वपूर्ण है। ज़रूर, यह निश्चित रूप से वहाँ होना आवश्यक है, लेकिन मुझे नहीं लगता कि इस तरह के साधारण गार्ड पर तीन लाइनें बर्बाद करना सार्थक है।

यह प्रिंट, वेब आदि में टेक्स्ट को थोड़ा छोटा करने में भी मदद करता है, जो एक प्लस है।

मल्टी-स्टेटमेंट गार्ड के लिए, मैं इसे पसंद करता हूं:

guard let name = json["name"] as? String,
  let coordinatesJSON = json["coordinates"] as? [String: Double],
  let latitude = coordinatesJSON["lat"],
  let longitude = coordinatesJSON["lng"],
  let mealsJSON = json["meals"] as? [String] else { return nil }

यहां अंतर else को पिछले अरैपिंग के समान लाइन पर रखने का है।
तर्क वही है: यह अपेक्षित पथ नहीं है, और यह स्थान बर्बाद करने के लायक नहीं है।

JRG-Developer 23 नव॰ 2016

👍4

यहाँ नया संस्करण है:

एकल:

guard let name = json["name"] as? String else { return nil }

बहु:

guard let name = json["name"] as? String,
    let coordinatesJSON = json["coordinates"] as? [String: Double],
    let latitude = coordinatesJSON["lat"],
    let longitude = coordinatesJSON["lng"],
    let mealsJSON = json["meals"] as? [String]
else { return nil }

मुझे लगता है कि else कई let s होने पर अपनी लाइन के योग्य है।

gokselkoksal 23 नव॰ 2016

👍11 👎2

इसे एक लाइन पर रखने से आप विफलता केस नंबर पर ब्रेकपॉइंट लगाने से रोक सकते हैं?

rayfix 24 नव॰ 2016

@rayfix हाँ , आप ऐसा नहीं कर सकते... _(ツ)_/¯

gokselkoksal 24 नव॰ 2016

मैंने इन दोनों शैलियों को आजमाया और उपयोग किया है और मेरी वरीयता भी एक पंक्ति विकल्प के रूप में समाप्त हो गई है। मेरी राय में, अधिक संक्षिप्त और पठनीय कोड होने से कोई नुकसान नहीं होता है।

हालांकि मैं देख सकता हूं कि असहमत लोग कहां से आ रहे हैं। समस्या के अलावा @rayfix ने उल्लेख किया है, मुझे दो अन्य डाउनसाइड दिखाई देते हैं।

कभी-कभी वे अपेक्षाकृत लंबे हो जाते हैं, इसलिए उन्हें कम पठनीय बना दिया जाता है। (मुझे यकीन है कि मुझे और अधिक चरम उदाहरण मिल सकते हैं):

एकाधिक पंक्तियाँ:

guard let meal = Meal(rawValue: string) else {
    throw SerializationError.invalid("meals", string)
}

एक पंक्ति:

guard let meal = Meal(rawValue: string) else { throw SerializationError.invalid("meals", string) }

दूसरी समस्या सिर्फ एकरूपता है। उदाहरण के लिए मैं कभी भी एक पंक्ति if शर्त नहीं करूँगा।

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

RobertGummesson 24 नव॰ 2016

मेरा झुकाव यह है कि इस पर कोई कठोर नियम नहीं है। हो सकता है कि हमें इस बारे में स्पष्ट होना चाहिए कि जिस तरह से हम क्लोजर चेनिंग के साथ थे।

स्पेसिंग, लाइन ब्रेक, और नामांकित बनाम अनाम तर्कों का उपयोग कब करना है, इस पर निर्णय लेखक के विवेक पर छोड़ दिया जाता है।

rayfix 24 नव॰ 2016

मैंने स्विफ्ट स्टैंडर्ड लाइब्रेरी, अल्मोफायर, अनबॉक्स, स्विफ्टीजसन, स्प्रिंग सहित कुछ उच्च तारांकित स्विफ्ट पुस्तकालयों का अनौपचारिक सर्वेक्षण किया। कोई वास्तविक आम सहमति नहीं है जो मुझे मिल सकती है। वे सभी मुझे अपने संदर्भ में बहुत अच्छे लगते हैं।

यहां तक कि https://developer.apple.com/swift/blog/?id=37 से Apple JSON उदाहरण में भी उन्होंने else को एक ही फ़ंक्शन में अलग-अलग स्थानों पर रखा है! इसका मतलब यह नहीं है कि यह बुरा लग रहा है। यह वास्तव में मेरी आंखों को अच्छा लगता है।

इसलिए मुझे लगता है कि मैं भाषा की अनुमति देने वाले लचीलेपन को अपनाने की इच्छा के शिविर में पड़ रहा हूं। मुझे लगता है कि यह कुछ स्थिरता की कीमत पर पठनीयता (स्पष्टता) का पक्षधर है।

मैं गलत हो सकता था, लेकिन मैं इस मुद्दे पर रिलीज को रोकना नहीं चाहता। मेरा लक्ष्य है कि सोमवार को टीम द्वारा दस्तावेज़ की समीक्षा की जाए ताकि गुरुवार को इसे मर्ज किया जा सके। अगर आप अपील करना चाहते हैं तो मैं इसके साथ पूरी तरह से शांत हूं! कृपया अपना मामला बताएं (यहां) और मैं इसे अंतिम निर्णय लेने के लिए टीम लीड्स को भेजूंगा।

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

rayfix 25 नव॰ 2016

👍3

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

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

Swift-style-guide: गार्ड स्टेटमेंट स्टाइलिंग

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

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

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