यह लेख गो कोड लिखने के लिए सर्वोत्तम प्रथाओं पर केंद्रित है। यह प्रस्तुति की शैली में बना है, लेकिन सामान्य स्लाइड के बिना। हम संक्षेप में और स्पष्ट रूप से प्रत्येक आइटम के माध्यम से जाने की कोशिश करेंगे।

पहले आपको इस बात पर सहमत होने की आवश्यकता है कि प्रोग्रामिंग भाषा के लिए सर्वोत्तम अभ्यास क्या हैं। यहाँ आप गो के तकनीकी निदेशक, रस कॉक्स के शब्दों को याद कर सकते हैं:

यदि आप समय कारक और अन्य प्रोग्रामर को जोड़ते हैं, तो सॉफ्टवेयर इंजीनियरिंग प्रोग्रामिंग के लिए क्या होता है।

इस प्रकार, रस प्रोग्रामिंग और सॉफ्टवेयर इंजीनियरिंग की अवधारणाओं के बीच अंतर करता है। पहले मामले में, आप अपने लिए एक कार्यक्रम लिखते हैं, दूसरे में आप एक उत्पाद बनाते हैं जो अन्य प्रोग्रामर समय के साथ काम करेंगे। इंजीनियर आते हैं और चले जाते हैं। टीमें बढ़ती या सिकुड़ती हैं। नई सुविधाएँ जोड़ी गई हैं और बग्स तय किए गए हैं। यह सॉफ्टवेयर विकास की प्रकृति है।

सामग्री

• सामग्री
• 1. मौलिक सिद्धांत
  
  • 1.1। आराम
  • 1.2। पठनीयता
  • 1.3। उत्पादकता
• 2. पहचान करने वाला
  
  • 2.1। नाम पहचानकर्ता संक्षिप्तता के बजाय स्पष्टता के आधार पर
  • 2.2। आईडी की लंबाई
  • 2.3। प्रकार से चर का नाम न लें
  • 2.4। एकल नामकरण शैली का उपयोग करें
  • 2.5। एकल घोषणा शैली का उपयोग करें
  • 2.6। टीम के लिए काम करें
• 3. टिप्पणियाँ
  
  • 3.1। चर और स्थिरांक में टिप्पणियाँ उनकी सामग्री का वर्णन करना चाहिए, उद्देश्य नहीं
  • 3.2। हमेशा सार्वजनिक रूप से उपलब्ध वर्णों को दस्तावेज़ित करें
• 4. पैकेज संरचना
  
  • 4.1। एक अच्छा पैकेज एक अच्छे नाम से शुरू होता है
  • 4.2। आधार, आम या उपयोग जैसे नामों से बचें
  • 4.3। गहरी डुबकी लगाए बिना जल्दी लौट आओ
  • 4.4। अशक्त मूल्य को उपयोगी बनाएं
  • 4.5। पैकेज स्तर की स्थिति से बचें
• 5. परियोजना संरचना
  
  • 5.1। कम पैकेज, लेकिन बड़ा
  • 5.2। सबसे छोटा मुख्य पैकेज
• 6. एपीआई संरचना
  
  • 6.1। डिजाइन एपीआई जो डिजाइन द्वारा दुरुपयोग करने के लिए कठिन हैं
  • 6.2। एक बेसिक उपयोग के मामले के लिए एक एपीआई डिजाइन
  • 6.3। कार्यों को वांछित व्यवहार निर्धारित करने दें।
• 7. हैंडलिंग में त्रुटि
  
  • 7.1। त्रुटियों को स्वयं हटाकर त्रुटि से निपटने की आवश्यकता को समाप्त करें
  • 7.2। केवल एक बार त्रुटि को संभालें
• 8. संगति
  
  • 8.1। हर समय कुछ काम करें।
  • 8.2। कॉल करने वाले के लिए समानता छोड़ दें
  • 8.3। कभी भी गोरोउटिन को बिना यह जाने कि यह कब रुकेगा

1. मौलिक सिद्धांत

मैं आपके बीच गो के पहले उपयोगकर्ताओं में से एक हो सकता हूं, लेकिन यह मेरी निजी राय नहीं है। इन बुनियादी सिद्धांतों के तहत ही जाना:

1. आराम
2. पठनीयता
3. उत्पादकता

नोट। कृपया ध्यान दें, मैंने "प्रदर्शन" या "संक्षिप्त नाम" का उल्लेख नहीं किया है। गो से भी तेज भाषाएं हैं, लेकिन उनकी तुलना निश्चित रूप से सरलता से नहीं की जा सकती। ऐसी भाषाएं हैं जो समानता को सर्वोच्च प्राथमिकता के रूप में रखती हैं, लेकिन उनकी तुलना पठनीयता या प्रोग्रामिंग उत्पादकता के मामले में नहीं की जा सकती।

प्रदर्शन और संगोष्ठी महत्वपूर्ण गुण हैं, लेकिन सादगी, पठनीयता और उत्पादकता के रूप में महत्वपूर्ण नहीं हैं।

आराम

"सादगी विश्वसनीयता के लिए एक पूर्वापेक्षा है" - एद्गर दिज्क्स्ट्रा

सादगी के लिए प्रयास क्यों? यह क्यों महत्वपूर्ण है कि गो कार्यक्रम सरल हैं?

हम में से प्रत्येक एक समझ से बाहर कोड में आया था, है ना? जब आप एक बदलाव करने से डरते हैं क्योंकि यह कार्यक्रम के एक और हिस्से को तोड़ देगा जिसे आप काफी समझ नहीं पाते हैं और यह नहीं जानते हैं कि कैसे ठीक करना है। यही कठिनाई है।

“सॉफ्टवेयर डिजाइन करने के दो तरीके हैं: पहला यह है कि इसे इतना सरल बनाया जाए कि कोई स्पष्ट खामियां न हों, और दूसरा यह है कि इसे इतना जटिल बना दिया जाए कि कोई स्पष्ट खामियां न हों। पहला बहुत अधिक कठिन है। ” - सी। ई। आर। होर

जटिलता विश्वसनीय सॉफ़्टवेयर को अविश्वसनीय बनाती है। जटिलता वह है जो सॉफ्टवेयर परियोजनाओं को मारती है। इसलिए, सादगी गो का अंतिम लक्ष्य है। हम जो भी कार्यक्रम लिखते हैं, वे सरल होने चाहिए।

1.2। पठनीयता

"पठनीयता बनाए रखने का एक अभिन्न अंग है" - मार्क रेनहोल्ड, जेवीएम सम्मेलन, 2018

यह क्यों महत्वपूर्ण है कि कोड पठनीय है? हमें पठनीयता के लिए क्यों प्रयास करना चाहिए?

"कार्यक्रमों को लोगों के लिए लिखा जाना चाहिए, और मशीनें सिर्फ उन्हें क्रियान्वित करती हैं" - हैल एबेल्सन और जेराल्ड ससमन, "कंप्यूटर प्रोग्राम की संरचना और व्याख्या"

न केवल गो कार्यक्रम, बल्कि आम तौर पर सभी सॉफ्टवेयर लोगों द्वारा लोगों के लिए लिखे जाते हैं। तथ्य यह है कि मशीनों भी कोड प्रक्रिया है माध्यमिक है।

एक बार लिखित कोड लोगों द्वारा बार-बार पढ़ा जाएगा: सैकड़ों, यदि हजारों बार नहीं।

"एक प्रोग्रामर के लिए सबसे महत्वपूर्ण कौशल विचारों को प्रभावी ढंग से संवाद करने की क्षमता है।" - गैस्टन होर्कर

पठनीयता यह समझने की कुंजी है कि एक कार्यक्रम क्या करता है। यदि आप कोड को नहीं समझ सकते हैं, तो इसे कैसे बनाए रखें? यदि सॉफ़्टवेयर का समर्थन नहीं किया जा सकता है, तो इसे फिर से लिखा जाएगा; और यह आखिरी बार हो सकता है जब आपकी कंपनी Go का उपयोग करती है।

यदि आप अपने लिए एक कार्यक्रम लिख रहे हैं, तो वह करें जो आपके लिए काम करता है। लेकिन अगर यह एक संयुक्त परियोजना का हिस्सा है या आवश्यकताओं, कार्यों या वातावरण जिसमें यह काम करता है, को बदलने के लिए लंबे समय तक कार्यक्रम का उपयोग किया जाएगा, तो आपका लक्ष्य कार्यक्रम को बनाए रखना है।

समर्थित सॉफ़्टवेयर लिखने का पहला चरण यह सुनिश्चित करना है कि कोड स्पष्ट है।

1.3। उत्पादकता

"डिजाइन कोड को व्यवस्थित करने की कला है ताकि यह आज काम करे, लेकिन हमेशा बदलाव का समर्थन करता है।" - सैंडी मेट्स

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

यह एक मजाक है कि C ++ प्रोग्राम को संकलित करते समय गो भाषा विकसित की गई थी। त्वरित संकलन गो की एक प्रमुख विशेषता है और नए डेवलपर्स को आकर्षित करने में महत्वपूर्ण कारक है। हालांकि संकलक में सुधार किया जा रहा है, सामान्य तौर पर, अन्य भाषाओं में मिनट संकलन को गो पर कुछ सेकंड लगते हैं। इसलिए गो डेवलपर्स गतिशील भाषाओं में प्रोग्रामर के रूप में उत्पादक महसूस करते हैं, लेकिन उन भाषाओं की विश्वसनीयता के साथ किसी भी समस्या के बिना।

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

जाओ प्रोग्रामर अजीब संकलन त्रुटियों, जटिल बिल्ड स्क्रिप्ट, या उत्पादन वातावरण में कोड की तैनाती डिबगिंग के दिन नहीं बिताते हैं। और सबसे महत्वपूर्ण बात, वे यह समझने में समय बर्बाद नहीं करते कि एक सहयोगी ने क्या लिखा है।

जब गो डेवलपर्स स्केलेबिलिटी के बारे में बात करते हैं, तो उनका मतलब उत्पादकता होता है।

2. पहचान करने वाला

पहला विषय जिस पर हम चर्चा करेंगे - पहचानकर्ता , नामों का एक पर्याय है: चर, कार्य, विधियाँ, प्रकार, पैकेज और इसी तरह के नाम।

"खराब नाम खराब डिजाइन का एक लक्षण है" - डेव चेनी

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

2.1। नाम पहचानकर्ता संक्षिप्तता के बजाय स्पष्टता के आधार पर

“यह महत्वपूर्ण है कि कोड स्पष्ट है। आप एक पंक्ति में क्या कर सकते हैं, आपको तीन में करना होगा। ” - उकी स्मिथ

ट्रिकी वन-लाइनर्स या किसी प्रोग्राम में लाइनों की न्यूनतम संख्या के लिए गो को अनुकूलित नहीं किया गया है। हम डिस्क पर स्रोत कोड के आकार का अनुकूलन नहीं करते हैं, न ही संपादक में कार्यक्रम टाइप करने के लिए आवश्यक समय।

“एक अच्छा नाम एक अच्छे मजाक की तरह है। अगर आपको इसे समझाने की ज़रूरत है, तो यह अब मज़ेदार नहीं है। ” - डेव चेनी

अधिकतम स्पष्टता की कुंजी वे नाम हैं जिन्हें हम कार्यक्रमों की पहचान करने के लिए चुनते हैं। अच्छे नाम में क्या गुण निहित हैं?

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

आइए इन गुणों में से प्रत्येक पर अधिक विस्तार से विचार करें।

2.2। आईडी की लंबाई

कभी-कभी लघु चर नामों के लिए गो की शैली की आलोचना की जाती है। जैसा कि रोब पाइक ने कहा , "जाओ प्रोग्रामर सही लंबाई के पहचानकर्ता चाहते हैं।"

एंड्रयू गेरैंड महत्व बताने के लिए लंबी पहचान प्रदान करता है।

"किसी नाम की घोषणा और किसी वस्तु के उपयोग के बीच की दूरी जितनी अधिक होगी, उतना लंबा नाम होना चाहिए" - एंड्रयू जेरैंड

इस प्रकार, कुछ सिफारिशें की जा सकती हैं:

• लघु चर नाम अच्छे हैं यदि घोषणा और अंतिम उपयोग के बीच की दूरी छोटी है।
  
• लंबे चर नाम खुद को सही ठहराना चाहिए; अब वे जितने महत्वपूर्ण हैं, उतना ही महत्वपूर्ण होना चाहिए। पृष्ठ पर उनके वजन के संबंध में वर्बोज़ शीर्षक में बहुत कम संकेत होते हैं।
  
• चर नाम में प्रकार नाम शामिल न करें।
  
• निरंतर नामों को आंतरिक मूल्य का वर्णन करना चाहिए, न कि यह कि मूल्य का उपयोग कैसे किया जाता है।
  
• लूप और शाखाओं के लिए एकल-अक्षर चर को प्राथमिकता दें, मापदंडों और वापसी मूल्यों के लिए अलग-अलग शब्द, पैकेज स्तर पर कार्यों और घोषणाओं के लिए कई शब्द।
  
• विधियों, इंटरफेस और पैकेज के लिए एकल शब्दों को प्राथमिकता दें।
  
• याद रखें कि पैकेज का नाम उस नाम का हिस्सा है जिसे कॉलर संदर्भ के लिए उपयोग करता है।

एक उदाहरण पर विचार करें।

type Person struct { Name string Age int } // AverageAge returns the average age of people. func AverageAge(people []Person) int { if len(people) == 0 { return 0 } var count, sum int for _, p := range people { sum += p.Age count += 1 } return sum / count } 

दसवीं पंक्ति में, रेंज p एक चर घोषित किया जाता है, और इसे अगली पंक्ति से केवल एक बार कहा जाता है। यही है, चर बहुत कम समय के लिए पृष्ठ पर रहता है। यदि पाठक को कार्यक्रम में p की भूमिका में रुचि है, तो उसे केवल दो पंक्तियों को पढ़ना होगा।

तुलना के लिए, people फ़ंक्शन मापदंडों में घोषित किया people और सात लाइनें लाइव होती हैं। वही sum और count लिए जाता है, इसलिए वे अपने लंबे नामों को सही ठहराते हैं। पाठक को उन्हें खोजने के लिए अधिक कोड स्कैन करने की आवश्यकता है: यह अधिक प्रतिष्ठित नामों को सही ठहराता है।

आप count लिए sum और c (या n ) के लिए s चयन कर सकते हैं, लेकिन यह कार्यक्रम में सभी चर के महत्व को समान स्तर तक कम कर देता है। आप p साथ people को बदल सकते हैं, लेकिन एक समस्या होगी, क्या for ... range पुनरावृत्ति चर कॉल करने के for ... range । एक अकेला person अजीब लगेगा, क्योंकि एक अल्पकालिक चलना चर को कई मानों से अधिक लंबा नाम मिलता है, जहां से यह प्राप्त होता है।

टिप । रिक्त लाइनों के साथ कार्यों की धारा को अलग करें, क्योंकि पैराग्राफ के बीच की खाली लाइनें पाठ के प्रवाह को तोड़ती हैं। AverageAge , हमारे पास लगातार तीन ऑपरेशन हैं। सबसे पहले, विभाजन को शून्य से जांचना, फिर कुल आयु और लोगों की संख्या का निष्कर्ष, और अंतिम - औसत आयु की गणना।

2.2.1। मुख्य बात संदर्भ है

यह समझना महत्वपूर्ण है कि अधिकांश नामकरण युक्तियाँ संदर्भ विशेष हैं। मुझे यह कहना पसंद है कि यह एक सिद्धांत है, एक नियम नहीं है।

i और index क्या अंतर है? उदाहरण के लिए, आप इस तरह के कोड को असमान रूप से नहीं कह सकते

 for index := 0; index < len(s); index++ { // } 

मौलिक रूप से अधिक पठनीय है

 for i := 0; i < len(s); i++ { // } 

मेरा मानना ​​है कि दूसरा विकल्प कोई भी बदतर नहीं है, क्योंकि इस मामले में क्षेत्र i या index लूप के शरीर द्वारा सीमित है, और अतिरिक्त वर्बोसिटी कार्यक्रम की समझ में बहुत कम जोड़ता है।

लेकिन इनमें से कौन सा कार्य अधिक पठनीय है?

 func (s *SNMP) Fetch(oid []int, index int) (int, error) 

या

 func (s *SNMP) Fetch(o []int, i int) (int, error) 

इस उदाहरण में, oid एसएनएमपी ऑब्जेक्ट आईडी का संक्षिप्त नाम है, और o को अतिरिक्त संक्षिप्त नाम आपको डॉक्यूमेंटेड नोटेशन से कोड को पढ़ने के लिए कोड में स्विच करने के लिए मजबूर करता है। इसी प्रकार, i को सिकुड़ते हुए index को समझना कठिन हो जाता है, क्योंकि SNMP संदेशों में, प्रत्येक OID के उप मूल्य को सूचकांक कहा जाता है।

टिप । एक विज्ञापन में लंबे और छोटे औपचारिक मापदंडों को संयोजित न करें।

2.3। प्रकार से चर का नाम न लें

आप अपने पालतू जानवरों को "कुत्ता" और "बिल्ली" नहीं कहते हैं, है ना? उसी कारण से, आपको चर नाम में प्रकार नाम शामिल नहीं करना चाहिए। यह सामग्री का वर्णन करना चाहिए, न कि इसका प्रकार। एक उदाहरण पर विचार करें:

 var usersMap map[string]*User 

यह घोषणा कितनी अच्छी है? हम देखते हैं कि यह एक नक्शा है, और इसका *User प्रकार के साथ कुछ करना है: यह शायद अच्छा है। लेकिन usersMap मानचित्र वास्तव में एक नक्शा है, और गो, एक सांख्यिकीय रूप से टाइप की गई भाषा के रूप में, गलती से इस नाम का उपयोग नहीं करेगा जहां एक स्केलर चर की आवश्यकता होती है, इसलिए Map प्रत्यय बेमानी है।

ऐसी स्थिति पर विचार करें जहां अन्य चर जोड़े जाते हैं:

 var ( companiesMap map[string]*Company productsMap map[string]*Products ) 

अब हमारे पास टाइप मैप के तीन वैरिएबल्स हैं: usersMap मैप, companiesMap usersMap और productsMap मैप, और सभी लाइनें अलग-अलग तरह से मैप की जाती हैं। हम जानते हैं कि ये नक्शे हैं, और हम यह भी जानते हैं कि कंपाइलर एक त्रुटि को फेंक देगा यदि हम उन companiesMap map[string]*User का उपयोग करने का प्रयास करते companiesMap जहां कोड map[string]*User अपेक्षा करता है। इस स्थिति में, यह स्पष्ट है कि Map प्रत्यय कोड की स्पष्टता में सुधार नहीं करता है, ये केवल अतिरिक्त वर्ण हैं।

मैं किसी भी प्रत्यय से बचने का सुझाव देता हूं जो एक चर के प्रकार से मिलता-जुलता है।

टिप । यदि नाम वाले users सार का स्पष्ट रूप से वर्णन नहीं करते हैं, तो usersMap भी।

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

 type Config struct { // } func WriteConfig(w io.Writer, config *Config) 

*Config पैरामीटर के लिए config नाम बेमानी है। हम पहले से ही जानते हैं कि यह *Config , यह तुरंत इसके बगल में लिखा जाता है।

इस मामले में, विचार करें कि क्या c या c चर के जीवनकाल के लिए पर्याप्त है।

यदि हमारे क्षेत्र में कुछ बिंदु पर एक से अधिक *Config , तो conf1 और conf2 नाम original और updated तुलना में कम सार्थक conf2 , क्योंकि उत्तरार्द्ध मिश्रण करना अधिक कठिन है।

नोट। पैकेज नामों को अच्छे चर नामों को चोरी न करने दें।

आयातित पहचानकर्ता के नाम में पैकेज का नाम होता है। उदाहरण के लिए, context पैकेज में Context प्रकार को context कहा जाएगा। context.Context । यह आपके पैकेज में एक चर या प्रकार के context का उपयोग करना असंभव बनाता है।

 func WriteLog(context context.Context, message string) 

यह संकलन नहीं होगा। इसीलिए जब context.Context घोषणा की जाती है। स्थानीय रूप से context.Context प्रकार, उदाहरण के लिए, ctx जैसे नाम परंपरागत रूप से उपयोग किए जाते हैं।

 func WriteLog(ctx context.Context, message string) 

2.4। एकल नामकरण शैली का उपयोग करें

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

उदाहरण के लिए, यदि कोड डेटाबेस के डिस्क्रिप्टर के आसपास जाता है, तो हर बार पैरामीटर प्रदर्शित होने पर, उसका नाम समान होना चाहिए। d *sql.DB , dbase *sql.DB , DB *sql.DB और database *sql.DB जैसे सभी प्रकार के संयोजनों के बजाय एक चीज़ का उपयोग करना बेहतर है:

 db *sql.DB 

कोड को समझना आसान है यदि आप db देखते हैं, तो आप जानते हैं कि यह *sql.DB और इसे स्थानीय रूप से घोषित किया जाता है या कॉलर द्वारा प्रदान किया जाता है।

एक विधि के प्राप्तकर्ताओं के बारे में इसी तरह की सलाह; इस प्रकार की प्रत्येक विधि के लिए एक ही प्राप्तकर्ता नाम का उपयोग करें। इसलिए पाठक के लिए इस प्रकार के विभिन्न तरीकों के बीच प्राप्तकर्ता के उपयोग को सीखना आसान होगा।

नोट। जाओ प्राप्तकर्ता संक्षिप्त नाम समझौता पहले की गई सिफारिशों का विरोधाभासी है। यह उन मामलों में से एक है जहां प्रारंभिक चरण में किया गया विकल्प मानक शैली बन जाता है, जैसे कि snake_case बजाय CamelCase का उपयोग snake_case ।

टिप । गो शैली एकल अक्षर के नाम या उनके प्रकार से प्राप्त प्राप्तकर्ताओं के लिए संक्षिप्त रूप को इंगित करती है। यह पता लग सकता है कि प्राप्तकर्ता नाम कभी-कभी विधि में पैरामीटर नाम के साथ संघर्ष करता है। इस मामले में, पैरामीटर नाम को थोड़ा लंबा करने की सिफारिश की जाती है और क्रमिक रूप से इसका उपयोग करने के लिए मत भूलना।

अंत में, कुछ एक-अक्षर चर पारंपरिक रूप से छोरों और गिनती के साथ जुड़े होते हैं। उदाहरण के लिए, i , j और k आमतौर पर छोरों के for आगमनात्मक चर होते हैं, n आमतौर पर एक काउंटर या संचयी योजक के साथ जुड़ा होता है, v एक एन्कोडिंग फ़ंक्शन में मूल्य के लिए एक विशिष्ट संक्षिप्त नाम है, आमतौर पर एक मैप कुंजी के लिए k उपयोग किया जाता है, और s अक्सर टाइप string मापदंडों के लिए एक संक्षिप्त नाम के रूप में उपयोग किया जाता है। ।

जैसा कि ऊपर db उदाहरण के साथ, प्रोग्रामर उम्मीद करते हैं कि i एक इंडक्टिव वेरिएबल बनूंगा। यदि वे इसे कोड में देखते हैं, तो वे जल्द ही एक लूप देखने की उम्मीद करते हैं।

टिप । यदि आपके पास इतने सारे नेस्टेड लूप हैं जो आपने i , j और k वैरिएबल्स से निकाले हैं, तो आप फंक्शन को छोटी यूनिट्स में तोड़ना चाह सकते हैं।

2.5। एकल घोषणा शैली का उपयोग करें

चर घोषित करने के लिए गो के पास कम से कम छह अलग-अलग तरीके हैं।

•  var x int = 1 

•  var x = 1 

•  var x int; x = 1 

•  var x = int(1) 

•  x := 1 

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

मैं उन चरों को घोषित करने की एक शैली का प्रस्ताव करना चाहता हूँ जो मैं स्वयं जहाँ भी संभव हो उपयोग करने का प्रयास करता हूँ।

• आरंभीकरण के बिना एक चर घोषित करते समय, var उपयोग करें ।
  
  

   var players int // 0 var things []Thing // an empty slice of Things var thing Thing // empty Thing struct json.Unmarshall(reader, &thing) 

  
  var एक संकेत के रूप में कार्य करता है कि यह चर जानबूझकर निर्दिष्ट प्रकार के शून्य मान के रूप में घोषित किया गया है। यह लघु घोषित सिंटैक्स के विपरीत var पैकेज स्तर पर चर घोषित करने की आवश्यकता के अनुरूप है, हालांकि मैं बाद में तर्क दूंगा कि पैकेज स्तर के चर का उपयोग बिल्कुल भी नहीं किया जाना चाहिए।
• आरंभीकरण के साथ घोषणा करते समय, उपयोग करें := । इससे पाठक को यह स्पष्ट हो जाता है कि बाईं ओर का चर := जानबूझकर आरंभिक है।
  
  यह समझाने के लिए कि, हम पिछले उदाहरण को देखते हैं, लेकिन इस बार हम विशेष रूप से प्रत्येक चर को शुरू करते हैं:
  
  

   var players int = 0 var things []Thing = nil var thing *Thing = new(Thing) json.Unmarshall(reader, thing) 

चूंकि गो में एक प्रकार से दूसरे में स्वचालित रूपांतरण नहीं होते हैं, पहले और तीसरे उदाहरण में असाइनमेंट ऑपरेटर के बाईं ओर का प्रकार दाईं ओर के प्रकार के समान होना चाहिए। संकलक दाईं ओर के प्रकार से घोषित चर के प्रकार का अनुमान लगा सकता है, इसलिए उदाहरण को अधिक संक्षेप में लिखा जा सकता है:

 var players = 0 var things []Thing = nil var thing = new(Thing) json.Unmarshall(reader, thing) 

यहां, players स्पष्ट रूप से 0 प्रारंभ किया जाता है, जो निरर्थक है, क्योंकि players का प्रारंभिक मूल्य किसी भी मामले में शून्य है। इसलिए, यह स्पष्ट करना बेहतर है कि हम एक शून्य मान का उपयोग करना चाहते हैं:

 var players int 

दूसरे ऑपरेटर के बारे में क्या? हम प्रकार निर्धारित नहीं कर सकते हैं और लिख सकते हैं

 var things = nil 

क्योंकि nil कोई प्रकार नहीं है । इसके बजाय, हमारे पास एक विकल्प है: या हम स्लाइस के लिए एक शून्य मान का उपयोग करते हैं ...

 var things []Thing 

... या शून्य तत्वों के साथ एक स्लाइस बनाएं?

 var things = make([]Thing, 0) 

दूसरे मामले में, स्लाइस के लिए मूल्य शून्य नहीं है, और हम घोषणा के संक्षिप्त रूप का उपयोग करके पाठक को स्पष्ट करते हैं:

 things := make([]Thing, 0) 

यह पाठक को बताता है कि हमने things को स्पष्ट रूप से शुरू करने का फैसला किया है।

तो हम तीसरी घोषणा पर आते हैं:

 var thing = new(Thing) 

यहाँ, चर का स्पष्ट इनिशियलाइज़ेशन और "यूनिक" कीवर्ड new की शुरूआत, जिसे कुछ गो प्रोग्रामर पसंद नहीं करते हैं। अनुशंसित लघु सिंटैक्स पैदावार का उपयोग करना

 thing := new(Thing) 

इससे यह स्पष्ट होता है कि thing new(Thing) के परिणाम के लिए स्पष्ट रूप से आरंभीकृत है, लेकिन फिर भी एक new छोड़ देता है। समस्या को शाब्दिक रूप से हल किया जा सकता है:

 thing := &Thing{} 

जो new(Thing) समान है, और इस तरह के दोहराव कुछ गो प्रोग्रामर को अपसेट करते हैं। हालांकि, इसका मतलब यह है कि हम स्पष्ट रूप से thing को पॉइंटर Thing{} और शून्य के Thing मान के साथ इंगित करते हैं।

लेकिन इस तथ्य को ध्यान में रखना बेहतर है कि thing शून्य मान के साथ घोषित की जाती है, और ऑपरेटर के पते का उपयोग करके json.Unmarshall में json.Unmarshall thing का पता पास करना है:

 var thing Thing json.Unmarshall(reader, &thing) 

नोट। बेशक, किसी भी नियम के अपवाद हैं। उदाहरण के लिए, कभी-कभी दो चर निकटता से संबंधित होते हैं, इसलिए यह लिखना अजीब होगा

 var min int max := 1000 

अधिक पठनीय घोषणा:

 min, max := 0, 1000 

संक्षेप में:

• आरंभीकरण के बिना एक चर घोषित करते समय, var सिंटैक्स का उपयोग करें।
  
• घोषित करते समय और स्पष्ट रूप से एक चर को इनिशियलाइज़ करते हुए, उपयोग करें :=

टिप । स्पष्ट रूप से जटिल चीजों को इंगित करें।

 var length uint32 = 0x80 

यहां length का उपयोग पुस्तकालय के साथ किया जा सकता है, जिसके लिए एक विशिष्ट संख्यात्मक प्रकार की आवश्यकता होती है, और यह विकल्प अधिक स्पष्ट रूप से इंगित करता है कि टाइप लंबाई को विशेष रूप से लघु घोषणा की तुलना में uint32 के रूप में चुना गया है:

 length := uint32(0x80) 

पहले उदाहरण में, मैं स्पष्ट रूप से प्रारंभिक आरंभीकरण के साथ var घोषणा का उपयोग करके जानबूझकर अपने नियम को तोड़ता हूं। मानक से एक प्रस्थान पाठक को समझ में आता है कि कुछ असामान्य हो रहा है।

2.6। टीम के लिए काम करें

मैंने पहले ही कहा है कि सॉफ्टवेयर विकास का सार पठनीय, समर्थित कोड का निर्माण है। आपका अधिकांश कैरियर संभवतः संयुक्त परियोजनाओं पर काम करेगा। इस स्थिति में मेरी सलाह: टीम में अपनाई गई शैली का पालन करें।

फ़ाइल के बीच में शैलियों को बदलना कष्टप्रद है। संगति महत्वपूर्ण है, यद्यपि व्यक्तिगत प्राथमिकता के उल्लंघन के लिए। मेरे अंगूठे का नियम है: यदि कोड gofmt माध्यम से फिट बैठता है, तो समस्या आमतौर पर चर्चा के लायक नहीं है।

टिप । यदि आप पूरे कोड आधार का नाम बदलना चाहते हैं, तो इसे अन्य परिवर्तनों के साथ न मिलाएं। यदि कोई git bisect का उपयोग करता है, तो वह एक और संशोधित कोड खोजने के लिए हजारों नाम बदलने के माध्यम से उतारा करना पसंद नहीं करेगा।

3. टिप्पणियाँ

इससे पहले कि हम अधिक महत्वपूर्ण बिंदुओं पर आगे बढ़ें, मैं टिप्पणी करने के लिए कुछ मिनट लेना चाहता हूं।

"एक अच्छे कोड में बहुत सारी टिप्पणियाँ होती हैं, और एक बुरे कोड को बहुत सारी टिप्पणियों की आवश्यकता होती है।" - डेव थॉमस और एंड्रयू हंट, व्यावहारिक प्रोग्रामर

कार्यक्रम की पठनीयता के लिए टिप्पणियाँ बहुत महत्वपूर्ण हैं। प्रत्येक टिप्पणी को एक करना चाहिए - और केवल एक - तीन चीजों का:

1. बताएं कि कोड क्या करता है।
2. यह बताएं कि वह यह कैसे करता है।
3. क्यों समझाएं।

पहला रूप सार्वजनिक पात्रों पर टिप्पणी करने के लिए आदर्श है:

 // Open     . //           . 

दूसरा एक विधि के अंदर टिप्पणियों के लिए आदर्श है:

 //     var results []chan error for _, dep := range a.Deps { results = append(results, execute(seen, dep)) } 

तीसरा रूप ("क्यों") इस मायने में अनूठा है कि यह पहले दो को दबा या प्रतिस्थापित नहीं करता है। इस तरह की टिप्पणियों से बाहरी कारकों की व्याख्या होती है जिसके कारण इसके वर्तमान रूप में कोड लिखना पड़ता है। अक्सर इस संदर्भ के बिना, यह समझना मुश्किल है कि कोड इस तरह से क्यों लिखा गया है।

 return &v2.Cluster_CommonLbConfig{ //  HealthyPanicThreshold HealthyPanicThreshold: &envoy_type.Percent{ Value: 0, }, } 

इस उदाहरण में, यह तुरंत स्पष्ट नहीं हो सकता है कि क्या होता है जब HealthyPanicThreshold शून्य प्रतिशत पर सेट किया गया हो। टिप्पणी को स्पष्ट करने का इरादा है कि 0 का मान घबराहट दहलीज को निष्क्रिय करता है।

3.1। चर और स्थिरांक में टिप्पणियाँ उनकी सामग्री का वर्णन करना चाहिए, उद्देश्य नहीं

मैंने पहले कहा था कि एक चर या अचर का नाम उसके उद्देश्य का वर्णन करना चाहिए। लेकिन एक चर या स्थिरांक पर एक टिप्पणी वास्तव में सामग्री का वर्णन करना चाहिए, उद्देश्य नहीं।

 const randomNumber = 6 //     

इस उदाहरण में, एक टिप्पणी बताती है कि randomNumber 6 पर randomNumber क्यों randomNumber और यह कहां से आया है। टिप्पणी यह ​​नहीं बताती है कि randomNumber का उपयोग कहां किया जाएगा। यहाँ कुछ और उदाहरण दिए गए हैं:

 const ( StatusContinue = 100 // RFC 7231, 6.2.1 StatusSwitchingProtocols = 101 // RFC 7231, 6.2.2 StatusProcessing = 102 // RFC 2518, 10.1 StatusOK = 200 // RFC 7231, 6.3.1 

HTTP के संदर्भ में, 100 नंबर StatusContinue रूप 100 जाना जाता है, जैसा कि RFC 7231, खंड 6.2.1 में परिभाषित किया गया है।

टिप । प्रारंभिक मूल्य के बिना चर के लिए, टिप्पणी का वर्णन करना चाहिए कि इस चर को शुरू करने के लिए कौन जिम्मेदार है।

 // sizeCalculationDisabled ,   //     . . dowidth. var sizeCalculationDisabled bool 

यहाँ एक टिप्पणी पाठक को बताती है कि dowidth फ़ंक्शन dowidth की स्थिति बनाए रखने के लिए ज़िम्मेदार है।

टिप । दृष्टि में छिपाना। यह केट ग्रेगरी की सलाह है । कभी-कभी एक चर का सबसे अच्छा नाम टिप्पणियों में छिपा होता है।

 //   SQL var registry = make(map[string]*sql.Driver) 

लेखक द्वारा एक टिप्पणी जोड़ी गई क्योंकि नाम registry पर्याप्त रूप से इसके उद्देश्य की व्याख्या नहीं करती है - यह एक रजिस्ट्री है, लेकिन रजिस्ट्री क्या है?

यदि आप एक चर का नाम sqlDrivers में रखते हैं, तो यह स्पष्ट हो जाता है कि इसमें SQL ड्राइवर हैं।

 var sqlDrivers = make(map[string]*sql.Driver) 

अब टिप्पणी बेमानी हो गई है और उसे हटाया जा सकता है।

3.2। हमेशा सार्वजनिक रूप से उपलब्ध वर्णों को दस्तावेज़ित करें

आपके पैकेज के लिए दस्तावेज़ गॉडोक द्वारा तैयार किया गया है, इसलिए आपको पैकेज में घोषित प्रत्येक सार्वजनिक चरित्र पर एक टिप्पणी जोड़ना चाहिए: एक चर, निरंतर, फ़ंक्शन और विधि।

Google शैली गाइड के दो दिशानिर्देश यहां दिए गए हैं:

• कोई भी सार्वजनिक समारोह जो स्पष्ट और संक्षिप्त दोनों नहीं है, उस पर टिप्पणी की जानी चाहिए।
  
• लाइब्रेरी के किसी भी फंक्शन पर कमेंट किया जाना चाहिए, चाहे लंबाई या जटिलता कुछ भी हो।

 package ioutil // ReadAll   r      (EOF)   // ..    err == nil, not err == EOF. //  ReadAll     ,     //  . func ReadAll(r io.Reader) ([]byte, error) 

इस नियम का एक अपवाद है: आपको इंटरफ़ेस को लागू करने वाले तरीकों का दस्तावेजीकरण करने की आवश्यकता नहीं है। विशेष रूप से, ऐसा न करें:

 // Read   io.Reader func (r *FileReader) Read(buf []byte) (int, error) 

इस टिप्पणी का कोई मतलब नहीं है। वह यह नहीं कहता कि विधि क्या करती है: बदतर, वह कहीं न कहीं दस्तावेज देखने के लिए भेजता है। इस स्थिति में, मैं टिप्पणी को पूरी तरह से हटाने का प्रस्ताव करता हूं।

यहाँ io पैकेज से एक उदाहरण है।

 // LimitReader  Reader,    r, //    EOF  n . //   *LimitedReader. func LimitReader(r Reader, n int64) Reader { return &LimitedReader{r, n} } // LimitedReader   R,     //   N .   Read  N  //    . // Read  EOF,  N <= 0    R  EOF. type LimitedReader struct { R Reader // underlying reader N int64 // max bytes remaining } func (l *LimitedReader) Read(p []byte) (n int, err error) { if lN <= 0 { return 0, EOF } if int64(len(p)) > lN { p = p[0:lN] } n, err = lRRead(p) lN -= int64(n) return } 

ध्यान दें कि LimitedReader घोषणा तुरंत उस फ़ंक्शन द्वारा पूर्ववर्ती है जो इसका उपयोग करता है, और LimitedReader.Read घोषणा खुद LimitedReader की घोषणा का LimitedReader करती है। हालाँकि LimitedReader.Read स्वयं प्रलेखित नहीं है, यह समझा जा सकता है कि यह io.Reader कार्यान्वयन है।

टिप । एक समारोह लिखने से पहले, यह वर्णन करते हुए एक टिप्पणी लिखें। यदि आपको टिप्पणी लिखना मुश्किल लगता है, तो यह एक संकेत है कि आप जिस कोड के बारे में लिखने वाले हैं उसे समझना मुश्किल होगा।

3.2.1। खराब कोड पर टिप्पणी न करें, इसे फिर से लिखें

"बुरा मत टिप्पणी कोड - इसे फिर से लिखना" - ब्रायन Kernighan

यह टिप्पणी में इंगित करने के लिए पर्याप्त नहीं है कि कोड के टुकड़े की कठिनाई। यदि आप इन टिप्पणियों में से एक पर आते हैं, तो आपको एक टिकट की शुरुआत करनी चाहिए जिसमें रीफैक्टरिंग की याद आती है। जब तक इसकी राशि ज्ञात हो आप तकनीकी ऋण के साथ रह सकते हैं।

मानक पुस्तकालय में, टीओडीओ शैली में टिप्पणियों को छोड़ने का रिवाज है, जिसमें उपयोगकर्ता ने समस्या पर ध्यान दिया है।

 // TODO(dfc)  O(N^2),     . 

यह समस्या को ठीक करने के लिए बाध्यता नहीं है, लेकिन संकेतित उपयोगकर्ता एक प्रश्न पूछने के लिए सबसे अच्छा व्यक्ति हो सकता है। अन्य परियोजनाएं TODO के साथ एक तिथि या टिकट संख्या के साथ होती हैं।

3.2.2। कोड को कमेंट करने के बजाय, इसे रिफलेक्टर करें

“अच्छा कोड सबसे अच्छा दस्तावेज है। जब आप एक टिप्पणी जोड़ने वाले हों, तो अपने आप से सवाल पूछें: "कोड में सुधार कैसे करें ताकि इस टिप्पणी की आवश्यकता न हो?" रिफ्लेक्टर और इसे और भी स्पष्ट बनाने के लिए एक टिप्पणी छोड़ें। ” - स्टीव मैककोनेल

कार्य केवल एक कार्य करना चाहिए। यदि आप एक टिप्पणी लिखना चाहते हैं क्योंकि कुछ अंश बाकी फ़ंक्शन से संबंधित नहीं है, तो इसे एक अलग फ़ंक्शन में निकालने पर विचार करें।

छोटी विशेषताएं न केवल स्पष्ट हैं, बल्कि एक-दूसरे से अलग-अलग परीक्षण करना आसान है। जब आप कोड को एक अलग फ़ंक्शन में अलग करते हैं, तो इसका नाम एक टिप्पणी को बदल सकता है।

4. पैकेज संरचना

"एक मामूली कोड लिखें: ऐसे मॉड्यूल जो अन्य मॉड्यूल के लिए कुछ भी अधिक नहीं दिखाते हैं और जो अन्य मॉड्यूल के कार्यान्वयन पर भरोसा नहीं करते हैं" - डेव थॉमस

प्रत्येक पैकेज अनिवार्य रूप से एक अलग छोटा गो कार्यक्रम है। जिस तरह किसी फंक्शन या मेथड का कार्यान्वयन कॉल करने वाले के लिए मायने नहीं रखता है, उसी तरह फंक्शन, मेथड और प्रकार जो आपके पैकेज की सार्वजनिक एपीआई को बनाते हैं, का कार्यान्वयन मायने नहीं रखता है।

एक अच्छा गो पैकेज स्रोत कोड स्तर पर अन्य पैकेजों के साथ न्यूनतम कनेक्टिविटी के लिए प्रयास करता है ताकि जैसे-जैसे परियोजना बढ़ती है, एक पैकेज में बदलाव पूरे कोड बेस में कैस्केड न हो। इस तरह की परिस्थितियाँ इस कोड बेस पर काम करने वाले प्रोग्रामर्स को बहुत रोकती हैं।

इस भाग में, हम पैकेज डिजाइन के बारे में बात करेंगे, जिसमें उसका नाम और लिखने के तरीके और कार्य शामिल हैं।

4.1। एक अच्छा पैकेज एक अच्छे नाम से शुरू होता है

एक अच्छा गो पैकेज एक गुणवत्ता नाम से शुरू होता है। इसे केवल एक शब्द तक सीमित एक छोटी प्रस्तुति के रूप में सोचें।

पिछले अनुभाग में चर नामों की तरह, पैकेज नाम बहुत महत्वपूर्ण है। इस पैकेज में डेटा प्रकारों के बारे में सोचने की आवश्यकता नहीं है, यह सवाल पूछना बेहतर है: "यह पैकेज किस सेवा प्रदान करता है?" आमतौर पर उत्तर "यह पैकेज टाइप X प्रदान करता है" नहीं है, लेकिन "यह पैकेज आपको HTTP के माध्यम से कनेक्ट करने की अनुमति देता है।"

टिप । इसकी कार्यक्षमता से पैकेज का नाम चुनें, इसकी सामग्री नहीं।

4.1.1। अच्छे पैकेज के नाम अद्वितीय होने चाहिए

प्रत्येक पैकेज का प्रोजेक्ट में एक विशिष्ट नाम है। पैकेजों के उद्देश्य के लिए नाम देने की सलाह का पालन करने पर कोई कठिनाई नहीं है। यदि यह पता चलता है कि दो पैकेजों का नाम एक ही है, तो सबसे अधिक संभावना है:

1. .
2. . , .

4.2। base , common util

बुरे नामों का एक सामान्य कारण तथाकथित सेवा पैकेज हैं , जहां समय के साथ विभिन्न सहायक और सेवा कोड जमा होते हैं। चूंकि वहां एक अनोखा नाम मिलना मुश्किल है। यह अक्सर इस तथ्य की ओर जाता है कि पैकेज का नाम इसमें निहित है : उपयोगिताओं से। आमतौर पर

नाम बड़े प्रोजेक्ट्स में मिलते हैं utilsया helpersमिलते हैं, जिसमें पैकेजों की गहरी पदानुक्रम निहित होती है, और सहायक कार्यों को साझा किया जाता है। यदि आप किसी फ़ंक्शन को नए पैकेज में निकालते हैं, तो आयात टूट जाता है। इस मामले में, पैकेज का नाम पैकेज के उद्देश्य को नहीं दर्शाता है, लेकिन केवल तथ्य यह है कि परियोजना के अनुचित संगठन के कारण आयात फ़ंक्शन विफल हो गया है।

ऐसी स्थितियों में, मैं विश्लेषण करने की सलाह देता हूं कि पैकेज कहां से बुलाए जाते हैं।utils helpers, और, यदि संभव हो, तो संबंधित कार्यों को कॉलिंग पैकेट में स्थानांतरित करें। यहां तक ​​कि अगर यह कुछ सहायक कोड के दोहराव का मतलब है, तो यह दो पैकेजों के बीच आयात निर्भरता को शुरू करने से बेहतर है।

"[थोड़ा] दोहराव एक गलत अमूर्त की तुलना में बहुत सस्ता है" - सैंडी मेट्स

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

टिप । सेवा पैकेज के लिए बहुवचन का उपयोग करें। उदाहरण के लिए, stringsस्ट्रिंग प्रसंस्करण उपयोगिताओं के लिए।

ऐसे नामों वाले पैकेज baseया commonजिनका सामना अक्सर तब होता है जब किसी क्लाइंट और सर्वर के लिए दो या दो से अधिक कार्यान्वयन या सामान्य प्रकारों की एक निश्चित सामान्य कार्यक्षमता को एक अलग पैकेज में मिला दिया जाता है। मेरा मानना ​​है कि ऐसे मामलों में क्लाइंट, सर्वर और कॉमन कोड को एक पैकेज में एक नाम के साथ जोड़कर पैकेज की संख्या को कम करना आवश्यक है जो इसके कार्य से मेल खाती है।

उदाहरण के लिए, करने के लिए net/httpअलग-अलग पैकेज भी नहीं clientऔर serverबजाय, वहाँ फ़ाइलें हैं, client.goऔर server.goइसी डेटा प्रकार के साथ, साथ ही साथ transport.goकुल परिवहन के लिए।

टिप । यह याद रखना महत्वपूर्ण है कि पहचानकर्ता नाम में पैकेज नाम शामिल है।

• एक Getपैकेज से एक फ़ंक्शन दूसरे पैकेज से net/httpएक http.Getलिंक बन जाता है ।
  
• एक Readerपैकेज का एक प्रकार stringsदूसरे पैकेज में आयात होने पर बदल जाता है strings.Reader।
  
• Errorपैकेज से इंटरफ़ेस netस्पष्ट रूप से नेटवर्क त्रुटियों से जुड़ा हुआ है।

4.3। गहरी डुबकी लगाए बिना जल्दी लौट आओ

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

यह सीमा ऑपरेटरों का उपयोग करके प्राप्त किया जाता है : फ़ंक्शन के इनपुट पर एक पूर्व शर्त के साथ सशर्त ब्लॉक। यहाँ पैकेज से एक उदाहरण है bytes:

 func (b *Buffer) UnreadRune() error { if b.lastRead <= opInvalid { return errors.New("bytes.Buffer: UnreadRune: previous operation was not a successful ReadRune") } if b.off >= int(b.lastRead) { b.off -= int(b.lastRead) } b.lastRead = opInvalid return nil } 

फ़ंक्शन में प्रवेश करने पर UnreadRune, राज्य की जांच की जाती है b.lastReadऔर यदि पिछला ऑपरेशन नहीं था ReadRune, तो एक त्रुटि तुरंत वापस आ जाती है। बाकी की b.lastReadतुलना में अधिक क्या है के आधार पर समारोह के बाकी काम करता है opInvalid।

समान फ़ंक्शन के साथ तुलना करें, लेकिन सीमा ऑपरेटर के बिना:

 func (b *Buffer) UnreadRune() error { if b.lastRead > opInvalid { if b.off >= int(b.lastRead) { b.off -= int(b.lastRead) } b.lastRead = opInvalid return nil } return errors.New("bytes.Buffer: UnreadRune: previous operation was not a successful ReadRune") } 

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

4.4। अशक्त मूल्य को उपयोगी बनाएं

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

हमेशा एक ज्ञात डिफ़ॉल्ट मान सेट करने की क्षमता आपके प्रोग्राम की सुरक्षा और शुद्धता के लिए महत्वपूर्ण है और आपके गो कार्यक्रमों को आसान और अधिक कॉम्पैक्ट बना सकती है। जब वे कहते हैं कि यह गो प्रोग्रामर्स के दिमाग में है, "संरचनाओं को एक उपयोगी शून्य मान दें।"

एक प्रकार पर विचार करें sync.Mutexजिसमें म्यूटेक्स की आंतरिक स्थिति का प्रतिनिधित्व करने वाले दो पूर्णांक फ़ील्ड शामिल हैं। ये क्षेत्र किसी भी घोषणा में स्वतः ही अशक्त हैं।sync.Mutex। इस तथ्य को कोड में ध्यान में रखा गया है, इसलिए प्रकार स्पष्ट आरंभीकरण के बिना उपयोग के लिए उपयुक्त है।

 type MyInt struct { mu sync.Mutex val int } func main() { var i MyInt // i.mu is usable without explicit initialisation. i.mu.Lock() i.val++ i.mu.Unlock() } 

उपयोगी शून्य मान के साथ एक अन्य प्रकार का एक और उदाहरण है bytes.Buffer। आप स्पष्ट आरंभीकरण के बिना इसे घोषित और लिखना शुरू कर सकते हैं।

 func main() { var b bytes.Buffer b.WriteString("Hello, world!\n") io.Copy(os.Stdout, &b) } 

इस संरचना के शून्य मान का मतलब है कि lenदोनों capबराबर हैं 0, और वाई array, बैकअप स्लाइस सरणी की सामग्री के साथ मेमोरी के लिए सूचक, मान nil। इसका मतलब है कि आपको स्पष्ट रूप से कटौती करने की आवश्यकता नहीं है, आप बस इसे घोषित कर सकते हैं।

 func main() { // s := make([]string, 0) // s := []string{} var s []string s = append(s, "Hello") s = append(s, "world") fmt.Println(strings.Join(s, " ")) } 

नोट । var s []stringशीर्ष पर दो टिप्पणी लाइनों के समान, लेकिन उनके समान नहीं। शून्य के एक स्लाइस मान और शून्य लंबाई के एक स्लाइस मान के बीच अंतर होता है। निम्न कोड गलत प्रिंट करेगा।

 func main() { var s1 = []string{} var s2 []string fmt.Println(reflect.DeepEqual(s1, s2)) } 

एक उपयोगी, अनपेक्षित, अनइंस्टाल्ड पॉइंटर वैरिएबल की संपत्ति - एनआईएल पॉइंटर्स - उन तरीकों पर कॉल करने की क्षमता है जो शून्य हैं। इसका उपयोग आसानी से डिफ़ॉल्ट मान प्रदान करने के लिए किया जा सकता है।

 type Config struct { path string } func (c *Config) Path() string { if c == nil { return "/usr/home" } return c.path } func main() { var c1 *Config var c2 = &Config{ path: "/export", } fmt.Println(c1.Path(), c2.Path()) } 

4.5। पैकेज स्तर की स्थिति से बचें

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

गो में कमजोर कनेक्टिविटी को प्राप्त करने के दो शानदार तरीके हैं:

1. फ़ंक्शन या विधियों द्वारा आवश्यक व्यवहार का वर्णन करने के लिए इंटरफेस का उपयोग करें।
   
2. वैश्विक स्थिति से बचें।

गो में, हम किसी फ़ंक्शन या विधि के दायरे में, साथ ही एक पैकेज के दायरे में चर घोषित कर सकते हैं। जब एक चर सार्वजनिक रूप से एक पहचान पत्र के साथ पहचानकर्ता के साथ उपलब्ध होता है, तो इसका दायरा वास्तव में पूरे कार्यक्रम के लिए वैश्विक होता है: किसी भी समय कोई भी पैकेज इस चर के प्रकार और सामग्री को देखता है।

परिवर्तनशील वैश्विक स्थिति कार्यक्रम के स्वतंत्र भागों के बीच घनिष्ठ संबंध प्रदान करती है, क्योंकि वैश्विक चर कार्यक्रम में प्रत्येक फ़ंक्शन के लिए एक अदृश्य पैरामीटर बन जाते हैं! वैश्विक चर पर निर्भर किसी भी फ़ंक्शन का उल्लंघन किया जा सकता है जब इस चर के प्रकार में परिवर्तन होता है। कोई भी फ़ंक्शन जो वैश्विक चर की स्थिति पर निर्भर करता है, उसका उल्लंघन किया जा सकता है यदि प्रोग्राम का दूसरा भाग इस चर को बदलता है।

वैश्विक वैरिएबल बनाने वाली कनेक्टिविटी को कैसे कम करें:

1. संबंधित चर को उन संरचनाओं के क्षेत्र के रूप में स्थानांतरित करें जिनकी उन्हें आवश्यकता है।
   
2. व्यवहार और इस व्यवहार के कार्यान्वयन के बीच संबंध को कम करने के लिए इंटरफेस का उपयोग करें।

5. परियोजना संरचना

आइए इस बारे में बात करते हैं कि पैकेज को एक परियोजना में कैसे जोड़ा जाता है। यह आमतौर पर एक एकल गिट रिपॉजिटरी है।

पैकेज की तरह, प्रत्येक परियोजना का एक स्पष्ट लक्ष्य होना चाहिए। यदि यह एक पुस्तकालय है, तो यह एक काम करना चाहिए, उदाहरण के लिए, XML पार्सिंग या जर्नलिंग। आपको एक परियोजना में कई लक्ष्यों को संयोजित नहीं करना चाहिए, इससे डरावने पुस्तकालय से बचने में मदद मिलेगी common।

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

यदि आपके पास कोई एप्लिकेशन (वेब ​​एप्लिकेशन, कुबेरनेट्स नियंत्रक, आदि) है, तो प्रोजेक्ट में एक या अधिक मुख्य पैकेज हो सकते हैं। उदाहरण के लिए, मेरे कुबेरनेट्स नियंत्रक में एक पैकेज है cmd/contourजो कुबेरनेट क्लस्टर में तैनात सर्वर के रूप में और डिबग क्लाइंट के रूप में कार्य करता है।

5.1। कम पैकेज, लेकिन बड़ा

कोड समीक्षा में, मैंने प्रोग्रामर की विशिष्ट गलतियों में से एक को देखा, जो अन्य भाषाओं से गो पर स्विच करते थे: वे पैकेज का दुरुपयोग करते हैं।

जाओ दृश्यता की व्यापक व्यवस्था प्रदान नहीं करता है: भाषा जावा में के रूप में पर्याप्त पहुँच संशोधक (नहीं है public, protected, privateऔर निहित default)। C ++ से अनुकूल कक्षाओं का कोई एनालॉग नहीं है।

गो में, हमारे पास केवल दो एक्सेस मॉडिफायर हैं: ये सार्वजनिक और निजी पहचानकर्ता हैं, जो कि पहचानकर्ता (अपरकेस / लोअरकेस) के पहले अक्षर द्वारा इंगित किया गया है। यदि पहचानकर्ता सार्वजनिक है, तो उसका नाम एक बड़े अक्षर से शुरू होता है, इसे किसी भी अन्य गो पैकेज द्वारा संदर्भित किया जा सकता है।

नोट । आप सार्वजनिक और निजी शब्दों के समानार्थक शब्द "निर्यात" या "निर्यात नहीं" सुन सकते हैं।

सीमित अभिगम नियंत्रण सुविधाओं को देखते हुए, अत्यधिक जटिल पैकेज पदानुक्रम से बचने के लिए किन विधियों का उपयोग किया जा सकता है?

टिप । प्रत्येक पैकेज में, इसके अलावा cmd/और internal/स्रोत कोड मौजूद होना चाहिए।

मैंने बार-बार कहा है कि कम बड़े पैकेट पसंद करना बेहतर है। आपका डिफ़ॉल्ट स्थान एक नया पैकेज नहीं बनाना चाहिए। यह कई प्रकार के सार्वजनिक होने का कारण बनता है, जो उपलब्ध API का एक विस्तृत और छोटा दायरा बनाता है। नीचे हम इस थीसिस पर अधिक विस्तार से विचार करते हैं।

टिप । जावा से आया है?

यदि आप जावा या सी # दुनिया से आते हैं, तो अनिर्दिष्ट नियम को याद रखें: एक जावा पैकेज एक एकल स्रोत फ़ाइल के बराबर है .go। गो पैकेज पूरे मावेन मॉड्यूल या .NET असेंबली के बराबर है।

5.1.1। आयात निर्देशों का उपयोग करके फ़ाइल द्वारा कोड क्रमित करना

यदि आप पैकेज को सेवा द्वारा व्यवस्थित करते हैं, तो क्या आपको पैकेज में फ़ाइलों के लिए भी ऐसा ही करना चाहिए? कैसे पता करें कि कब एक फाइल .goको कई में विभाजित किया जाए? आपको कैसे पता चलेगा कि आप बहुत दूर चले गए हैं और फाइलों को मर्ज करने के बारे में सोचने की जरूरत है?

यहां वे सिफारिशें हैं जिनका मैं उपयोग करता हूं:

• एक फ़ाइल के साथ प्रत्येक पैकेज शुरू करें .go। इस फ़ाइल को निर्देशिका के समान नाम दें। उदाहरण के लिए, पैकेज एक निर्देशिका httpमें एक फ़ाइल http.goमें होना चाहिए http।
  
• जैसे ही पैकेज बढ़ता है, आप विभिन्न कार्यों को कई फाइलों में विभाजित कर सकते हैं। उदाहरण के लिए, फ़ाइल messages.goमें प्रकार Requestऔर Response, फ़ाइल client.goप्रकार Client, फ़ाइल server.goप्रकार सर्वर होगा।
  
• , . , .
  
• . , messages.go HTTP- , http.go , client.go server.go — HTTP .

. .

. Go . ( — Go). .

5.1.2। बाहरी को आंतरिक परीक्षण पसंद करते हैं

उपकरण दो स्थानों पर goपैकेज का समर्थन करता है testing। यदि आपके पास एक पैकेज है http2, तो आप एक फ़ाइल लिख सकते http2_test.goहैं और पैकेज घोषणा का उपयोग कर सकते हैं http2। यह कोड संकलित http2_test.go, के रूप में यह पैकेज का हिस्सा है http2। बोलचाल की भाषा में, इस तरह के परीक्षण को आंतरिक कहा जाता है।

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

मैं यूनिट यूनिट परीक्षणों के लिए आंतरिक परीक्षणों का उपयोग करने की सलाह देता हूं। यह आपको बाहरी परीक्षण की नौकरशाही से बचते हुए, प्रत्येक फ़ंक्शन या पद्धति का सीधे परीक्षण करने की अनुमति देता है।

लेकिन परीक्षण कार्यों ( ) के उदाहरणों को बाहरी परीक्षण फ़ाइल में रखना आवश्यक है Example। यह सुनिश्चित करता है कि जब गोडॉक में देखा जाता है, तो उदाहरण उपयुक्त पैकेज उपसर्ग प्राप्त करेंगे और आसानी से कॉपी किए जा सकते हैं।

. , .

, , Go go . , net/http net .

.go , , .

5.1.3. , API

यदि आपकी परियोजना में कई पैकेज हैं, तो आप निर्यात किए गए फ़ंक्शंस पा सकते हैं, जिनका उपयोग अन्य पैकेजों द्वारा किया जाना है, लेकिन सार्वजनिक एपीआई के लिए नहीं। ऐसी स्थिति में, उपकरण goएक विशेष फ़ोल्डर नाम को पहचानता internal/है जिसका उपयोग कोड रखने के लिए किया जा सकता है जो आपकी परियोजना के लिए खुला है, लेकिन दूसरों के लिए बंद है।

इस तरह के पैकेज को बनाने के लिए, इसे डायरेक्ट्री में नाम internal/या इसकी उपनिर्देशिका में रखें। जब टीम goपैकेज के आयात को पथ के साथ देखती है internal, तो यह निर्देशिका या उपनिर्देशिका में कॉलिंग पैकेज के स्थान की जांच करता है internal/।

उदाहरण के लिए, एक पैकेज .../a/b/c/internal/d/e/fडायरेक्टरी ट्री से केवल एक पैकेज आयात कर सकता है .../a/b/c, लेकिन सभी .../a/b/gया किसी अन्य रिपॉजिटरी में नहींप्रलेखन )।

5.2। सबसे छोटा मुख्य पैकेज

एक फ़ंक्शन mainऔर पैकेज mainमें न्यूनतम कार्यक्षमता होनी चाहिए, क्योंकि यह main.mainएक सिंगलटन की तरह कार्य करता है: एक प्रोग्राम में केवल एक फ़ंक्शन हो सकता है main, जिसमें परीक्षण शामिल हैं।

चूंकि यह main.mainएक सिंगलटन है, इसलिए ऑब्जेक्ट्स पर कई प्रतिबंध हैं: उन्हें केवल main.mainया उसके दौरान main.init, और केवल एक बार कहा जाता है । इससे कोड के लिए लेखन परीक्षण कठिन हो जाता है main.main। इस प्रकार, आपको मुख्य फ़ंक्शन से और यथासंभव आदर्श रूप से, मुख्य पैकेज से अधिक तर्क प्राप्त करने का प्रयास करने की आवश्यकता है।

टिप । func main()झंडे, डेटाबेस, लॉगर, इत्यादि के लिए खुले कनेक्शन का विश्लेषण करना चाहिए, और फिर निष्पादन को उच्च-स्तरीय ऑब्जेक्ट में स्थानांतरित करना चाहिए।

6. एपीआई संरचना

परियोजना के लिए अंतिम डिजाइन सलाह मैं सबसे महत्वपूर्ण मानता हूं।

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

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

जब यह सार्वजनिक एपीआई की बात आती है, तो यह शुरुआत से ही संरचना पर गंभीरता से विचार करने के लायक है, क्योंकि बाद के बदलाव उपयोगकर्ताओं के लिए विनाशकारी होंगे।

6.1। डिजाइन एपीआई जो डिजाइन द्वारा दुरुपयोग करने के लिए कठिन हैं

"एपीआई उचित उपयोग के लिए सरल और गलत के लिए मुश्किल होना चाहिए" - जोश बलोच

जोश बलोच की सलाह शायद इस लेख में सबसे मूल्यवान है। यदि एपीआई सरल चीजों के लिए उपयोग करना मुश्किल है, तो प्रत्येक एपीआई कॉल आवश्यक से अधिक जटिल है। जब कोई API कॉल जटिल और अप्रकाशित होती है, तो इसे अनदेखा कर दिया जाता है।

6.1.1। उन कार्यों से सावधान रहें जो एक ही प्रकार के कई मापदंडों को स्वीकार करते हैं।

पहली नज़र में एक सरल का एक अच्छा उदाहरण, लेकिन एपीआई का उपयोग करना मुश्किल है, जब इसे एक ही प्रकार के दो या अधिक मापदंडों की आवश्यकता होती है। दो फ़ंक्शन हस्ताक्षरों की तुलना करें:

 func Max(a, b int) int func CopyFile(to, from string) error 

इन दोनों कार्यों में क्या अंतर है? जाहिर है, एक अधिकतम दो नंबर लौटाता है, और दूसरा फाइल कॉपी करता है। लेकिन यह बात नहीं है।

 Max(8, 10) // 10 Max(10, 8) // 10 

अधिकतम सराहनीय है : मापदंडों का क्रम मायने नहीं रखता है। आठ और दस की अधिकतम संख्या दस है, चाहे आठ और दस या दस और आठ की तुलना की जाए।

लेकिन CopyFile के मामले में, ऐसा नहीं है।

 CopyFile("/tmp/backup", "presentation.md") CopyFile("presentation.md", "/tmp/backup") 

इनमें से कौन सा ऑपरेटर आपकी प्रस्तुति का बैकअप लेगा, और जो इसे पिछले सप्ताह के संस्करण के साथ अधिलेखित कर देगा? जब तक आप दस्तावेज़ की जांच नहीं करते तब तक आप नहीं बता सकते कोड समीक्षा के दौरान, यह स्पष्ट नहीं है कि तर्कों का क्रम सही है या नहीं। फिर से, प्रलेखन देखें।

एक संभावित समाधान एक सहायक प्रकार का परिचय देना है जो सही कॉल के लिए जिम्मेदार है CopyFile।

 type Source string func (src Source) CopyTo(dest string) error { return CopyFile(dest, string(src)) } func main() { var from Source = "presentation.md" from.CopyTo("/tmp/backup") } 

इसे CopyFileहमेशा यहां सही ढंग से कहा जाता है - यह एक इकाई परीक्षण का उपयोग करके कहा जा सकता है - और निजी किया जा सकता है, जो आगे गलत उपयोग की संभावना को कम करता है।

टिप । एक ही प्रकार के कई मापदंडों वाला एपीआई सही ढंग से उपयोग करना मुश्किल है।

6.2। एक बेसिक उपयोग के मामले के लिए एक एपीआई डिजाइन

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

6.2.1। एक पैरामीटर के रूप में शून्य का उपयोग करने की अनुशंसा नहीं की जाती है

मैंने यह कहकर शुरुआत की कि आपको उपयोगकर्ता को एपीआई पैरामीटर प्रदान करने के लिए मजबूर नहीं करना चाहिए जो उसे ब्याज नहीं देते हैं। इसका मतलब है मुख्य उपयोग के मामले के लिए एपीआई (डिफ़ॉल्ट विकल्प) डिजाइन करना।

यहां नेट / http पैकेज से एक उदाहरण दिया गया है।

 package http // ListenAndServe listens on the TCP network address addr and then calls // Serve with handler to handle requests on incoming connections. // Accepted connections are configured to enable TCP keep-alives. // // The handler is typically nil, in which case the DefaultServeMux is used. // // ListenAndServe always returns a non-nil error. func ListenAndServe(addr string, handler Handler) error { 

ListenAndServeदो मापदंडों को स्वीकार करता है: आने वाले कनेक्शनों को सुनने और http.Handlerआने वाले HTTP अनुरोध को संसाधित करने के लिए एक टीसीपी पता । Serveदूसरे पैरामीटर की अनुमति देता है nil। टिप्पणियों में, यह ध्यान दिया जाता है कि आमतौर पर कॉलिंग ऑब्जेक्ट वास्तव में पास होगा nil, जो इसे http.DefaultServeMuxएक अंतर्निहित पैरामीटर के रूप में उपयोग करने की इच्छा दर्शाता है ।

अब कॉलर के Serveपास भी ऐसा करने के दो तरीके हैं।

 http.ListenAndServe("0.0.0.0:8080", nil) http.ListenAndServe("0.0.0.0:8080", http.DefaultServeMux) 

दोनों विकल्प एक ही काम करते हैं।

यह एप्लिकेशन nilवायरस की तरह फैलता है। पैकेज httpमें एक सहायक भी है http.Serve, जिससे आप फ़ंक्शन की संरचना की कल्पना कर सकते हैं ListenAndServe:

 func ListenAndServe(addr string, handler Handler) error { l, err := net.Listen("tcp", addr) if err != nil { return err } defer l.Close() return Serve(l, handler) } 

चूंकि ListenAndServeयह कॉल करने वाले को nilदूसरे पैरामीटर के लिए पास करने की अनुमति देता है , इसलिए http.Serveयह इस व्यवहार का समर्थन भी करता है। वास्तव में, यह http.Serveलागू तर्क में है "यदि हैंडलर समान है nil, तो उपयोग करें DefaultServeMux"। nilएक पैरामीटर के लिए स्वीकृति कॉलर को यह सोचने के लिए प्रेरित कर सकती है कि इसे nilदोनों मापदंडों के लिए पारित किया जा सकता है । लेकिन ऐसेServe

 http.Serve(nil, nil) 

एक भयानक आतंक की ओर जाता है।

टिप । एक ही फ़ंक्शन सिग्नेचर में पैरामीटर न मिलाएं nilऔर न ही nil।

लेखक http.ListenAndServeने डिफ़ॉल्ट मामले के लिए एपीआई उपयोगकर्ताओं के जीवन को आसान बनाने की कोशिश की, लेकिन सुरक्षा प्रभावित हुई।

उपस्थिति में, nilस्पष्ट और अप्रत्यक्ष उपयोग के बीच की लाइनों की संख्या में कोई अंतर नहीं है DefaultServeMux।

  const root = http.Dir("/htdocs") http.Handle("/", http.FileServer(root)) http.ListenAndServe("0.0.0.0:8080", nil) 

की तुलना में

  const root = http.Dir("/htdocs") http.Handle("/", http.FileServer(root)) http.ListenAndServe("0.0.0.0:8080", http.DefaultServeMux) 

क्या एक लाइन रखना भ्रम के लायक था?

  const root = http.Dir("/htdocs") mux := http.NewServeMux() mux.Handle("/", http.FileServer(root)) http.ListenAndServe("0.0.0.0:8080", mux) 

टिप । इस बात पर गंभीरता से विचार करें कि हेल्पर फ़ंक्शन प्रोग्रामर को कितने समय में बचाएगा। स्पष्टता संक्षिप्तता से बेहतर है।

टिप । सार्वजनिक API से उन मापदंडों से बचें जो केवल परीक्षणों की आवश्यकता है। उन एपीआई के निर्यात से बचें, जिनका मान परीक्षण के दौरान ही भिन्न होता है। इसके बजाय, निर्यात आवरण फ़ंक्शन जो ऐसे मापदंडों के हस्तांतरण को छिपाते हैं, और परीक्षणों में समान सहायक कार्यों का उपयोग करते हैं जो परीक्षण के लिए आवश्यक मानों को पास करते हैं।

6.2.2। [] T के बजाय परिवर्तनीय लंबाई के तर्कों का उपयोग करें

बहुत बार, एक फ़ंक्शन या विधि मानों का एक टुकड़ा लेती है।

 func ShutdownVMs(ids []string) error 

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

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

इस तरह के एक एपीआई वर्ग का एक उदाहरण देने के लिए, मैंने हाल ही में तर्क-वितर्क किया, जिसमें कुछ अतिरिक्त क्षेत्रों की स्थापना की आवश्यकता होती थी, यदि कम से कम एक पैरामीटर नॉनज़रो होता। तर्क कुछ इस तरह दिखता था:

 if svc.MaxConnections > 0 || svc.MaxPendingRequests > 0 || svc.MaxRequests > 0 || svc.MaxRetries > 0 { // apply the non zero parameters } 

चूंकि ऑपरेटर ifबहुत लंबा हो रहा था, इसलिए मैं सत्यापन तर्क को एक अलग फ़ंक्शन में खींचना चाहता था। यहाँ मैं क्या लेकर आया हूँ:

 // anyPostive indicates if any value is greater than zero. func anyPositive(values ...int) bool { for _, v := range values { if v > 0 { return true } } return false } 

इससे उस स्थिति को स्पष्ट रूप से बताना संभव हो गया जिसके तहत इनडोर इकाई को निष्पादित किया जाएगा:

 if anyPositive(svc.MaxConnections, svc.MaxPendingRequests, svc.MaxRequests, svc.MaxRetries) { // apply the non zero parameters } 

हालांकि, इसके साथ एक समस्या है anyPositive, कोई गलती से इसे इस तरह कह सकता है:

 if anyPositive() { ... } 

उस मामले में, anyPositiveवापस आ जाएगी false। यह सबसे बुरा विकल्प नहीं है। इससे भी बदतर अगर तर्कों के अभाव में anyPositiveलौटे true।

हालांकि, यह सुनिश्चित करने के लिए किसी भी पॉजिटिव के हस्ताक्षर को बदलने में सक्षम होना बेहतर होगा कि कॉल करने वाले को कम से कम एक तर्क दिया जाए। यह सामान्य तर्कों और चर-लंबाई तर्कों (वैरगेज) के लिए मापदंडों को मिलाकर किया जा सकता है:

 // anyPostive indicates if any value is greater than zero. func anyPositive(first int, rest ...int) bool { if first > 0 { return true } for _, v := range rest { if v > 0 { return true } } return false } 

अब anyPositiveआप एक से कम तर्क के साथ नहीं बुला सकते।

6.3। कार्यों को वांछित व्यवहार निर्धारित करने दें।

मान लीजिए मुझे एक फ़ंक्शन लिखने का काम दिया गया था जो Documentडिस्क पर संरचना को संरक्षित करता है ।

 // Save      f. func Save(f *os.File, doc *Document) error 

मैं एक फंक्शन लिख सकता हूं Saveजो Documentएक फाइल पर लिखता है *os.File। लेकिन कुछ समस्याएं हैं।

हस्ताक्षर Saveनेटवर्क पर डेटा रिकॉर्ड करने की संभावना को समाप्त करता है। यदि भविष्य में ऐसी आवश्यकता दिखाई देती है, तो फ़ंक्शन के हस्ताक्षर को बदलना होगा, जो सभी कॉलिंग ऑब्जेक्ट को प्रभावित करेगा।

Saveयह परीक्षण करने के लिए भी अप्रिय है, क्योंकि यह डिस्क पर फ़ाइलों के साथ सीधे काम करता है। इस प्रकार, इसके संचालन को सत्यापित करने के लिए, परीक्षण को लिखने के बाद फ़ाइल की सामग्री को पढ़ना चाहिए।

और मुझे यह सुनिश्चित करना होगा कि यह fएक अस्थायी फ़ोल्डर में लिखा गया है और बाद में हटा दिया गया है।

*os.Fileकई तरीकों को भी परिभाषित करता है जो संबंधित नहीं हैं Save, उदाहरण के लिए, निर्देशिकाओं को पढ़ना और यह जांचना कि क्या कोई पथ एक प्रतीकात्मक लिंक है। खैर, अगर हस्ताक्षरSaveकेवल प्रासंगिक भागों का वर्णन किया *os.File।

क्या किया जा सकता है?

 // Save      // ReadWriterCloser. func Save(rwc io.ReadWriteCloser, doc *Document) error 

इसकी मदद से io.ReadWriteCloserआप इंटरफ़ेस पृथक्करण के सिद्धांत को लागू कर सकते हैं - और इसे Saveउस इंटरफ़ेस पर फिर से परिभाषित करें जो फ़ाइल के अधिक सामान्य गुणों का वर्णन करता है।

इस तरह के बदलाव के बाद, इंटरफ़ेस io.ReadWriteCloserको लागू करने वाले किसी भी प्रकार को पिछले एक के साथ बदल दिया जा सकता है *os.File।

यह एक साथ दायरे का विस्तार करता है Saveऔर कॉलर को स्पष्ट करता है कि किस प्रकार के तरीके *os.Fileइसके संचालन से संबंधित हैं।

और लेखक Saveअब इन असंबंधित तरीकों को नहीं कह सकता है *os.File, क्योंकि वह इंटरफ़ेस के पीछे छिपा हुआ है io.ReadWriteCloser।

लेकिन हम इंटरफ़ेस पृथक्करण के सिद्धांत को और भी आगे बढ़ा सकते हैं।

सबसे पहले अगरSave एकल जिम्मेदारी के सिद्धांत का पालन करता है, यह संभावना नहीं है कि वह उस फ़ाइल को पढ़ेगा जो उसने सिर्फ अपनी सामग्री की जांच करने के लिए लिखा था - अन्य कोड को ऐसा करना चाहिए।

 // Save      // WriteCloser. func Save(wc io.WriteCloser, doc *Document) error 

इसलिए, आप इंटरफ़ेस के विनिर्देशों को Saveकेवल लिखने और बंद करने के लिए संकीर्ण कर सकते हैं ।

दूसरे, थ्रेड क्लोजिंग मैकेनिज्म y Saveउस समय की विरासत है जब उसने फ़ाइल के साथ काम किया था। सवाल यह है कि किन परिस्थितियों wcमें इसे बंद किया जाएगा।

चाहे Saveकारण Closeबिना शर्त, चाहे सफलता के मामले में।

यह कॉल करने वाले के लिए एक समस्या प्रस्तुत करता है क्योंकि वह दस्तावेज़ लिखे जाने के बाद धारा में डेटा जोड़ना चाह सकता है।

 // Save      // Writer. func Save(w io.Writer, doc *Document) error 

सबसे अच्छा विकल्प केवल io.Writerडेटा को स्ट्रीम के लिए लिखने के अलावा, अन्य सभी कार्यक्षमता से ऑपरेटर को बचाने के साथ काम को फिर से परिभाषित करना है।

इंटरफ़ेस पृथक्करण के सिद्धांत को लागू करने के बाद, एक ही समय में फ़ंक्शन आवश्यकताओं के संदर्भ में दोनों अधिक विशिष्ट बन गया (इसे केवल एक ऑब्जेक्ट की आवश्यकता है जहां इसे लिखा जा सकता है) और कार्यक्षमता के संदर्भ में अधिक सामान्य है, क्योंकि अब हम इसका उपयोग Saveडेटा को बचाने के लिए कर सकते हैं जहां कहीं भी इसे लागू किया जाता है io.Writer।

7. हैंडलिंग में त्रुटि

मैंने कई प्रस्तुतियाँ दीं और ब्लॉग पर इस विषय पर बहुत कुछ लिखा , इसलिए मैंने इसे दोहराया नहीं।

इसके बजाय, मैं एरर हैंडलिंग से संबंधित दो अन्य क्षेत्रों को कवर करना चाहता हूं।

7.1। त्रुटियों को स्वयं हटाकर त्रुटि से निपटने की आवश्यकता को समाप्त करें

मैंने सिंटैक्स में त्रुटि को सुधारने के लिए कई सुझाव दिए, लेकिन सबसे अच्छा विकल्प उन्हें संभालना नहीं है।

नोट । मैं नहीं कहता "त्रुटि से निपटने को हटाएं"। मैं कोड को बदलने का सुझाव देता हूं ताकि प्रसंस्करण के लिए कोई त्रुटि न हो।

जॉन ओस्टरहौट की हालिया सॉफ्टवेयर विकास दर्शन पुस्तक ने मुझे यह सुझाव देने के लिए प्रेरित किया । अध्यायों में से एक "वास्तविकता से त्रुटियों को खत्म करने" का हकदार है। आइए इस सलाह को लागू करने का प्रयास करें।

7.1.1। पंक्ति की गिनती

हम एक फ़ाइल में लाइनों की संख्या की गणना करने के लिए एक फ़ंक्शन लिखेंगे।

 func CountLines(r io.Reader) (int, error) { var ( br = bufio.NewReader(r) lines int err error ) for { _, err = br.ReadString('\n') lines++ if err != nil { break } } if err != io.EOF { return 0, err } return lines, nil } 

जैसा कि हम पिछले वर्गों से सलाह का पालन करते हैं, CountLinesस्वीकार करते हैं io.Reader, नहीं *os.File; यह पहले से ही कॉल करने वाले का काम है कि io.Readerहम किसकी सामग्री को गिनना चाहते हैं।

हम बनाते हैं bufio.Reader, और फिर विधि को एक लूप में कॉल करते हैं ReadString, काउंटर बढ़ाते हैं, जब तक हम फ़ाइल के अंत तक नहीं पहुंचते हैं, तब हम पढ़ी गई लाइनों की संख्या वापस करते हैं।

कम से कम हम ऐसे कोड लिखना चाहते हैं, लेकिन फ़ंक्शन त्रुटि हैंडलिंग के बोझ से दब जाता है। उदाहरण के लिए, इस तरह का एक अजीब निर्माण है:

  _, err = br.ReadString('\n') lines++ if err != nil { break } 

हम त्रुटियों की जांच करने से पहले लाइनों की संख्या बढ़ाते हैं - यह अजीब लगता है।

हमें इसे इस तरह लिखना चाहिए क्योंकि यह ReadStringएक त्रुटि लौटाएगा यदि यह फ़ाइल के अंत का सामना नए वर्ण से करता है। ऐसा तब हो सकता है जब फ़ाइल के अंत में कोई नई लाइन न हो।

इसे ठीक करने का प्रयास करने के लिए, पंक्ति काउंटर के तर्क को बदलें, और फिर देखें कि क्या हमें लूप से बाहर निकलने की आवश्यकता है।

नोट । यह तर्क अभी भी सही नहीं है, क्या आप गलती पा सकते हैं?

लेकिन हमने त्रुटियों की जाँच पूरी नहीं की है। जब यह फ़ाइल के अंत का सामना ReadStringकरेगा तो वापस आ जाएगा io.EOF। यह अपेक्षित स्थिति है, इसलिए ReadStringआपको "रुकने के लिए" कहने के लिए कुछ करने की ज़रूरत है, पढ़ने के लिए अधिक कुछ नहीं है। इसलिए, कॉलिंग ऑब्जेक्ट में त्रुटि लौटने से पहले CountLine, आपको यह जांचने की आवश्यकता है कि त्रुटि संबंधित नहीं है io.EOF, और फिर इसे पास करें, अन्यथा हम लौटते हैं nilऔर कहते हैं कि सब कुछ ठीक है।

मुझे लगता है कि यह रस्क कॉक्स की थीसिस का एक अच्छा उदाहरण है कि त्रुटि को कैसे फ़ंक्शन छिपा सकता है। आइए बेहतर संस्करण देखें।

 func CountLines(r io.Reader) (int, error) { sc := bufio.NewScanner(r) lines := 0 for sc.Scan() { lines++ } return lines, sc.Err() } 

इसके bufio.Scannerबजाय यह बेहतर संस्करण उपयोग करता है bufio.Reader।

हुड bufio.Scannerउपयोग के तहत bufio.Reader, लेकिन अमूर्तता का एक अच्छा स्तर जोड़ता है, जो त्रुटि से निपटने में मदद करता है।

. bufio.Scanner , .

यदि स्कैनर ने एक स्ट्रिंग का सामना किया और कोई त्रुटि नहीं मिली, तो विधि sc.Scan()एक मान लौटाती है true। इस प्रकार, लूप बॉडी को forकेवल तभी कहा जाता है जब स्कैनर बफर में पाठ की एक पंक्ति होती है। इसका मतलब यह है कि नया CountLinesतब मामलों को संभालता है जब कोई नई लाइन नहीं होती है या जब फाइल खाली होती है।

दूसरे, चूंकि यह त्रुटि का पता चलने पर sc.Scanवापस लौटता falseहै, forफ़ाइल के अंत तक पहुंचने पर चक्र समाप्त होता है या त्रुटि का पता चलता है। प्रकार bufio.Scannerउस पहली त्रुटि को याद करता है जो उसे सामना करना पड़ा, और विधि का उपयोग करके sc.Err()हम लूप से बाहर निकलते ही उस त्रुटि को पुनर्स्थापित कर सकते हैं।

अंत में, यह sc.Err()प्रोसेसिंग का ध्यान रखता है io.EOFऔर nilयदि फ़ाइल का अंत बिना त्रुटियों के हो जाता है , तो इसे कनवर्ट करता है ।

टिप । यदि आप अत्यधिक त्रुटि से निपटने का सामना करते हैं, तो कुछ ऑपरेशनों को सहायक प्रकार में निकालने का प्रयास करें।

7.1.2। WriteResponse

मेरा दूसरा उदाहरण "गलतियाँ मान रहे हैं" पोस्ट से प्रेरित है ।

पहले हमने उदाहरण देखे कि किसी फ़ाइल को कैसे खोला, लिखा और बंद किया जाता है। त्रुटि से निपटने में मदद मिलती है, लेकिन यह बहुत अधिक नहीं है, क्योंकि सहायकों में ऑपरेशन को समझाया जा सकता है, जैसे ioutil.ReadFileऔर ioutil.WriteFile। लेकिन जब निम्न-स्तरीय नेटवर्क प्रोटोकॉल के साथ काम करते हैं, तो I / O प्राइमेटिव का उपयोग करके सीधे उत्तर बनाने की आवश्यकता होती है। इस स्थिति में, त्रुटि हैंडलिंग घुसपैठ बन सकती है। एक HTTP सर्वर के एक टुकड़े पर विचार करें जो एक HTTP प्रतिक्रिया बनाता है।

 type Header struct { Key, Value string } type Status struct { Code int Reason string } func WriteResponse(w io.Writer, st Status, headers []Header, body io.Reader) error { _, err := fmt.Fprintf(w, "HTTP/1.1 %d %s\r\n", st.Code, st.Reason) if err != nil { return err } for _, h := range headers { _, err := fmt.Fprintf(w, "%s: %s\r\n", h.Key, h.Value) if err != nil { return err } } if _, err := fmt.Fprint(w, "\r\n"); err != nil { return err } _, err = io.Copy(w, body) return err } 

सबसे पहले, स्थिति पट्टी का निर्माण fmt.Fprintfकरें और त्रुटि की जांच करें। फिर प्रत्येक हेडिंग के लिए हम एक कुंजी और हेडिंग वैल्यू लिखते हैं, हर बार एक त्रुटि की जाँच करते हैं। अंत में, हम हेडर अनुभाग को एक अतिरिक्त के साथ पूरा करते हैं \r\n, त्रुटि की जांच करते हैं, और ग्राहक को प्रतिक्रिया निकाय की नकल करते हैं। अंत में, हालांकि हमें त्रुटि की जांच करने की आवश्यकता नहीं है io.Copy, हमें इसे दो रिटर्न मानों से केवल एक ही रिटर्न में बदलने की आवश्यकता है WriteResponse।

यह बहुत नीरस काम है। लेकिन आप छोटे प्रकार के रैपर लगाकर अपने काम को आसान कर सकते हैं errWriter।

errWriterअनुबंध को संतुष्ट करता है io.Writer, इसलिए इसे एक आवरण के रूप में इस्तेमाल किया जा सकता है। errWriterएक त्रुटि का पता चलने तक फ़ंक्शन के माध्यम से रिकॉर्ड पारित करता है। इस स्थिति में, यह प्रविष्टियों को अस्वीकार कर देता है और पिछली त्रुटि को लौटाता है।

 type errWriter struct { io.Writer err error } func (e *errWriter) Write(buf []byte) (int, error) { if e.err != nil { return 0, e.err } var n int n, e.err = e.Writer.Write(buf) return n, nil } func WriteResponse(w io.Writer, st Status, headers []Header, body io.Reader) error { ew := &errWriter{Writer: w} fmt.Fprintf(ew, "HTTP/1.1 %d %s\r\n", st.Code, st.Reason) for _, h := range headers { fmt.Fprintf(ew, "%s: %s\r\n", h.Key, h.Value) } fmt.Fprint(ew, "\r\n") io.Copy(ew, body) return ew.err } 

यदि इसे लागू किया errWriterजाता है WriteResponse, तो कोड की स्पष्टता में बहुत सुधार होता है। अब आपको प्रत्येक व्यक्तिगत ऑपरेशन में त्रुटियों की जांच करने की आवश्यकता नहीं है। त्रुटि संदेश फ़ंक्शन के अंत में एक फ़ील्ड चेक के रूप में चलता है ew.err, लौटे io.Copy मूल्यों के कष्टप्रद अनुवाद से बचता है।

7.2। केवल एक बार त्रुटि को संभालें

अंत में, मैं यह नोट करना चाहता हूं कि त्रुटियों को केवल एक बार नियंत्रित किया जाना चाहिए। प्रोसेसिंग का अर्थ है त्रुटि का अर्थ जाँचना और एकल निर्णय लेना।

 // WriteAll writes the contents of buf to the supplied writer. func WriteAll(w io.Writer, buf []byte) { w.Write(buf) } 

यदि आप एक से कम निर्णय लेते हैं, तो आप त्रुटि को अनदेखा करते हैं। जैसा कि हम यहां देखते हैं, त्रुटि को w.WriteAllनजरअंदाज किया जाता है।

लेकिन एक गलती के जवाब में एक से अधिक निर्णय लेना भी गलत है। नीचे वह कोड है जो मैं अक्सर भरता हूं।

 func WriteAll(w io.Writer, buf []byte) error { _, err := w.Write(buf) if err != nil { log.Println("unable to write:", err) // annotated error goes to log file return err // unannotated error returned to caller } return nil } 

इस उदाहरण में, यदि समय के दौरान कोई त्रुटि होती है w.Write, तो लाइन लॉग को लिखी जाती है, और उसे कॉलिंग ऑब्जेक्ट पर भी लौटा दिया जाता है, जो, शायद, उसे लॉग इन भी करेगा और प्रोग्राम के शीर्ष स्तर तक इसे पारित करेगा।

सबसे अधिक संभावना है, कॉलर एक ही करता है:

 func WriteConfig(w io.Writer, conf *Config) error { buf, err := json.Marshal(conf) if err != nil { log.Printf("could not marshal config: %v", err) return err } if err := WriteAll(w, buf); err != nil { log.Println("could not write config: %v", err) return err } return nil } 

इस प्रकार, लॉग में दोहराई जाने वाली लाइनों का एक स्टैक बनाया जाता है।

 unable to write: io.EOF could not write config: io.EOF 

लेकिन कार्यक्रम के शीर्ष पर आपको बिना किसी संदर्भ के एक मूल त्रुटि मिलती है।

 err := WriteConfig(f, &conf) fmt.Println(err) // io.EOF 

मैं इस विषय का अधिक विस्तार से विश्लेषण करना चाहता हूं, क्योंकि मैं एक साथ एक त्रुटि को वापस करने और अपनी व्यक्तिगत प्राथमिकताओं को लॉग करने की समस्या पर विचार नहीं करता हूं।

 func WriteConfig(w io.Writer, conf *Config) error { buf, err := json.Marshal(conf) if err != nil { log.Printf("could not marshal config: %v", err) // oops, forgot to return } if err := WriteAll(w, buf); err != nil { log.Println("could not write config: %v", err) return err } return nil } 

मैं अक्सर एक समस्या का सामना करता हूं जो एक प्रोग्रामर एक त्रुटि से वापस आना भूल जाता है। जैसा कि हमने पहले कहा, गो की शैली सीमा ऑपरेटरों का उपयोग करना है, पूर्वापेक्षाएँ जांचें क्योंकि फ़ंक्शन निष्पादित होता है, और जल्दी लौटता है।

इस उदाहरण में, लेखक ने त्रुटि की जाँच की, इसे पंजीकृत किया, लेकिन वापस लौटना भूल गया । इस वजह से, एक सूक्ष्म समस्या उत्पन्न होती है।

गो त्रुटि हैंडलिंग अनुबंध कहता है कि त्रुटि की उपस्थिति में, अन्य रिटर्न मानों की सामग्री के बारे में कोई धारणा नहीं बनाई जा सकती है। चूंकि JSON मार्शलिंग विफल हो गया है, सामग्री bufअज्ञात है: इसमें कुछ भी नहीं हो सकता है, लेकिन इससे भी बदतर, इसमें आधा-लिखित JSON संशोधन शामिल हो सकता है।

चूंकि प्रोग्रामर त्रुटि की जांच करने और पंजीकरण करने के बाद वापस आना भूल गया, इसलिए क्षतिग्रस्त बफर को स्थानांतरित किया जाएगा WriteAll। ऑपरेशन सफल होने की संभावना है, और इसलिए कॉन्फ़िगरेशन फ़ाइल सही ढंग से नहीं लिखी जाएगी। हालाँकि, फ़ंक्शन सामान्य रूप से पूरा होता है, और केवल संकेत है कि एक समस्या हुई है लॉग में एक पंक्ति है जहां JSON मार्शलिंग विफल हो गया है, और कॉन्फ़िगरेशन रिकॉर्ड विफलता नहीं है।

7.2.1। त्रुटियों के संदर्भ में जोड़ना

एक त्रुटि हुई क्योंकि लेखक त्रुटि संदेश के संदर्भ को जोड़ने का प्रयास कर रहा था। उन्होंने त्रुटि के स्रोत को इंगित करने के लिए एक निशान छोड़ने की कोशिश की।

आइए इसके माध्यम से एक ही तरीका देखें fmt.Errorf।

 func WriteConfig(w io.Writer, conf *Config) error { buf, err := json.Marshal(conf) if err != nil { return fmt.Errorf("could not marshal config: %v", err) } if err := WriteAll(w, buf); err != nil { return fmt.Errorf("could not write config: %v", err) } return nil } func WriteAll(w io.Writer, buf []byte) error { _, err := w.Write(buf) if err != nil { return fmt.Errorf("write failed: %v", err) } return nil } 

यदि आप त्रुटि रिकॉर्ड को एक पंक्ति में लौटने के साथ जोड़ते हैं, तो भूल जाना और आकस्मिक निरंतरता से बचने के लिए अधिक कठिन है।

यदि फ़ाइल लिखते समय I / O त्रुटि होती है, तो विधि Error()कुछ इस तरह उत्पन्न होगी:

 could not write config: write failed: input/output error 

7.2.2। Github.com/pkg/errors के साथ रैपिंग में त्रुटि

त्रुटि संदेशोंfmt.Errorf को रिकॉर्ड करने के लिए पैटर्न अच्छी तरह से काम करता है , लेकिन त्रुटि का प्रकार जिस तरह से होता है। मैंने तर्क दिया कि शिथिल युग्मित परियोजनाओं के लिए अपारदर्शी मानों के रूप में त्रुटियों को संभालना महत्वपूर्ण है , इसलिए स्रोत त्रुटि का प्रकार कोई फर्क नहीं पड़ता अगर हमें केवल इसके मूल्य के साथ काम करने की आवश्यकता है:

1. सुनिश्चित करें कि यह शून्य नहीं है।
   
2. इसे स्क्रीन पर प्रदर्शित करें या लॉग इन करें।

हालाँकि, ऐसा होता है कि आपको मूल त्रुटि को पुनर्स्थापित करने की आवश्यकता होती है। ऐसी त्रुटियों की व्याख्या करने के लिए, आप मेरे पैकेज की तरह कुछ का उपयोग कर सकते हैं errors:

 func ReadFile(path string) ([]byte, error) { f, err := os.Open(path) if err != nil { return nil, errors.Wrap(err, "open failed") } defer f.Close() buf, err := ioutil.ReadAll(f) if err != nil { return nil, errors.Wrap(err, "read failed") } return buf, nil } func ReadConfig() ([]byte, error) { home := os.Getenv("HOME") config, err := ReadFile(filepath.Join(home, ".settings.xml")) return config, errors.WithMessage(err, "could not read config") } func main() { _, err := ReadConfig() if err != nil { fmt.Println(err) os.Exit(1) } } 

अब संदेश एक अच्छा कश्मीर और डी-स्टाइल बग बन जाता है:

 could not read config: open failed: open /Users/dfc/.settings.xml: no such file or directory 

और इसके मूल्य में मूल कारण का लिंक है।

 func main() { _, err := ReadConfig() if err != nil { fmt.Printf("original error: %T %v\n", errors.Cause(err), errors.Cause(err)) fmt.Printf("stack trace:\n%+v\n", err) os.Exit(1) } } 

इस प्रकार, आप मूल त्रुटि को पुनर्स्थापित कर सकते हैं और स्टैक ट्रेस प्रदर्शित कर सकते हैं:

 original error: *os.PathError open /Users/dfc/.settings.xml: no such file or directory stack trace: open /Users/dfc/.settings.xml: no such file or directory open failed main.ReadFile /Users/dfc/devel/practical-go/src/errors/readfile2.go:16 main.ReadConfig /Users/dfc/devel/practical-go/src/errors/readfile2.go:29 main.main /Users/dfc/devel/practical-go/src/errors/readfile2.go:35 runtime.main /Users/dfc/go/src/runtime/proc.go:201 runtime.goexit /Users/dfc/go/src/runtime/asm_amd64.s:1333 could not read config 

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

8. संगति

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

गो के शीर्ष पायदान संगामिति समर्थन चैनलों द्वारा प्रदान किया जाता है, साथ ही निर्देश selectऔरgo। यदि आपने पाठ्यपुस्तकों या किसी विश्वविद्यालय से गो सिद्धांत का अध्ययन किया है, तो आपने देखा होगा कि समानांतरता खंड हमेशा पाठ्यक्रम में अंतिम में से एक होता है। हमारा लेख अलग नहीं है: मैंने अंत में समानता के बारे में बात करने का फैसला किया, क्योंकि सामान्य प्रोग्रामर को कुछ और सीखना चाहिए जो कि गो प्रोग्रामर को सीखना चाहिए।

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

इस खंड में गो संगति कार्यों के भोले उपयोग के कुछ नुकसान पर चर्चा की गई है।

8.1। हर समय कुछ काम करें।

इस कार्यक्रम में क्या समस्या है?

 package main import ( "fmt" "log" "net/http" ) func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Hello, GopherCon SG") }) go func() { if err := http.ListenAndServe(":8080", nil); err != nil { log.Fatal(err) } }() for { } } 

कार्यक्रम वही करता है जो हमने इरादा किया था: यह एक साधारण वेब सर्वर पर कार्य करता है। उसी समय, यह एक अनंत लूप में सीपीयू समय बिताता है, क्योंकि for{}अंतिम पंक्ति में यह mainगोरूटिन मुख्य को अवरुद्ध करता है, बिना किसी आई / ओ के प्रदर्शन के बिना, अवरुद्ध करने, संदेश भेजने या प्राप्त करने, या किसी तरह के कनेक्शन के साथ प्रतीक्षा नहीं करनी होती है।

चूंकि गो रनटाइम आमतौर पर एक शेडयूलर द्वारा परोसा जाता है, इसलिए यह प्रोग्राम प्रोसेसर पर बेवजह चलेगा और सक्रिय लॉक (लाइव-लॉक) में समाप्त हो सकता है।

इसे कैसे ठीक करें? यहाँ एक विकल्प है।

 package main import ( "fmt" "log" "net/http" "runtime" ) func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Hello, GopherCon SG") }) go func() { if err := http.ListenAndServe(":8080", nil); err != nil { log.Fatal(err) } }() for { runtime.Gosched() } } 

यह मूर्खतापूर्ण लग सकता है, लेकिन यह एक सामान्य समाधान है जो वास्तविक जीवन में मेरे सामने आता है। यह अंतर्निहित समस्या की गलतफहमी का एक लक्षण है।

यदि आप गो के साथ थोड़े अधिक अनुभवी हैं, तो आप कुछ ऐसा लिख ​​सकते हैं।

 package main import ( "fmt" "log" "net/http" ) func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Hello, GopherCon SG") }) go func() { if err := http.ListenAndServe(":8080", nil); err != nil { log.Fatal(err) } }() select {} } 

एक खाली कथन selectहमेशा के लिए अवरुद्ध हो जाता है। यह उपयोगी है, क्योंकि अब हम पूरे प्रोसेसर को केवल एक कॉल के लिए स्पिन नहीं करते हैं runtime.GoSched()। हालांकि, हम केवल लक्षण का इलाज करते हैं, कारण नहीं।

मैं आपको एक और समाधान दिखाना चाहता हूं, जो मुझे आशा है कि आपके पास पहले ही हो चुका है। http.ListenAndServeगोरोइन में दौड़ने के बजाय , मुख्य गोरोइन की समस्या को छोड़कर, मुख्य गोरोइन http.ListenAndServeमें ही दौड़ें।

टिप । यदि आप फ़ंक्शन से बाहर निकलते हैं main.main, तो गो कार्यक्रम बिना शर्त के समाप्त हो जाता है, भले ही प्रोग्राम के निष्पादन के दौरान चल रहे अन्य गोरआउट्स की परवाह किए बिना।

 package main import ( "fmt" "log" "net/http" ) func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Hello, GopherCon SG") }) if err := http.ListenAndServe(":8080", nil); err != nil { log.Fatal(err) } } 

इसलिए यह मेरी पहली सलाह है: अगर गोरोइन किसी अन्य से परिणाम प्राप्त करने तक प्रगति नहीं कर सकती है, तो यह काम खुद को सौंपने के बजाय अक्सर करना आसान होता है।

यह अक्सर राज्य ट्रैकिंग और चैनल हेरफेर को समाप्त करता है जिसके परिणामस्वरूप परिणाम को गोरोइन से वापस प्रक्रिया आरंभ करने वाले को स्थानांतरित करने की आवश्यकता होती है।

टिप । कई गो प्रोग्रामर गोरोनाइट्स का दुरुपयोग करते हैं, खासकर पहले। जीवन में सब कुछ की तरह, सफलता की कुंजी मॉडरेशन है।

8.2। कॉल करने वाले के लिए समानता छोड़ दें

दोनों API में क्या अंतर है?

 // ListDirectory returns the contents of dir. func ListDirectory(dir string) ([]string, error) 

 // ListDirectory returns a channel over which // directory entries will be published. When the list // of entries is exhausted, the channel will be closed. func ListDirectory(dir string) chan string 

हम स्पष्ट अंतरों का उल्लेख करते हैं: पहला उदाहरण निर्देशिका को एक स्लाइस में पढ़ता है, और फिर कुछ गलत होने पर संपूर्ण स्लाइस या त्रुटि देता है। यह तब ListDirectoryतक होता है जब तक कि सभी डायरेक्टरी प्रविष्टियाँ नहीं पढ़ी जाती हैं, तब तक कॉलर ब्लॉक हो जाता है । निर्देशिका कितनी बड़ी है, इस पर निर्भर करते हुए, इसमें बहुत समय लग सकता है और संभवतः बहुत अधिक मेमोरी हो सकती है।

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

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

ListDirectoryचैनल संस्करण में दो और समस्याएं हैं:

• एक बंद चैनल का उपयोग एक संकेत के रूप में कि प्रक्रिया के लिए अधिक तत्व ListDirectoryनहीं हैं , एक त्रुटि के कारण तत्वों के अपूर्ण सेट के कॉलर को सूचित नहीं कर सकता है। कॉलर के पास खाली निर्देशिका और त्रुटि के बीच अंतर बताने का कोई तरीका नहीं है। दोनों मामलों में, ऐसा लगता है कि चैनल तुरंत बंद हो जाएगा।
  
• कॉल करने वाले को बंद होने पर चैनल से पढ़ना जारी रखना चाहिए, क्योंकि यह समझने का एकमात्र तरीका है कि चैनल भरने वाले गोरोइन ने काम करना बंद कर दिया है। यह उपयोग पर एक गंभीर प्रतिबंध है ListDirectory: कॉलर चैनल से पढ़ने में समय व्यतीत करता है, भले ही उसे सभी आवश्यक डेटा प्राप्त हो। यह संभवतः मध्यम और बड़ी निर्देशिकाओं के लिए मेमोरी उपयोग के संदर्भ में अधिक कुशल है, लेकिन यह विधि मूल स्लाइस आधारित विधि से तेज नहीं है।

दोनों मामलों में, समाधान कॉलबैक का उपयोग करना है: एक फ़ंक्शन जिसे प्रत्येक निर्देशिका प्रविष्टि के संदर्भ में कहा जाता है, जैसा कि वह निष्पादित करता है।

 func ListDirectory(dir string, fn func(string)) 

अप्रत्याशित रूप से, फ़ंक्शन filepath.WalkDirउस तरह से काम करता है।

टिप । यदि आपका फ़ंक्शन गोरोइन लॉन्च करता है, तो आपको कॉलर को इस दिनचर्या को स्पष्ट रूप से रोकने का एक तरीका प्रदान करना चाहिए। कॉलर पर अतुल्यकालिक निष्पादन मोड को छोड़ना अक्सर आसान होता है।

8.3। कभी भी गोरोउटिन को बिना यह जाने कि यह कब रुकेगा

पिछले उदाहरण में, गोरोइन का अनावश्यक रूप से उपयोग किया गया था। लेकिन गो की मुख्य खूबियों में से एक इसकी प्रथम श्रेणी की संगणकीय क्षमताएं हैं। वास्तव में, कई मामलों में समानांतर काम काफी उपयुक्त है, और फिर गोरोनाइट का उपयोग करना आवश्यक है।

यह सरल अनुप्रयोग दो अलग-अलग बंदरगाहों पर http ट्रैफ़िक प्रदान करता है: अनुप्रयोग ट्रैफ़िक के लिए पोर्ट 8080 और समापन बिंदु तक पहुँच के लिए पोर्ट 8001 /debug/pprof।

 package main import ( "fmt" "net/http" _ "net/http/pprof" ) func main() { mux := http.NewServeMux() mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) { fmt.Fprintln(resp, "Hello, QCon!") }) go http.ListenAndServe("127.0.0.1:8001", http.DefaultServeMux) // debug http.ListenAndServe("0.0.0.0:8080", mux) // app traffic } 

यद्यपि यह कार्यक्रम सरल है, यह एक वास्तविक अनुप्रयोग की नींव है।

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

 func serveApp() { mux := http.NewServeMux() mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) { fmt.Fprintln(resp, "Hello, QCon!") }) http.ListenAndServe("0.0.0.0:8080", mux) } func serveDebug() { http.ListenAndServe("127.0.0.1:8001", http.DefaultServeMux) } func main() { go serveDebug() serveApp() } 

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

लेकिन इस तरह के कार्यक्रम के प्रदर्शन के साथ कुछ समस्याएं हैं। यदि हम बाहर निकलते हैं serveAppऔर फिर बाहर निकलते हैं main.main, तो प्रोग्राम समाप्त हो जाता है और प्रक्रिया प्रबंधक द्वारा फिर से शुरू किया जाएगा।

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

हालांकि, यह serveDebugएक अलग गोरोइनटाइन में शुरू होता है, और इसकी रिहाई के मामले में, गोरोइनिन समाप्त होता है, जबकि बाकी कार्यक्रम जारी रहता है। आपके देवता इस तथ्य को पसंद नहीं करेंगे कि आप आवेदन के आँकड़े प्राप्त नहीं कर सकते क्योंकि हैंडलर /debugने लंबे समय से काम करना बंद कर दिया है।

हमें यह सुनिश्चित करने की आवश्यकता है कि यदि कोई गोरोइन परोसता है तो आवेदन बंद हो जाता है ।

 func serveApp() { mux := http.NewServeMux() mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) { fmt.Fprintln(resp, "Hello, QCon!") }) if err := http.ListenAndServe("0.0.0.0:8080", mux); err != nil { log.Fatal(err) } } func serveDebug() { if err := http.ListenAndServe("127.0.0.1:8001", http.DefaultServeMux); err != nil { log.Fatal(err) } } func main() { go serveDebug() go serveApp() select {} } 

अब serverAppवे serveDebugत्रुटियों की जांच करते हैं ListenAndServeऔर यदि आवश्यक हो, तो उन्हें कॉल करते हैं log.Fatal। चूँकि दोनों हैंडलर गोरोनाइट में काम करते हैं, इसलिए हम मुख्य रूटीन तैयार करते हैं select{}।

इस दृष्टिकोण में कई समस्याएं हैं:

1. यदि यह ListenAndServeएक त्रुटि के साथ लौटता है nil, तो कोई कॉल नहीं होगा log.Fatal, और इस पोर्ट पर HTTP सेवा एप्लिकेशन को रोकने के बिना बाहर निकल जाएगी।
   
2. log.Fatalकॉल os.Exitजो बिना शर्त प्रोग्राम से बाहर निकलती है; स्थगित कॉल काम नहीं करेगी, अन्य गोरोइन्ट्स को बंद करने की सूचना नहीं दी जाएगी, कार्यक्रम बस बंद हो जाएगा। इससे इन कार्यों के लिए परीक्षण लिखना मुश्किल हो जाता है।

टिप । केवल log.Fatalकार्यों पर उपयोग करें main.mainया init।

वास्तव में, हम किसी भी त्रुटि को व्यक्त करना चाहते हैं जो कि गोरआउट के निर्माता को होती है, ताकि वह पता लगा सके कि उसने क्यों रोका और सफाई से प्रक्रिया को पूरा किया।

 func serveApp() error { mux := http.NewServeMux() mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) { fmt.Fprintln(resp, "Hello, QCon!") }) return http.ListenAndServe("0.0.0.0:8080", mux) } func serveDebug() error { return http.ListenAndServe("127.0.0.1:8001", http.DefaultServeMux) } func main() { done := make(chan error, 2) go func() { done <- serveDebug() }() go func() { done <- serveApp() }() for i := 0; i < cap(done); i++ { if err := <-done; err != nil { fmt.Println("error: %v", err) } } } 

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

चूंकि चैनल doneको सुरक्षित रूप से बंद नहीं किया जा सकता है, हम चैनल चक्र के लिए मुहावरे का उपयोग नहीं कर सकते हैं for rangeजब तक कि सभी गोरआउट्स ने रिपोर्ट नहीं किया हो। इसके बजाय, हम एक चक्र में सभी चलने वाले गोरोइन को चलाते हैं, जो चैनल की क्षमता के बराबर है।

अब हमारे पास हर गोरेइन को साफ करने और उन सभी त्रुटियों को ठीक करने का एक तरीका है जो वे मुठभेड़ करते हैं। यह केवल पहले गोरोइन से बाकी सभी को काम पूरा करने के लिए एक संकेत भेजने के लिए बनी हुई है।

की अपील कीhttp.Serverपूरा करने के बारे में, इसलिए मैंने इस तर्क को एक सहायक समारोह में लपेटा। सहायक serveपते को स्वीकार करता है और http.Handlerइसी तरह http.ListenAndServe, वह चैनल stopजिसे हम विधि को चलाने के लिए उपयोग करते हैं Shutdown।

 func serve(addr string, handler http.Handler, stop <-chan struct{}) error { s := http.Server{ Addr: addr, Handler: handler, } go func() { <-stop // wait for stop signal s.Shutdown(context.Background()) }() return s.ListenAndServe() } func serveApp(stop <-chan struct{}) error { mux := http.NewServeMux() mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) { fmt.Fprintln(resp, "Hello, QCon!") }) return serve("0.0.0.0:8080", mux, stop) } func serveDebug(stop <-chan struct{}) error { return serve("127.0.0.1:8001", http.DefaultServeMux, stop) } func main() { done := make(chan error, 2) stop := make(chan struct{}) go func() { done <- serveDebug(stop) }() go func() { done <- serveApp(stop) }() var stopped bool for i := 0; i < cap(done); i++ { if err := <-done; err != nil { fmt.Println("error: %v", err) } if !stopped { stopped = true close(stop) } } } 

अब चैनल में प्रत्येक मान के लिए doneहम चैनल को बंद कर देते हैं stop, जो इस चैनल के प्रत्येक गोरूटिन को अपने आप बंद कर देता है http.Server। बदले में, यह सभी शेष गोरआउट्स की वापसी की ओर जाता है ListenAndServe। जब सभी चलने वाले गोरूटिन बंद हो जाते हैं, तो यह main.mainसमाप्त हो जाता है और प्रक्रिया सफाई से बंद हो जाती है।

टिप । इस तरह के तर्क को अपने आप में लिखना दोहराव कार्य और गलतियों का जोखिम है। इस पैकेज को कुछ इस तरह से देखें जो आपके लिए अधिकांश काम करेगा।