C ++ में Google स्टाइल गाइड। भाग 1

भाग 1. परिचय
...
भाग 8. नामकरण
भाग 9. टिप्पणियाँ
...


कोड लिखते समय, हम सभी कोड डिजाइन के नियमों का उपयोग करते हैं। कभी-कभी अपने स्वयं के नियमों का आविष्कार किया जाता है, अन्य मामलों में, तैयार-किए गए स्टाइल गाइड का उपयोग किया जाता है। यद्यपि सभी C ++ प्रोग्रामर अंग्रेजी में अपनी मूल भाषा की तुलना में आसान पढ़ते हैं, लेकिन बाद में एक मैनुअल होना अधिक सुखद है।
यह लेख C ++ में Google शैली गाइड के रूसी में अनुवाद का हिस्सा है।
मूल लेख (जीथुब पर कांटा), अद्यतन अनुवाद ।
यह गाइड का परिचयात्मक हिस्सा है, जो सामान्य प्रश्नों को संबोधित करता है "क्यों?"
साथ ही, अनुवाद के बाद संभावित प्रश्नों के कई उत्तर होंगे।

प्रविष्टि

C ++ ओपन-सोर्स Google प्रोजेक्ट्स में उपयोग की जाने वाली मुख्य प्रोग्रामिंग भाषाओं में से एक है। यह ज्ञात है कि C ++ बहुत शक्तिशाली भाषा है। हालांकि, यह एक जटिल भाषा है और, अगर गलत तरीके से उपयोग किया जाता है, तो बग का एक हॉटबेड हो सकता है, जिससे कोड को पढ़ना और बनाए रखना मुश्किल हो जाता है।

इस गाइड का लक्ष्य C ++ कोड लिखने के लिए विस्तार से वर्णन करना है कि यह कैसे (या इसके लायक नहीं है) कोड जटिलता का प्रबंधन करना है। इस गाइड के नियम कोड प्रबंधन को सरल करेंगे और एन्कोडर के प्रदर्शन को बढ़ाएंगे।

शैली - कन्वेंशन सी ++ कोड द्वारा पीछा किया जाता है। शैली कोड के साथ एक फ़ाइल को प्रारूपित करने से अधिक है।

Google द्वारा विकसित अधिकांश ओपन-सोर्स प्रोजेक्ट इस गाइड का पालन करते हैं।

नोट: यह मार्गदर्शिका C ++ ट्यूटोरियल नहीं है: यह माना जाता है कि आप भाषा से परिचित हैं।

स्टाइल गाइड के उद्देश्य

इस दस्तावेज़ की आवश्यकता क्यों है?

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

प्रबंधन के उद्देश्य इस प्रकार हैं:

• नियम परिवर्तन के लायक होने चाहिए।
  
  
  • एकल शैली का उपयोग करने के लाभों को नियमों को याद रखने और उपयोग करने में इंजीनियरों के असंतोष को दूर करना चाहिए।
  • नियमों के आवेदन के बिना कोड आधार के साथ तुलना में लाभ का मूल्यांकन किया जाता है, इसलिए यदि आपके लोग अभी भी नियमों को लागू नहीं करेंगे, तो लाभ बहुत छोटा होगा।
  • यह सिद्धांत बताता है कि कुछ नियम क्यों गायब हैं: उदाहरण के लिए, गोटो कई सिद्धांतों का उल्लंघन करता है, लेकिन इसका व्यावहारिक रूप से उपयोग नहीं किया जाता है, इसलिए गाइड इसका वर्णन नहीं करता है।
• पढ़ने के लिए अनुकूलित, लिखने के लिए नहीं
  
  
  • हमारे कोड बेस (और इसमें से अधिकांश व्यक्तिगत घटक) का उपयोग लंबे समय तक किया जाएगा। इसलिए, लेखन की तुलना में इस कोड को पढ़ने में अधिक समय व्यतीत होगा।
  • हमें स्पष्ट रूप से परवाह है कि हमारे इंजीनियरों के पास पढ़ने, रखरखाव, डिबग कोड को लेगो है। "डिबगिंग / लॉगिंग कोड को छोड़ दें" एक परिणाम है: जब कोड का एक टुकड़ा "अजीब तरह से" काम करता है (उदाहरण के लिए, एक पॉइंटर के स्वामित्व को स्थानांतरित करते समय), पाठ के संकेत की उपस्थिति बहुत उपयोगी हो सकती है ( std :: unique_rr स्पष्ट रूप से स्वामित्व के हस्तांतरण को दर्शाता है)।
• मौजूदा कोड के समान कोड लिखें
  
  एक कोड बेस पर एकल शैली का उपयोग करने से आप अन्य, अधिक महत्वपूर्ण, मुद्दों पर स्विच कर सकते हैं।
  
  इसके अलावा, एक एकल शैली स्वचालन को बढ़ावा देती है। और, निश्चित रूप से, कोड ऑटो-प्रारूप (या #include के संरेखण) सही ढंग से काम करता है अगर यह उपयोगिता की आवश्यकताओं को पूरा करता है। अन्य मामलों में, नियमों के सेट से केवल एक (सबसे उपयुक्त) का उपयोग किया जाता है, और नियमों का उपयोग करने में कुछ लचीलापन लोगों को कम बहस करने की अनुमति देता है।
• C ++ समुदाय में उपयोग किए गए कोड के समान कोड लिखें (यदि संभव हो तो)
  
  अन्य संगठनों और समुदायों के C ++ कोड के साथ हमारे कोड की स्थिरता बहुत उपयोगी है। यदि मानक C ++ की विशेषताएं या भाषा के स्वीकृत मुहावरे लेखन कार्यक्रमों को आसान बनाते हैं, तो यह उनका उपयोग करने का एक अवसर है। हालांकि, कभी-कभी मानक और मुहावरे खराब रूप से कार्य के अनुकूल होते हैं। इन मामलों में (जैसा कि नीचे वर्णित है) यह कुछ मानक सुविधाओं के उपयोग को सीमित या प्रतिबंधित करने के लिए समझ में आता है। कुछ मामलों में, आपका समाधान बनाया जाता है, लेकिन कभी-कभी बाहरी पुस्तकालयों का उपयोग किया जाता है (मानक सी ++ लाइब्रेरी के बजाय) और इसे अपने स्वयं के मानक पर फिर से लिखना बहुत महंगा है।
• अप्रत्याशित या खतरनाक संरचनाओं से बचें।
  
  C ++ में अप्रतिष्ठित और यहां तक ​​कि खतरनाक दृष्टिकोण हैं। कुछ कोडिंग शैलियों ने उनके उपयोग को सीमित कर दिया है, जैसा कि उनका उपयोग कोड की शुद्धता के लिए बहुत जोखिम उठाता है।
• उन कंस्ट्रक्शंस से बचें जो औसत C ++ प्रोग्रामर कंसिस्टेंट्स को एबस्ट्र्यूज और सपोर्ट करने में मुश्किल करते हैं
  
  C ++ में, ऐसी विशेषताएं हैं जो आमतौर पर कोड की जटिलता के कारण स्वागत नहीं करती हैं।
  हालांकि, अक्सर उपयोग किए जाने वाले कोड में, बार-बार उपयोग के कारण मुश्किल निर्माणों का उपयोग अधिक उचित होता है, साथ ही कोड के नए हिस्से अधिक स्पष्ट हो जाएंगे।
  
  यदि संदेह है, तो परियोजना के नेता के साथ परामर्श करें।
  
  यह हमारे कोड आधार के लिए बहुत महत्वपूर्ण है, जैसा कि समय के साथ कोड के मालिक और एक समर्थन टीम बदल जाती है: भले ही हर कोई अब कोड को समझता है, कुछ वर्षों में चीजें बदल सकती हैं।
• कोड के पैमाने पर विचार करें
  
  100 मिलियन से अधिक लाइनों और हजारों इंजीनियरों के कोडबेस के साथ, त्रुटियां और सरलीकरण महंगा हो सकता है। उदाहरण के लिए, वैश्विक नामस्थान पर कूड़ा डालने से बचना महत्वपूर्ण है: यदि वैश्विक नेमस्पेस में सब कुछ घोषित किया जाता है तो बड़े कोड बेस में नाम टकराना बहुत मुश्किल है।
• आवश्यकतानुसार अनुकूलित करें
  
  कोडिंग में नियमों का पालन करने की तुलना में प्रदर्शन अनुकूलन कभी-कभी अधिक महत्वपूर्ण होता है।

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

सी ++ संस्करण

अब कोड को C ++ 17, यानी के साथ पालन करना चाहिए सी ++ 2x सुविधाएँ अवांछनीय हैं। भविष्य में, C ++ के नए संस्करणों के लिए मैनुअल को समायोजित किया जाएगा।

कस्टम एक्सटेंशन का उपयोग न करें।

यदि आप अपनी परियोजना में C ++ 14 और C ++ 17 का उपयोग करने का इरादा रखते हैं, तो अन्य वातावरणों के साथ संगतता पर विचार करें।

नोट: लिंक मैनुअल के उन वर्गों को ले जा सकते हैं जिन्हें अभी तक अनुवादित नहीं किया गया है।

कुछ जवाब / टिप्पणियाँ:

- ट्रांसफर क्यों?

निजी तौर पर, मैं रूसी नेतृत्व के साथ अधिक सहज हूं। रूसी पाठ के साथ शैली गाइड में परिवर्तन पर चर्चा करना भी बेहतर है।

- क्यों गूगल? क्या अधिक (या कम) लोकप्रिय हैं ...?

कंपनी काफी प्रसिद्ध है, नेतृत्व बहुत बड़ा नहीं है (आप एक व्यक्ति द्वारा प्रयास किए बिना इसका अनुवाद कर सकते हैं), यह आवश्यक कार्यों को पूरा करता है - यह मार्गदर्शिका शैली में है

- लेकिन Google मैनुअल अप्रचलित (...) के उपयोग की घोषणा करता है, ऐसे उपयोगी (...) की अस्वीकृति! क्यों?

जैसा कि मैंने इसे समझा, यह दस्तावेज़ एक प्रस्ताव है। तुम कुछ का उपयोग करोगे, कुछ बदलोगे - यह अनुमेय है। नेतृत्व एक अच्छी नींव है।