क्या एक कोडिंग मानक की भी आवश्यकता है?

Question

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

क्या कोडिंग मानक के विकास के लिए कोई तर्क हैं (हमारे पास एक नहीं है, लेकिन मैं एक बनाने में देख रहा था)?

Comments

यदि आप एक कोडिंग मानक लागू करने का निर्णय लेते हैं, तो निरंतर एकीकरण के दौरान इसे लागू करने पर विचार करें।

— लीफ कार्लसन 3

टीम के सभी व्यक्तियों की जानी चाहिए की आवश्यकता ही आईडीई उपयोग करने के लिए?

— कीथ थॉम्पसन

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

— कालेब

सभी लोग आईडीई का उपयोग नहीं करते हैं, मैं उदाहरण के लिए एक्मे का उपयोग करता हूं।

— डिस्को कोको

Answer 1

हालांकि, कई अलग-अलग उपकरण और आईडीई हैं जो प्रोग्रामर को जो भी मानक पसंद करते हैं, उसे प्रारूपित करेंगे।

उसके साथ अच्छा भाग्य। मेरा अनुभव है, वहाँ उपकरण (शून्य!) की एक छोटी संख्या है जो ठीक से प्रारूप X से प्रारूप Y में कोड को ठीक कर सकते हैं। बस बहुत सी चीजें हैं जो रास्ते में मिलती हैं। टैब्स बनाम स्पेस, मल्टी-लाइन स्टेटमेंट आदि, बस सी ++ मानक लाइब्रेरी फ़ाइलों के जीएनयू के कार्यान्वयन को देखें। आप जो कुछ भी कर सकते हैं, वह यह है कि अपना आईडीई करें, हमेशा टैब के बजाय रिक्त स्थान का उपयोग करें और विदेशी कोड को सुधारने में परेशान न करें। अब आपका कोड आपको पसंद करने का तरीका दिखता है, और विदेशी कोड उस तरह दिखता है जैसा मूल लेखक ने लिखा था।

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

बड़ी बातें:

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

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

कोडिंग मानकों के अनपेक्षित परिणाम हो सकते हैं। उदाहरण: एक परियोजना इंजीनियर के कुछ मूर्ख व्याख्या करने के लिए "कोई जादू संख्या पर राज" इसका मतलब यह जा रहा है if (index == 0) {...}और for (ii = 0; ii < 3; ++ii) {...}करने के लिए परिवर्तित किया जाना चाहिए if (ZERO == index) {}और for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}क्या हंसी नहीं। मैंने इसे होते देखा है। आजकल जब मैं एक कोडिंग मानक लिखता हूं तो यह इस तरह की मूर्खता का मुकाबला करने के लिए एक नियम के बजाय एक "कोई जादुई संख्या दिशानिर्देश" है।

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

Comments

एक महान सूची के लिए +1 - यह मेरा पसंदीदा उत्तर है। विशेष रूप से ऑफ-लिमिट्स कोड, कंपाइलर चेतावनियां, परीक्षण और प्रलेखन। लेकिन मुझे अभी भी लगता है कि टैब बनाम रिक्त स्थान और इंडेंटेशन महत्वपूर्ण हैं। किसी और ने दुःस्वप्न का उल्लेख किया जब यह स्रोत नियंत्रण में परिवर्तन को अलग करता है।

— ग्लेनपेटर्सन

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

— डेविड हैम्मन सेप

ध्यान दें कि "नो टैब्स" रूल (कुछ मैंने अपनी लिस्ट में टाला क्योंकि राय अलग-अलग हैं) का मतलब यह नहीं है कि जब आप अपना कोड टाइप कर रहे हैं तो आप टैब्स का उपयोग नहीं कर सकते। एक सभ्य संपादक टैब को प्रोग्रामर के प्रकार को व्हाट्सएप में बदल सकता है। यदि आपका संपादक ऐसा नहीं कर सकता है, तो बेहतर संपादक पर स्विच करने के बारे में सोच सकता है।

— डेविड हैमेन

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

— ग्लेनपेटर्सन

@GlenPeterson - इंडेंटेशन / फॉर्मेटिंग मेरी सूची में है, या मेरी सूची से ठीक पहले: "IMO, एक कोडिंग मानक को स्वीकार्य इंडेंटेशन शैलियों का एक उचित सूट निर्दिष्ट करना चाहिए, लेकिन एक पैकेज के लेखकों के लिए बारीकियों को छोड़ दें।" और हां, "कोई टैब" नियम के अपवाद नहीं हैं। उदाहरण के लिए मेकफाइल्स।

— डेविड हैम्मन

Answer 2

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

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

Comments

अच्छा जवाब, यह मेरे ज्ञान का विस्तार एक अच्छी व्याख्या के साथ करता है जो मैंने सोचा नहीं था। +1

— SomeKittens

वे क्रॉस-प्लेटफ़ॉर्म संगतता को संभालने के लिए चीजों को भी कवर कर सकते हैं, जो कि एक नया डेवलपर क्रॉस-प्लेटफ़ॉर्म कोड लिखने में अनुभवी नहीं है।

— वेलोसिरैप्टर

अगर आपको लगता है कि यह उत्तर एक अच्छा है और आपके प्रश्न का उत्तर देता है, तो इसे इस तरह चिह्नित करें।

— marktani

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

— मैथ्यू शार्ले

@MatthewScharley आम तौर पर आप परिवर्तित कोड को फ़ॉर्मेटर के माध्यम से धकेलते हैं और फिर कमिट करते हैं (हो सकता है कि एक अंतिम टेस्ट रन बनाने के बाद फ़ॉर्मेटर कुछ भी न तोड़ें) इसलिए केवल फॉर्मेट किया गया कोड रेपो पर मिलता है

— शाफ़्ट फ्रीक

Answer 3

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

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

Comments

Diffs! मैंने ऐसा नहीं सोचा था।

— SomeKittens

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

— ग्लेनपेटर्सन

Answer 4

संक्षिप्त उत्तर: हां, यह गुणवत्ता को दर्शाता है ।

यह क्या है और हमें इसकी आवश्यकता क्यों है?

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

ठीक है, हर डेवलपर जानता है कि कोडिंग कन्वेंशन अच्छे हैं। लेकिन मानक कहां से आने चाहिए?

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

क्या कोडिंग मानक के विकास के लिए कोई तर्क हैं (हमारे पास एक नहीं है, लेकिन मैं एक बनाने में देख रहा था)?

हां, ऐसे उद्योग मानक हैं जिनका उपयोग करने की अनुशंसा की जाती है। हालांकि, विकास मंच के लिए प्रत्येक कोडिंग मानक विशिष्ट है। इस प्रकार, कोडिंग मानक ज्यादातर भाषा विशिष्ट हैं। उदाहरण के लिए, जावा में .NET की तुलना में एक अलग मानक है। उदाहरण के लिए C # .NET इस संदर्भ में उस मानकों का उपयोग कर रहा है ।

सामान्य मानक

सामान्य मानकों में किसी भी प्रोग्रामिंग भाषा पर निर्भरता नहीं होती है। विक्रेता की पेशकश की मानकों के अलावा, उर्फ ​​उल्लेख उद्योग कोडिंग मानकों, हंगेरियन संकेतन या CamelCase जैसे विभिन्न प्रोग्रामिंग सूचनाएं हैं । मुझे लगता है कि Microsoft .NET कोडिंग मानक शुरू में CamelCase नोटेशन पर आधारित थे।

टीम कोडिंग मानकों और दिशानिर्देशों

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

Comments

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

— ब्रायन ओकले

मैंने अपना जवाब अभी तक पूरा नहीं किया है

— यूसुबोव

वह While Notपूरी तरह से एक होना चाहिए Do Until।

— आरवाई- 3

Answer 5

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

इस चर का नाम कैसे होना चाहिए? हमें किन भाषा सुविधाओं का उपयोग करना चाहिए? क्या हमें बचना चाहिए? क्या परीक्षण सबसे अच्छा है? ये तब तक अनुत्तरित रह जाते हैं जब तक कि हम संकीर्ण रूप से परिभाषित समस्या का सामना नहीं करते हैं जो हम अभी काम कर रहे हैं ।

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

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

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

और जब कोई आपको बताता है कि "मानक" में एक नियम का कुछ कारण नहीं है, लेकिन उनके दावे का कोई अनुभव या उचित बैकअप नहीं है, तो उन्हें अनदेखा करें। यहाँ मानक ने किसी की सेवा नहीं की या किसी को बेहतर डेवलपर नहीं बनाया।

Comments

मेरे द्वारा ठीक - समय बर्बाद करने के लिए एक कम चीज, खासकर यदि सभी देवों के पास एक रेस्पर लाइसेंस है और बिल्ड सर्वर पर fxcop / stylecop चल रहा है।

— स्टुअर्टएलसी 4

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

— एंड्रयू

@ और उन अनुभवों को लागू नहीं कर सकते हैं और आपको बहुत सारे विचारों से बांध सकते हैं, जिनका आपके द्वारा हल की जा रही मौजूदा समस्या से

— डग टी।

+1 स्टिफ़लिंग नवाचार के लिए, सबसेट को नियंत्रित करने, सामान्य सर्वोत्तम प्रथाओं और राजनीति को नियंत्रित करने के लिए। शिक्षित करें, विनियमित न करें!

— kirk.burleson

"कोई लिखित कोडिंग मानक नहीं, सम्मेलन पर भरोसा करें और मार्गदर्शन के लिए पूछें" छोटी टीमों में काफी अच्छी तरह से काम करता है (कम से कम, मुझे पता है, 50? 100?)। जब आपके पास हजारों लोग होते हैं, तो कोड-बेस के भीतर परियोजनाओं के बीच आगे-पीछे माइग्रेट करना, यह वास्तव में कोड के लिए दिशानिर्देशों का लिखित सेट होने में मदद करता है।

— वेटिन

Answer 6

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

देखें: प्रस्तावित संघीय उड्डयन प्रशासन सी और सी ++ कोडिंग मानक

क्या मुझे कुछ और कहने की ज़रूरत है।

नोट: मुझे एफएए ऑनलाइन से वास्तविक मानक नहीं मिला, लेकिन मैंने इसे देखा है।

Comments

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

— डेविड हैमेन

Answer 7

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

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

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

Answer 8

कोडिंग मानक किसी भी अधिक महत्वपूर्ण नहीं हो सकते हैं! मैं एक शौकीन चावलाPHPHP उपयोगकर्ता हूं और मुझे संस्करण-से-संस्करण में बदलावों की समीक्षा करना पसंद है और डेवलपर्स वहां मानकों का पालन नहीं कर रहे हैं।

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