Swift-style-guide: चर छायांकन कठिन-से-पढ़ने वाले कोड को जन्म दे सकता है।

को निर्मित 15 दिस॰ 2014 · 22टिप्पणियाँ · स्रोत: raywenderlich/swift-style-guide

मुझे लगता है कि हमें अलिखित करते समय छाया चर का उपयोग करने पर अपनी स्थिति पर पुनर्विचार करना चाहिए। हमारा वर्तमान तर्क यह है कि यदि आप गलत चर का उपयोग करने का प्रयास करते हैं तो संकलक आपको सही कर देगा। मुझे लगता है कि उस तर्क में एक मौलिक दोष है जिसे हमने अनदेखा कर दिया है: यह वास्तव में संकलित नहीं होने पर कोड को पढ़ने में काफी कठिन बनाता है।

मैं तीन प्रमुख स्थानों को देखता हूं जहां एक कंपाइलर के बाहर इस तरह के कोड पढ़ने से समस्याएं होती हैं:

स्विफ्ट शुरुआती । एक ही नाम वाली दो चीजों का मौलिक रूप से भिन्न व्यवहार होना बहुत भ्रमित करने वाला है। यह हम में से उन लोगों के लिए विशेष रूप से सच है जो उद्देश्य-सी से आते हैं, जहां एक ही नाम से दो चीजों को परिभाषित करने का प्रयास एक संकलक चेतावनी का कारण बनता है।
कोड समीक्षा । किसी भी व्यक्ति के लिए, जिसे विलय होने से पहले कोड को देखना होता है, यह सुनिश्चित करने के लिए अतिरिक्त स्तर की जांच की आवश्यकता होती है कि "रुको, क्या यह व्यक्ति वैकल्पिक या अलिखित मूल्य निर्दिष्ट करने का प्रयास कर रहा है?"
पुस्तक संपादन । क्या हम अपने सभी पुस्तक संपादकों से अपेक्षा करते हैं कि वे न केवल नमूना कोड बल्कि पुस्तक में टाइप किया गया कोई भी कोड लें और सुनिश्चित करें कि यह संकलित है?

यह उदाहरण लें:

func createNewPerson(name: String?) -> Person {
  let person = Person()
  if let name = name {
    person.name = name
  }
 return person
}

उस कोड को संकलित किए बिना, मुझे कैसे पता चलेगा कि name चर सेट किया जा रहा है जो पास-इन वैकल्पिक के बजाय अलिखित है?

इसी तरह की स्थिति में मैं अपने स्विफ्ट कोड में यही कर रहा हूं:

func createNewPerson(name: String?) -> Person {
  let person = Person()
  if let unwrappedName = name {
    person.name = unwrappedName
  }
 return person
}

मेरे लिए, केवल unwrapped को अलिखित चर नाम में जोड़ने से कोड का प्रवाह काफी स्पष्ट हो जाता है। हमें उस सटीक सिंटैक्स का उपयोग करने की आवश्यकता नहीं है (विशेषकर चूंकि यह चर नामों को इतना लंबा बनाता है), लेकिन मुझे लगता है कि हमें इस कारण से छायांकन चर पर पुनर्विचार करना चाहिए।

ठीक है, अब जब मैंने अपना मामला बना लिया है: फाइट फाइट फाइट फाइट फाइट!

1tpffru

स्रोत

designatednerd

👍3

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

मेरे लिए, कोड समीक्षा के दौरान ! देखना लाल झंडा है। तभी मैं पूछना शुरू करता हूं "हमने वैकल्पिक रूप से इस चीज़ को क्यों नहीं बांधा?"

मुझे किताबों के लिए उपसर्ग के बहुत लंबे समय तक "अनकैप्ड" होने की चिंता है, लाइन रैपिंग को कम से कम रखना बहुत मुश्किल है, और यह बहुत अधिक क्षैतिज स्थान का उपयोग किया जाता है। जहां तक पठनीयता आईएमओ जाती है, किताबों में कोड की लाइन रैपिंग यकीनन बदतर है। बेशक यह उदाहरण लाइन रैपिंग से ग्रस्त नहीं होगा, लेकिन कोको एपीआई कॉल में फेंक देगा और यह एक अलग कहानी होगी।

छायांकन पर मेरा रुख शायद मामले और दिन-ब-दिन अलग-अलग होगा:]

cwagdev 15 दिस॰ 2014

👍1

उस कोड को संकलित किए बिना, मुझे कैसे पता चलेगा कि नाम चर सेट किया जा रहा है जो पास-इन वैकल्पिक के बजाय अलिखित है?

क्योंकि स्विफ्ट इसी तरह काम करती है। यदि आप if let के दायरे में हैं, तो यह अलिखित संस्करण का उपयोग करता है। यहां कोई अस्पष्टता नहीं है।

hollance 15 दिस॰ 2014

👍1

@ होलेंस : स्विफ्ट को अच्छी तरह से जानने वाले किसी व्यक्ति के लिए कोई अस्पष्टता नहीं है, और संकलित होने पर कोई अस्पष्टता नहीं है। किसी ऐसे व्यक्ति के लिए जो इसे कम अच्छी तरह जानता है (उदाहरण के लिए: मुझे) और कोड को बिना जांचे और संकलित किए पढ़ने की कोशिश कर रहा है, चर छायांकन प्रवाह को काफी कम स्पष्ट करता है।

@cwagdev शायद अलिखित के बजाय केवल u के साथ उपसर्ग करें? काम पर हमारे एंड्रॉइड कोड मानकों को उपसर्ग के रूप में a के तर्क के रूप में पारित किसी भी चर की आवश्यकता होती है, और यह स्पष्टता और परिवर्तनीय लंबाई के बीच एक बहुत ही ठोस समझौता रहा है।

designatednerd 15 दिस॰ 2014

मुझे लगता है कि यह वह जगह है जहाँ सिमेंटिक कोड हाइलाइटिंग काम आता है। ;-)

वैसे, क्या आप जानते हैं कि if var भी अनरैपिंग का काम करता है?

  if var name = name {
    name += ", Esq."
    person.name = name
  }

hollance 16 दिस॰ 2014

@ होलेंस यह निश्चित रूप से मदद करता है यदि आप जिस वैकल्पिक को खोल रहे हैं वह एक स्थानीय संपत्ति है, लेकिन अगर यह एक पारित तर्क है तो बहुत कुछ नहीं करता है।

जहां तक if var : https://www.youtube.com/watch?v=Cd7tEsAuspA - धन्यवाद!

designatednerd 16 दिस॰ 2014

सिमेंटिक हाइलाइटिंग बनाम रेगुलर सिंटैक्स हाइलाइटिंग के बारे में बात यह है कि यह प्रत्येक वेरिएबल को अपना रंग देता है। तो आप एक नज़र में देख पाएंगे कि अलिखित name पैरामीटर name से अलग है।

इसके लिए एक एक्सकोड प्लग-इन है, लेकिन मुझे नहीं पता कि यह स्विफ्ट के साथ काम करता है या नहीं। https://github.com/kolinkrewinkel/Polychromatic

hollance 16 दिस॰ 2014

मैं किसी भी नए चर या निरंतर उपसर्गों को पेश करने का कड़ा विरोध करता हूं। हंगेरियन नोटेशन लगभग समाप्त हो गया है, इसे पुनर्जीवित करने का कोई अच्छा कारण नहीं है!

मैं सहमत हूं कि हमें कार्यक्षेत्र और संदर्भ के बारे में संकेत देने के लिए विकास उपकरणों पर भरोसा करना चाहिए।

ColinEberhardt 16 दिस॰ 2014

मुझे निश्चित रूप से यह तर्क मिलता है कि संकलित वातावरण में, यह आवश्यक नहीं है - इसलिए इस नियम को पहली जगह में अपनाया गया था।

समस्या यह है कि हमारा कोड अक्सर संकलित वातावरण के बाहर पढ़ा जाता है, चाहे वह वेबसाइट पर हो या किताबों में। यदि आप गलत गैर-वैकल्पिक बनाम वैकल्पिक var या let का उपयोग करने का प्रयास करते हैं तो यह प्रक्रिया संकलक बारफिंग की सहायता के बिना _महत्वपूर्ण रूप से कम स्पष्ट हो जाती है।

@ColinEberhardt और @hollance : क्या आपके पास कोई अन्य सुझाव है कि हम इन चीजों को एक चर उपसर्ग का उपयोग किए बिना केवल-पढ़ने के लिए बेहतर संदर्भ कैसे दे सकते हैं? या हमें बस इतना कहना चाहिए, "इसे पेंच करो, अगर आपको यह नहीं मिलता है तो इसे खेल के मैदान में टाइप करें।"?

designatednerd 18 दिस॰ 2014

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

jawwad 1 अप्रैल 2015

मुझे @jawwad की व्याख्या पसंद है कि छायांकन वास्तव में "खुद को छायांकन" कर रहा है, इसलिए उसी नाम का उपयोग करना समझ में आता है।

आप दूसरे पक्ष से भी बहस कर सकते हैं: यदि आपके पास foo और unwrappedFoo था और फिर आपने unwrappedFoo पर कुछ विधि कहा, तो संभव है कि लोग भ्रमित हो सकते हैं कि ये दो अलग-अलग चीजें हैं। और उस foo को छुआ नहीं गया था। वे इसे अंततः तब समझेंगे जब वे वैकल्पिक को समझेंगे, लेकिन छायांकन के मामले में भी यही स्थिति है।

किसी भी तरह से, हमें अंततः "इसे प्राप्त करने" वाले लोगों पर भरोसा करने की आवश्यकता होगी और यदि ऐसा है - तो मैं वैकल्पिक को समझने वाले लोगों की स्थिति के लिए अनुकूलित करना चाहूंगा।

हालांकि चर्चा जारी रखें! हो सकता है कि हम ivars बनाम properties पर ऑब्जेक्टिव-सी स्टाइल गाइड चर्चा के लिए पोस्ट काउंट को हरा सकें!

gregheo 9 अप्रैल 2015

स्वयं भगवान की ओर से आने वाला एक संभावित तूफान, https://devforums.apple.com/message/1127586#1127586

cwagdev 20 अप्रैल 2015

मुझे लगता है कि पोस्ट और अधिक है कि क्या परिवर्तनीय छायांकन को चेतावनी फेंकनी चाहिए - लेटेनर कहते हैं कि नहीं और इस पर कोई विशिष्ट मार्गदर्शन नहीं है कि आपको स्टाइलिस्टिक रूप से छाया करना चाहिए या नहीं।

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

यह मेरे लिए क्या नीचे आता है यह पुराना शाहबलूत है:

Programs must be written for people to read, 
and only incidentally for machines to execute.

हां, जब आप वास्तव में कोड लिख रहे होते हैं तो संकलक आपको बताएगा कि आप कब खराब हो रहे हैं। लेकिन परिवर्तनीय छायांकन के साथ दूसरों के (या यहां तक कि मेरा अपना) कोड पढ़ना मेरे लिए काफी कठिन हो जाता है। जब मैं छायांकित कोड पढ़ रहा होता हूं, तो मुझे यह पता लगाने में बहुत कठिन समय लगता है कि कोई व्यक्ति अलिखित मूल्य बनाम लिपटे हुए मूल्य तक पहुंच रहा है।

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

जिस चीज़ को आप खोल रहे हैं और जो चीज़ अलिखित है, जो आसानी से पढ़ी जा सकती है, के बीच एक स्पष्ट चित्रण होने से नोब्स के लिए यह बताना बहुत आसान हो जाएगा कि वे दोनों में से किस तक पहुँच बना रहे हैं।

और मुझे पता है कि यह सुनकर @ColinEberhardt को बहुत दुख होगा, लेकिन मैंने अपने व्यक्तिगत कोड पर u उपसर्ग को अपनाया है और मैंने पाया है कि यह काफी मदद करता है।

designatednerd 20 अप्रैल 2015

मुझे नहीं लगता कि लाएटनर यहां किसी तरह की सलाह देते हैं... वह सिर्फ इतना कहते हैं कि कोई चेतावनी नहीं होगी।

ऐसा लगता है कि वह कह रहा है "अगर आप वास्तव में चाहते हैं तो इसे करें" ...:]

JRG-Developer 20 अप्रैल 2015

सहमत, मैं मुख्य रूप से व्यंग्यात्मक था और धागे ने मुझे इसकी याद दिला दी: मुस्कान:

मैं अभी भी छाया शिविर में हूं लेकिन @designatednerd की बात देख सकता हूं।

cwagdev 20 अप्रैल 2015

@designatednerd शैडोइंग सिर्फ नटखट है। यह आसानी से समझने योग्य तथ्य है कि if let स्कोप के अंदर, आप अलिखित संस्करण की बात कर रहे हैं। स्पष्ट रूप से खोलना इतना सामान्य है कि स्विफ्ट के साथ कुछ दिनों के अनुभव के लायक कोई भी व्यक्ति इसे पहले से ही जानता है।

aminiz 21 जुल॰ 2015

@annehiro मैं इस आकलन से असहमत हूं "स्विफ्ट के साथ कुछ दिनों के अनुभव के लायक कोई भी व्यक्ति पहले से ही यह जानता है।" स्विफ्ट _और_ बहुत सारे अन्य प्रोग्रामिंग अनुभव वाले कुछ दिनों के अनुभव वाले किसी भी व्यक्ति को इसे प्राप्त होने की संभावना है, क्योंकि वे स्कोपिंग को समझते हैं। मैंने ऊपर विस्तार से बताया कि मुझे क्यों लगता है कि यह उन n00bs के लिए कठिन बना देता है जो वास्तव में समझने की गुंजाइश नहीं रखते हैं।

हालाँकि, @gregheo , मुझे नहीं पता कि क्या यह मुद्दा अब खुला छोड़ने लायक है। जबकि मुझे अभी भी ठीक वैसा ही लगता है जैसा कि इस मुद्दे का शीर्षक कहता है (और अभी भी अपने कोड में गैर-छायांकित चर का उपयोग कर रहा हूं), साइट स्तर पर यह परिवर्तन करने के लिए इस बिंदु पर साइट और पुस्तकों को अद्यतन करने के लिए एक पागल राशि की आवश्यकता होगी।

कोड मानकों के इस सेट का उपयोग कई कार्यस्थलों के लिए एक संदर्भ के रूप में किया जाता है जो अभी भी अपने स्वयं के स्विफ्ट कोड मानकों (मेरे सहित) को विकसित कर रहे हैं, लेकिन अंततः, ये हमारी साइट और पुस्तकों के लिए हैं। और मुझे लगता है कि घोड़े ने खलिहान छोड़ दिया है और इस बिंदु पर आधे देश में ट्यूटोरियल और किताबें बदलते हुए दौड़ रहा है। :घुड़दौड़:

designatednerd 21 जुल॰ 2015

एफडब्ल्यूआईडब्ल्यू मैंने स्विफ्ट के बारे में काफी कुछ लिखा है क्योंकि यह आया है और मैं कहूंगा कि मैं 90% समय छाया करता हूं, मैं छायांकन छोड़ देता हूं जब चर अत्यंत वर्बोज़ होता है।

cwagdev 21 जुल॰ 2015

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

func compute(a: Int?, b: Int?) -> {
   unwrap a, b else { return }
   // compute with a and b Ints
}

Unwrap पौराणिक Result प्रकार के साथ भी काम करेगा।

कई बार ऐसा होता है कि एक ही नाम का नहीं बल्कि एक संक्षिप्त रूप का उपयोग करना समझ में आता है। उदाहरण के लिए, सिएस्टा ढांचे से आ रहा है (जिसे मैं वास्तव में महान कोड मॉड्यूलो इसकी अजीब सफेद जगह मानता हूं):

guard let cache = config.persistentCache else { return }

दूसरी बार यह सिर्फ छाया है।

मुझे लगता है कि @cwagdev मिल रहा है। मैंने जिन कुछ अन्य परियोजनाओं की जाँच की, उनमें अल्मोफ़ायर और ऐप्पल के फाउंडेशन के ओपन सोर्स कार्यान्वयन सहित शैडोइंग और नॉन-शैडोइंग का मिश्रण था। हालांकि, इनमें से किसी भी परियोजना ने हंगेरियन संकेतन का उपयोग नहीं किया।

इन निष्कर्षों और अपनी व्यक्तिगत आंत के आधार पर मैं यह शासन करने जा रहा हूं कि अभी के लिए छाया के बारे में कोई मानक नहीं बनाया जाना चाहिए या छाया नहीं होना चाहिए। इस मुद्दे को बंद करना लेकिन अगर परिदृश्य बदलता है तो हम इसे फिर से देख सकते हैं।

rayfix 8 अप्रैल 2016

@rayfix मैं भी इस मुद्दे को बंद करने के लिए हूं।

हालांकि, के बारे में

मैं शासन करने जा रहा हूं कि अभी के लिए छाया के बारे में कोई मानक नहीं बनाया जाना चाहिए और न ही छाया के लिए।

दरअसल, स्टाइल गाइड का पहले से ही इस पर फैसला है:

वैकल्पिक बाइंडिंग के लिए, अलिखित दृश्य या वास्तविक लेबल जैसे नामों का उपयोग करने के बजाय उपयुक्त होने पर मूल नाम को छायांकित करें।

जब इस मुद्दे को खोला गया था, तो हमारे बहुत सारे कोड या ट्यूटोरियल नहीं थे जो "छाया" का उपयोग करते थे।

अब, हालांकि, एक अलग कहानी है:

हमने इसे कई लिखित और वीडियो ट्यूटोरियल में इस्तेमाल किया है।
हमने इसे RWDevCon 2015 और 2016 में इस्तेमाल किया और समझाया।
कुल मिलाकर, हमने मूल नाम को "छाया" करने के विचार का अनिवार्य रूप से समर्थन किया है।

इस बिंदु पर, मुझे लगता है कि हम इसके लिए प्रतिबद्ध हैं... निजी तौर पर, मैं भी इसे पसंद करने लगा हूं...

ठीक की तरह, यह आप पर बढ़ता है? मैं

JRG-Developer 8 अप्रैल 2016

मेरे लिए वह कहता है, "हंगेरियन नोटेशन का उपयोग न करें" जो मैं पूरी तरह से बोर्ड पर हूं। "जब उपयुक्त हो" चीजों के लिए थोड़ा झालरदार जगह देता है:

guard let json = content as? NSDictionary else { throw InvalidJSON }

rayfix 8 अप्रैल 2016

एफडब्ल्यूआईडब्ल्यू, मैंने u का उपयोग करना बंद कर दिया और बस विभिन्न चर नामों का उपयोग करके घायल हो गया, लेकिन मुझे एहसास है कि मैं यह लड़ाई हार गया हूं। :मुस्कुराओ:

designatednerd 8 अप्रैल 2016

@designatednerd किसी नए व्यक्ति के रूप में तेजी से, मुझे लगता है कि आप इसमें बिल्कुल सही थे। यह शुरुआती लोगों के लिए भ्रमित करने वाला है। मैं वास्तव में उलझन में था कि स्कोपिंग ने इसके साथ कैसे काम किया।

rvail2 9 जून 2016

👍1

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

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

Swift-style-guide: चर छायांकन कठिन-से-पढ़ने वाले कोड को जन्म दे सकता है।

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

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