किसी भी सॉफ़्टवेयर डेवलपमेंट संगठन में कोडिंग मानक सामान्य हैं, लेकिन उनका पालन करना कितना महत्वपूर्ण है? मैं कुछ स्थिरता की आवश्यकता को समझ सकता हूं, लेकिन जब ब्रेसिज़ की स्थिति, लाइन की लंबाई आदि जैसी सरल चीजों से निपटते हैं, तो मुझे यकीन नहीं है कि सॉफ़्टवेयर के विकास में अत्यधिक सख्त मानकों का बहुत योगदान है।
क्या यह अधिक महत्वपूर्ण नहीं है कि आपका कोड पठनीय हो, न कि यह एक पूर्वनिर्धारित मानक के अनुरूप हो? ऐसा लगता है कि वे और अधिक पसंद कर रहे हैं ... दिशा-निर्देश वैसे भी।
जवाबों:
सभी को एक ही मानक कोड फ़ॉर्मेटिंग का पालन करने के लिए सभी को 100% पूछना एक समान लेखन शैली के साथ 100 पेज का पेपर लिखने पर सभी को अलग-अलग सहयोग करने के लिए कहना है।
उम्मीद है कि हर कोई अंग्रेजी (या उसी भाषा) में पेपर लिखेगा, लेकिन अलग-अलग शैली स्पष्ट होगी। कुछ इसे अच्छी तरह से लिखेंगे, अन्य नहीं। कुछ संकुचन का उपयोग करेंगे, कुछ शब्दों को पूरी तरह से जादू करेंगे (उदाहरण: यह क्रिया है)। आदि।
मुझे लगता है कि आपने सबसे महत्वपूर्ण बिंदुओं को छुआ है:
यदि आप चाहते हैं कि कोड उसी स्वरूपण का पालन करे, जैसे एक ही लेखन शैली में होना चाहिए, तो उसे संपादन और संशोधन की आवश्यकता होगी। कोड को साफ, समीक्षा, पुन: फैक्टरेड आदि की आवश्यकता होगी।
मैं कभी किसी ऐसी दुकान में नहीं गया जहाँ मैं किसी अन्य डेवलपर की कोडिंग शैली या प्रारूपण से पूरी तरह खुश था (कम से कम क्योंकि यह बिल्कुल मेरी तरह नहीं है)। लेकिन मुझे संतोष होगा अगर मैं इसे पढ़ / समझ सकता हूँ और अगर यह सुसंगत है। सिंटैक्टिक शुगर पर बाकी सब चीनी है।
इसलिए आपके प्रश्न का उत्तर देने के लिए: कुछ महत्वपूर्ण, लेकिन यह निश्चित रूप से दुनिया का अंत नहीं है यदि वे नहीं करते हैं।
मानकों को प्रारूपित करने के लिए, मैं उसका अनुसरण करता हूं जो हर कोई कर रहा है। अगर वे PascalCase का उपयोग हर चीज के लिए कर रहे हैं, तो मैं PascalCase का उपयोग करता हूं। यदि वे _camelCase का उपयोग करते हैं, तो मैं _camelCase का उपयोग करता हूं। क्यों? क्योंकि यह मेरे द्वारा किए जाने वाले सुधारों की मात्रा को सीमित करता है, और दूसरों को इसे "अच्छा दिखने" के लिए क्या करना है, इसे सीमित करता है। प्रारूपण मानक आमतौर पर हर किसी के लिए चीजों को आसान बनाने के लिए होते हैं।
मेरी वर्तमान नौकरी में, मेरा पहला काम हमारे विकास समूह के लिए एक कोडिंग मानक के साथ आना था।
मेरा पहला प्रयास लगभग साठ पृष्ठों लंबा था (इसमें Microsoft से फ्रेमवर्क दिशानिर्देशों को शामिल किया गया था)। मुझे इसे नीचे देने के लिए कहा गया था, और मेरा अगला प्रयास दस पन्नों लंबा था, जिसमें कई अच्छे स्रोतों से विचारों का उपयोग किया गया था। मुझे लगता है कि इसे फिर से नीचे गिराने के लिए कहा गया था, और आखिरकार इसे तीन या चार पन्नों में बदल दिया गया, मुझे लगता है।
इसे कभी नहीं अपनाया गया।
क्यों? क्योंकि मैं बहुत सारे स्मार्ट लोगों के साथ काम करता हूं, जो पहले से ही सहज रूप से एक समझदार कोडिंग मानक का पालन करते हैं।
मेरे भाग के लिए, मैं Microsoft से आम तौर पर स्वीकृत दिशानिर्देशों का पालन करता हूं, और दूसरों की आमतौर पर इस्तेमाल की जाने वाली शैलियों का अनुकरण करता हूं (जावास्क्रिप्ट और jQuery को C # से अलग रूप में स्वरूपित किया जाता है, भले ही वे दोनों घुंघराले-ब्रेस भाषाएं हों)। मैं समय-समय पर नियमों को भी तोड़ता हूं, जब ऐसा करने से कोड अधिक पठनीय हो जाएगा।
यदि आप इसका उपयोग करते हैं और आईडीई जो आपके लिए मूल बातें करता है (उदाहरण के लिए विजुअल स्टूडियो), तो आइडीई को करने दें और जो कुछ भी अभी भी आपको लगता है कि जब तक आप आईडीई करते हैं तब तक इसे संशोधित करना मुश्किल है। अगले व्यक्ति कि ऑटो-प्रारूप यह वैसे भी मारने वाला है।
एक व्यक्ति के लिए सबसे अधिक पठनीय क्या सभी लोगों के लिए नहीं होगा।
यदि आप इस प्रकार के IDE का उपयोग नहीं कर रहे हैं तो एक प्राप्त करें। यहां तक कि 10 मिनट से अधिक समय तक इस बारे में सोचना भी संसाधनों की बर्बादी है IMHO।
मुझे लगता है कि कोड को जल्दी से समझने में मदद करने में एक असम्बद्ध लाभ है। कोड स्वरूपण जितना अधिक एक प्रोजेक्ट और सभी डेवलपर्स में होता है, उतना आसान (और अधिक अवचेतन रूप से) आप कोड के साथ काम करने में सक्षम होंगे।
मैं कनिष्ठ डेवलपर्स के लिए समय की एक विस्तारित अवधि के लिए भी साधारण कीड़े से निपटने की कोशिश करने के बाद मेरे पास आया है। उनके साथ हमारे कोड प्रारूप को लागू करने के लिए कुछ मिनट लेने के बाद, वे जल्दी से उस बग को देखने में सक्षम थे जो वे पहले चूक गए थे।
जबकि पठनीयता निश्चित रूप से महत्वपूर्ण है। यदि आपके कोड प्रारूप मानकों को अच्छी तरह से सोचा गया है, और ठीक से उपयोग किया जाता है, तो आप पा सकते हैं कि आप कोड को पढ़ने में सक्षम होने से परे जा सकते हैं, और कोड को और भी जल्दी समझने में सक्षम होने के लिए।
हमारे कोडिंग स्वरूपों को विकसित या अद्यतन करते समय मेरे द्वारा उपयोग किए जाने वाले दिशानिर्देशों का एक समूह समूहन के गेस्टाल्ट सिद्धांत है - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping
प्रत्यक्ष परिणाम / उदाहरण के रूप में हमारे कोड स्वरूपण के लिए आवश्यक है कि किसी भी ब्लॉक कोड (यदि, स्विच, आदि) के पास अगली पंक्ति में खुला ब्रेस हो, जिससे यह समापन ब्रेस के साथ पंक्तिबद्ध हो:
if(true)
{
}
इस तर्क के साथ कि समरूपता के सिद्धांत द्वारा, आपका दिमाग खुले और समापन ब्रेसिज़ को देखेगा और अधिक तेज़ी से स्वाभाविक रूप से कोड ब्लॉक को देखने में सक्षम होगा।
After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before.ऐसा इसलिए नहीं है क्योंकि आपके कोड प्रारूप ने उन्हें बग को देखने में मदद की है। ऐसा इसलिए है क्योंकि कोड को सुधारने के कार्य ने उन्हें उस कोड को ध्यान से देखने के लिए मजबूर कर दिया है जो वे पहले से अधिक संक्षिप्त थे।
कोई फर्क नहीं पड़ता कि आप किस भाषा या उपकरण का उपयोग करते हैं, कुछ के साथ आते हैं। अपनी IDE कॉन्फ़िगर करें और कॉन्फ़िगरेशन फ़ाइल में जांचें।
जब कोई भी परियोजना की जाँच करता है, तो वे समान स्वरूपण शैलियों का उपयोग करेंगे। इससे कोई फर्क नहीं पड़ता कि शैली क्या है, केवल यह सुसंगत है। रिक्त स्थान v। टैब्स के संबंध में मेरी अपनी प्राथमिकताएं हैं, और जो घुंघराले ब्रेसों पर चलते हैं। लेकिन मेरी अपनी प्राथमिकताओं से ज्यादा, मुझे बस इस बात का ध्यान है कि किसी दिए गए सोर्स कोड की फाइल ही इससे सहमत है। यह एक प्रारूप युद्ध से उत्पन्न होने के कारण इसे अधिक पठनीय बनाता है।
अब तक मैंने जो सबसे खराब चीज का सामना किया है, वह कोई कोडिंग मानकों का उपयोग नहीं कर रही है। और आपको कुछ कोड ब्लॉक को अधिक पठनीय बनाने के लिए निषिद्ध है क्योंकि यह अलग-अलग टूल को तोड़ता है ... क्योंकि हम परिवर्तन लागू करने के लिए पैच का उपयोग कर रहे हैं (परिवर्तन / बग फिक्स अनुरोध -> फिक्स / परिवर्तन -> पैच -> पैच "विश्वसनीय" व्यक्ति द्वारा लागू किया गया - (प्रतिबद्ध) आप बहुत अजीब लग स्रोत कोड (देखने की पठनीयता से) प्राप्त कर सकते हैं। कम से कम हमारे पास दो अक्षर चर (-) का उपयोग करने वाला कोई नहीं है।
[शेख़ी] सबसे मजेदार बात यह है कि हर कोई इस बात से सहमत है कि हमें इसे बदलने की जरूरत है। यहां तक कि सुधार के प्रयासों के कुछ जोड़े थे (प्रतिबद्ध पर स्वचालित), लेकिन क्योंकि एक एकल छोटी बिट बिट प्रारूपण विकल्प गायब है - बस बाहर के माध्यम से मिला सब कुछ। दृष्टि ... [/ शेख़ी]
दिशानिर्देश कोड की गुणवत्ता में सुधार करने में मदद करते हैं:
लेखक के दृष्टिकोण से: कई नियम बगों की शुरूआत को कम करने का लक्ष्य रखते हैं। उदाहरण के लिए, एक नियम जो कहता है कि if()या for(;;)निर्माण एक ब्लॉक और एक भी निर्देश का पालन नहीं करना चाहिए, प्रारंभिक कोडर का इरादा स्पष्ट करता है और अगले कोडर्स को बनाए रखने में मदद करता है।
पाठक के दृष्टिकोण से: कोड जो सहमत दिशानिर्देशों का पालन करता है, विभिन्न शैलियों के साथ कोड की तुलना में अधिक कुशलता से समीक्षा की जाती है। समीक्षक कम प्रयासों के साथ बेहतर जानता है कि संभावित कीड़े कहाँ देखें।
टीम को क्या करना चाहिए या क्या नहीं करना चाहिए, इसके लिए कोई सार्वभौमिक मानक नहीं है। कुछ टीमों को सख्त दिशानिर्देशों का पालन करने की आवश्यकता है, कुछ नहीं।
मुद्दा यह है, आपको एक टीम के रूप में एक साथ काम करना चाहिए और यह तय करना चाहिए कि आपकी टीम के लिए सबसे अच्छा क्या है । कोड को पढ़ना आसान होना चाहिए, क्योंकि इसे लिखे जाने की तुलना में अधिक बार परिमाण के आदेश पढ़े जाते हैं। यदि आपकी टीम को पठनीय कोड बनाने के लिए मार्गदर्शन की आवश्यकता है, तो एक कोडिंग मानक से चिपके रहें। यदि आप नहीं करते हैं, नहीं।
यह सब कहा जा रहा है, मुझे लगता है कि ज्यादातर टीमें एक मानक तरीके पर चर, फ़ंक्शन और कक्षाएं, स्थिति ब्रेसिज़, और इसी तरह के नाम पर सहमत होने से लाभान्वित होंगी। अगर टीम किसी चीज़ पर उतना आसान नहीं हो सकती है, तो वे एक साथ आने और वास्तव में महत्वपूर्ण निर्णय लेने की उम्मीद कैसे कर सकते हैं? साथ ही, आपकी टीम हमेशा के लिए एक जैसे लोगों से नहीं बनेगी - लोग निकल जाते हैं, नए लोगों को काम पर रखा जाता है। नए लोगों के लिए कोडबेस को ग्रॉस करना जितना आसान है, उतनी ही जल्दी वे कोड की गुणवत्ता को कम किए बिना टीम में योगदान कर सकते हैं।