यदि आपको लगता है कि यह नहीं होना चाहिए, तो क्यों समझाओ।क्या आपको लगता है कि एक सॉफ्टवेयर कंपनी को डेवलपर्स को कोडिंग-स्टाइल लगाया जाना चाहिए?
यदि हां, तो आपकी राय में दिशानिर्देश कितने गहरे होंगे? उदाहरण के लिए, कोड का इंडेंटेशन शामिल किया जाना चाहिए?
मुझे लगता है कि एक टीम (बजाय एक कंपनी) यथोचित संगत शैली के लिए दिशानिर्देशों का एक सेट पर सहमत करने की जरूरत है। यह रखरखाव के लिए इसे और अधिक सरल बनाता है।
कितना गहरा? उथले के रूप में आप सहमत हो सकते हैं। कम और स्पष्ट यह अधिक संभावना है कि सभी टीम के सदस्य इससे सहमत हो सकते हैं और इसका पालन करेंगे।
मेरा मानना है कि एक सतत कोडबेस होना महत्वपूर्ण है। यह आपके कोड की रखरखाव को बढ़ाता है। अगर सभी एक ही तरह के कोड की अपेक्षा करते हैं, तो वे आसानी से इसे पढ़ और समझ सकते हैं।
यह इसके अलावा एक परेशानी को देखते हुए आज के IDEs और उनके autoformatting क्षमताओं के ज्यादा नहीं है।
पी.एस: मैं अगली पंक्ति :) पर मेरी ब्रेसिज़ डालने की इस कष्टप्रद आदत है। कोई और नहीं यह
मुझे भी, जब अगर (हालत) { ... } टूट जाता है इसका इतना आसान जब यह की तरह अगले और ठीक दांतेदार पर है सही ब्रेसिज़ के लिए जाँच करने के लिए। – UnkwnTech
मुझे भी! मुझे लगता है कि यह डीबगिंग को बहुत आसान बनाता है। जब आप एक कड़े शेड्यूल पर होते हैं और एक बग ASAP को ठीक करने की आवश्यकता होती है तो यह और भी महत्वपूर्ण है। मेरे पास वाक्यविन्यास से लड़ने का समय नहीं है! –
मेरी राय में पसंद करने के लिए मुझे लगता है कि मानकों और शैली गाइड के साथ बेहद आवश्यक है लगता है। क्योंकि जब आपका कोड-बेस बढ़ता है तो आप इसे लगातार रखना चाहते हैं।
एक साइड नोट के रूप में, यही कारण है कि मुझे पायथन पसंद है; क्योंकि यह आपके अनुप्रयोगों और इस तरह की संरचनाओं को कैसे व्यवस्थित करता है, इस पर बहुत सारे नियम लगाए गए हैं। तुलना करें कि पर्ल, रुबी या जो कुछ भी आपके पास अत्यधिक आजादी है (जो इस मामले में अच्छा नहीं है) के साथ तुलना करें।
मुझे लगता है कि प्रोग्रामर अन्य प्रोग्रामर की शैली के लिए अनुकूल करने के लिए सक्षम होना चाहिए। यदि कोई नया प्रोग्रामर अनुकूलित करने में असमर्थ है, तो आमतौर पर इसका मतलब है कि नया प्रोग्रामर कंपनी की शैली का उपयोग करने के लिए बहुत जिद्दी है। यह अच्छा होगा अगर हम सब अपनी खुद की चीज कर सकें; हालांकि, अगर हम कुछ बेस्ट दिशानिर्देशों के साथ सभी कोड, यह डीबगिंग और रखरखाव को आसान बनाता है। यह केवल तभी सही है जब मानक अच्छी तरह से सोचा जाता है और बहुत ही सीमित नहीं है।
While I don't agree with everything, this book contains an excellent starting point for standards
हाँ, पर कारण के भीतर।
सभी आधुनिक IDEs एक कीस्ट्रोक कोड सुंदर प्रिंट प्रस्तुत करते हैं, तो "खरोज" बिंदु काफी अप्रासंगिक है, मेरी राय में।
सर्वोत्तम प्रथाओं को स्थापित करना अधिक महत्वपूर्ण है: उदाहरण के लिए, जितना संभव हो उतना छोटा "आउट" या "रेफरी" पैरामीटर के रूप में उपयोग करें ... इस उदाहरण में, आपके पास 2 फायदे हैं: पठनीयता में सुधार और बहुत से सुधार भी गलतियों (बहुत से पैरामीटर एक कोड गंध है और शायद इसे दोबारा किया जाना चाहिए)।
से परे जा रहा है, अपनी ईमानदार राय में, एक सा "गुदा" और अनावश्यक रूप से devs के लिए कष्टप्रद।
हामिश स्मिथ ने अच्छा बिंदु:
शैली सबसे अच्छा प्रथाओं से काफी अलग है। यह एक शर्म की बात है कि ' मानकों को कोडिंग' दो को एक साथ रोल करने की प्रवृत्ति है। अगर लोग शैली भाग को न्यूनतम और पर रख सकते हैं तो सर्वोत्तम अभ्यासों पर ध्यान केंद्रित करें शायद अधिक मूल्य जोड़ देगा।
शैली सर्वोत्तम प्रथाओं से काफी अलग है। यह एक शर्म की बात है कि 'कोडिंग मानकों' दोनों को एक साथ रोल करने के लिए प्रवृत्त होते हैं। अगर लोग शैली के हिस्से को कम से कम रख सकते हैं और सर्वोत्तम प्रथाओं पर ध्यान केंद्रित कर सकते हैं जो शायद अधिक मूल्य जोड़ते हैं। –
आप सभी को मानक तरीके से कोड पढ़ना और लिखना चाहते हैं। आप इसे प्राप्त करने के दो तरीके हैं:
जितना अधिक आप अपरिभाषित छोड़ते हैं, उतना अधिक संभावना डेवलपर्स में से एक स्टाइल पर संघर्ष करेगा।
एचआरएम, किसी ने मेरी टिप्पणी हटा दी। क्लोनिंग का उल्लेख करने के लिए यह rediculous। मेरी टिप्पणी ने उसको बढ़ा दिया। यदि यह हटा दिया जाता है, तो पोस्ट होना चाहिए, या कम से कम संपादित किया जाना चाहिए। वाह, नियंत्रण के बारे में बात करो। – mattlant
मैटलेंट: सेकेंड। यदि आप इस साइट पर कुछ भी नकारात्मक करते हैं (वोटिंग, टिप्पणियां हटाना, पोस्ट बंद करना आदि) तो आपको निश्चित रूप से एक शापित टिप्पणी छोड़नी चाहिए क्यों समझाती है! आपकी टिप्पणी मजाकिया थी और कोई नुकसान नहीं हुआ। – Oli
कंपनी को यह लागू करना चाहिए कि कुछ शैली का पालन किया जाना चाहिए। कंपनी में डेवलपर समुदाय द्वारा कौन सी शैली है और दिशानिर्देशों को कितना गहराई से तय किया जाना चाहिए।
मैं निश्चित रूप से ब्रेसिज़, इंडेंटेशन, नामकरण आदि पर दिशानिर्देश निर्धारित करता हूं ... आप पठनीयता और रखरखाव के लिए कोड लिखते हैं। हमेशा मान लें कि कोई और आपका कोड पढ़ रहा है। ऐसे उपकरण हैं जो स्वचालित रूप से आपके कोड को प्रारूपित करेंगे, और आप यह आदेश दे सकते हैं कि हर कोई टूल का उपयोग करता है।
आप StyleCop, FxCop पर नेट रूप और Resharper पर हैं
मैं सहमत हूं। एक उपकरण मानक का पालन करना आसान बनाता है, और अनुपालन की जांच करता है। उपकरण के साथ बहस करना भी मुश्किल है;) –
हाँ, मुझे लगता है कि कंपनियों चाहिए। डेवलपर को कोडिंग-शैली में उपयोग करने की आवश्यकता हो सकती है लेकिन मेरी राय में एक अच्छा प्रोग्रामर किसी भी कोडिंग शैली के साथ काम करने में सक्षम होना चाहिए। जैसा कि मिधात ने कहा: एक सतत कोडबेस होना महत्वपूर्ण है।
मुझे लगता है कि यह भी खुला स्रोत परियोजनाओं के लिए महत्वपूर्ण है, वहाँ आपको बताएगा कि अपनी कोड लिखने के लिए कोई पर्यवेक्षक है, लेकिन कई भाषाओं कैसे नामकरण और अपने कोड के संगठन होना चाहिए पर विनिर्देशों की है। यह आपके प्रोजेक्ट में ओपनसोर्स घटकों को एकीकृत करते समय बहुत मदद करता है।
निश्चित रूप से, दिशानिर्देश अच्छे हैं, और जब तक यह बुरी तरह से उपयोग नहीं किया जाता है हंगेरियन नोटेशन (हा!), यह शायद स्थिरता में सुधार करेगा और अन्य लोगों के कोड को आसान बना देगा। दिशानिर्देश केवल दिशानिर्देश होना चाहिए, हालांकि प्रोग्रामर पर सख्त नियम लागू नहीं किए गए हैं। आप मुझे बता सकते हैं कि मेरी ब्रेसिज़ कहां डालें या अस्थायी नामों का उपयोग न करें, लेकिन आप क्या नहीं कर सकते हैं मुझे सरणी ब्रैकेट्स में इंडेक्स वैल्यू के आसपास रिक्त स्थान प्राप्त करने के लिए मजबूर करना है (उन्होंने एक बार कोशिश की ...)
मानकों के विकास के तरीके को परिभाषित करने के तरीके के मानकों के लिए बहुत अच्छे कारण हैं और जिस तरह से कोड दिखना चाहिए। उदाहरण के लिए जब हर कोई एक ही मानक का उपयोग करता है तो एक स्वचालित स्टाइल-चेकर प्रोजेक्ट सीआई के हिस्से के रूप में उपयोग किया जा सकता है। समान मानकों का उपयोग कोड पठनीयता में सुधार करता है और टीम के सदस्यों के बीच तनाव को कम करने में मदद करता है ताकि वे उसी कोड को फिर से फैक्टरिंग कर सकें। इसलिए:
आउटसोर्सिंग कंपनी में ग्राहक के लिए काम करने वाली टीम के लिए एक अपवाद बनाया जा सकता है यदि ग्राहक अपने मानक को लागू करना चाहता है। इस मामले में टीम ग्राहक के मानक को गोद लेती है जो कि उनकी कंपनी द्वारा उपयोग किए जाने वाले किसी के साथ असंगत हो सकती है।
हां।
कोडिंग मानकों को सुनिश्चित करने का एक आम तरीका है कि एक निश्चित संगठन के भीतर कोड कम आश्चर्य के सिद्धांत का पालन करेगा: वेरिएबल नामकरण से इंडेंटेशन से घुंघराले ब्रेस उपयोग के लिए शुरू होने वाले मानकों में स्थिरता।
कोडर अपनी खुद की शैलियों और अपने स्वयं के मानकों को केवल कोड-आधार उत्पन्न करेंगे जो असंगत, भ्रमित और निराशाजनक है, विशेष रूप से बड़ी परियोजनाओं पर।
These एक कंपनी के लिए कोडिंग मानकों हैं जिनके लिए मैं काम करता था। वे अच्छी तरह से परिभाषित हैं, और, जबकि मुझे उन्हें उपयोग करने में थोड़ी देर लग गई, इसका मतलब था कि कोड हम सभी के द्वारा पठनीय था, और सभी तरह से वर्दी।
मुझे लगता है कि किसी भी कंपनी के भीतर कोडिंग मानकों को महत्वपूर्ण नहीं है, अगर कोई भी सेट नहीं है, तो डेवलपर्स और पठनीयता के साथ मुद्दों के बीच संघर्ष होने जा रहे हैं।
अंतिम उपयोगकर्ता को एक बेहतर कोड प्रस्तुत करने के माध्यम से कोड वर्दी को सभी तरह से रखने के लिए (ऐसा लगता है कि यह एक व्यक्ति द्वारा लिखा गया है - जो, अंतिम उपयोगकर्ताओं के दृष्टिकोण से, यह होना चाहिए - वह व्यक्ति " कंपनी "और यह टीम के भीतर पठनीयता के साथ भी मदद करता है ...
एक सामान्य कोडिंग शैली स्थिरता को बढ़ावा देती है और विभिन्न लोगों के लिए आसानी से समझने, बनाए रखने और विस्तार करने के लिए आसान बनाता है, न केवल अपने स्वयं के टुकड़े। नए लोगों के लिए कोड को तेज़ी से सीखना भी आसान बनाता है। इस प्रकार, किसी भी टीम के पास दिशानिर्देश होना चाहिए कि कोड को कैसे लिखा जाना चाहिए।
महत्वपूर्ण दिशानिर्देशों में शामिल हैं (विशेष रूप से नहीं आदेश):
इसके अलावा, प्रोग्रामर कि नहीं या टीम की शैली को चाहे कितना उज्ज्वल वे हो सकता है अनुकूलन नहीं कर सकते हैं से सावधान रहना। यदि वे टीम के नियमों में से किसी एक द्वारा नहीं खेलते हैं, तो वे शायद अन्य टीम के नियमों से भी नहीं खेलेंगे।
क्या आपको लगता है कि एक सॉफ्टवेयर कंपनी को डेवलपर्स को कोडिंग-शैली लागू करनी चाहिए?
शीर्ष-डाउन तरीके से नहीं। एक सॉफ्टवेयर कंपनी में डेवलपर्स को एक सामान्य कोडिंग शैली पर सहमत होना चाहिए।
यदि हां, तो आपकी राय में दिशानिर्देश कितने गहरे होंगे?
उन्हें विचलन को कम से कम रखने की कोशिश कर, प्रसिद्ध सम्मेलनों से मतभेदों का वर्णन करना चाहिए। यह पाइथन या जावा जैसी भाषाओं के लिए आसान है, सी/सी ++ के लिए कुछ हद तक धुंधला है, और पर्ल और रूबी के लिए लगभग असंभव है।
उदाहरण के लिए, कोड का इंडेंटेशन शामिल किया जाना चाहिए?
हां, यह कोड को और अधिक पठनीय बनाता है। रिक्त स्थान बनाम टैब के संदर्भ में इंडेंटेशन को लगातार रखें (और यदि आप रिक्त स्थान चुनते हैं) स्पेस वर्णों की संख्या। इसके अलावा, लंबी लाइनों के लिए मार्जिन (उदा। 76 वर्ण या 120 वर्ण) पर सहमति दें।
मैं सहमत हूं कि स्थिरता महत्वपूर्ण है। आप दिन बचाने के लिए आईडीई सुंदर प्रिंटिंग पर भरोसा नहीं कर सकते हैं, क्योंकि आपके कुछ डेवलपर्स आईडीई का उपयोग करना पसंद नहीं कर सकते हैं, और क्योंकि जब आप हजारों स्रोत फ़ाइलों के कोड बेस के माध्यम से ट्रैवल कर रहे हैं, तो यह सुंदरता के लिए संभव नहीं है जब आप उन पर काम करना शुरू करते हैं तो सभी फाइलों को प्रिंट करें, और बाद में रोल-बैक करें ताकि आपका वीसीएस सभी परिवर्तनों को वापस करने की कोशिश न करे (अनावश्यक अपडेट के साथ भंडार को क्लोज़ करना जो हर किसी को बोझ देता है)।
मैं कम से कम का मानकीकरण करने का सुझाव देते हैं निम्नलिखित (महत्व के घटते क्रम में):
ख (एक प्रारूप है कि स्वत: प्रलेखन पीढ़ी की अनुमति देता है का उपयोग करते हुए) मेटा डेटा के रूप में इस तरह के स्वरूपण को मानने के लिए आईडीई के लिए समाधान होगा। उदाहरण के लिए, ओपनिंग घुंघराले ब्रेस स्थिति (वर्तमान रेखा या अगली पंक्ति), ऑपरेटर के आसपास इंडेंटेशन और व्हाइट स्पेस स्रोत फ़ाइल को बदले बिना कॉन्फ़िगर करने योग्य होना चाहिए।
मेरे राय: के रूप में यह हर किसी के लिए मदद करता है पढ़ सकते हैं और बनाए रखने के लिए कोड
आधुनिक आईडीई आपको स्वरूपण टेम्पलेट को परिभाषित करने देते हैं। यदि कोई कॉर्पोरेट मानक है, तो एक कॉन्फ़िगरेशन फ़ाइल विकसित करें जो आपके द्वारा की जाने वाली सभी स्वरूपण मानों को परिभाषित करती है और सुनिश्चित करें कि प्रत्येक व्यक्ति अपने कोड में चेक करने से पहले फ़ॉर्मेटर चलाता है। यदि आप इसके बारे में और भी कठोर होना चाहते हैं तो आप इसे स्वीकार करने से पहले कोड को इंडेंट करने के लिए अपने संस्करण नियंत्रण प्रणाली के लिए एक प्रतिबद्ध हुक जोड़ सकते हैं।
हाँ एक सामान्य नामकरण मानक के साथ-साथ कक्षाओं के पीछे कक्षाओं और कोड का एक सामान्य लेआउट उपयोग करने के मामले में। बाकी सब कुछ खुला है।
प्रत्येक कंपनी को चाहिए। लगातार कोडिंग शैली आपकी पूरी टीम में कोडबेस की उच्च पठनीयता और रखरखाव सुनिश्चित करती है।
जिस दुकान में मैं काम करता हूं उसके पास एक एकीकृत कोडिंग मानक नहीं होता है, और मैं कह सकता हूं कि हम (एक टीम के रूप में) उस से काफी पीड़ित हैं। जब व्यक्तियों से कोई इच्छा नहीं होती है (जैसे कि मेरे कुछ सहयोगियों के मामले में), टीम के नेता को अपनी मुट्ठी को मेज पर धक्का देना होता है और मानकीकृत कोडिंग दिशानिर्देशों का कुछ रूप लगाया जाता है।
कभी-कभी भाषा में सामान्य मानक होते हैं जिनका उपयोग समुदाय द्वारा किया जाता है। आपको उन लोगों का भी पालन करना चाहिए जितना संभव हो सके ताकि आपका कोड भाषा में इस्तेमाल किए गए अन्य लोगों द्वारा बनाए रखा जा सके, लेकिन इसके बारे में तानाशाही करने की आवश्यकता नहीं है।
एक आधिकारिक मानक का निर्माण गलत है क्योंकि एक कंपनी कोडिंग मानक आमतौर पर बहुत कठोर है, और भाषा का उपयोग कर सामान्य समुदाय के साथ प्रवाह करने में असमर्थ है।
यदि आपको टीम के सदस्य के साथ समस्या हो रही है तो वास्तव में कोडिंग शैली में बाहर रहें, समूह के लिए धीरे-धीरे सुझाव देना एक अच्छी बात है कि कोड समीक्षा पर एक अच्छा विचार नहीं है।
कोडिंग मानकों: हाँ। पहले से ही इस धागे में शामिल कारणों के लिए।
स्टाइल मानकों: नहीं। आपका पठनीय, मेरा विस्मयकारी जंक है, और इसके विपरीत। अच्छी टिप्पणी और कोड फैक्टरिंग का बहुत अधिक लाभ है। इसके अलावा gnu इंडेंट।
मुझे इल्या के जवाब पसंद हैं क्योंकि इसमें पठनीयता के महत्व और प्रवर्तन तंत्र के रूप में निरंतर एकीकरण का उपयोग शामिल है। हिब्ररी ने एफएक्सकॉप का उल्लेख किया, और मुझे लगता है कि निर्माण प्रक्रिया में इसका उपयोग यह निर्धारित करने के लिए मानदंडों में से एक है कि कोई बिल्ड पास या असफलता मानक को दस्तावेज करने से अधिक लचीला और प्रभावी होगा।
मैं पूरी तरह से सहमत हूं कि कोडिंग मानकों को लागू किया जाना चाहिए, और यह लगभग हमेशा टीम स्तर पर होना चाहिए। हालांकि कुछ अपवाद हैं।
यदि टीम कोड लिख रही है जिसका उपयोग अन्य टीमों द्वारा किया जाना है (और यहां मेरा मतलब है कि अन्य टीमों को स्रोत को देखना होगा, न केवल लाइब्रेरी के रूप में इसका उपयोग करें) फिर सामान्य मानकों को बनाने के फायदे हैं इसका उपयोग कर सभी टीमों में। इसी प्रकार यदि कंपनी की नीति अक्सर प्रोग्रामर को एक टीम से दूसरी टीम में ले जाती है, या ऐसी स्थिति में है जहां एक टीम अक्सर दूसरी टीम से कोड का पुन: उपयोग करना चाहती है तो कंपनी में मानकों को लागू करना शायद सबसे अच्छा है।
दूसरों की तरह उल्लेख किया गया है, मुझे लगता है कि इसे इंजीनियरिंग या टीम द्वारा होना आवश्यक है - कंपनी (यानी व्यवसाय इकाइयां) इस तरह के निर्णय में शामिल नहीं होनी चाहिए।
लेकिन एक और चीज जिसे मैं जोड़ता हूं वह है कि लागू किए गए नियमों को उपकरण और लोगों द्वारा लागू किया जाना चाहिए। सबसे खराब स्थिति परिदृश्य, आईएमओ, कुछ अति उत्साही व्याकरण स्नोब है (हाँ, हम मौजूद हैं; मुझे पता है क्योंकि हम खुद को गंध कर सकते हैं) कोडिंग दिशानिर्देशों के एक सेट को रेखांकित करते हुए कुछ दस्तावेज लिखते हैं जो बिल्कुल कोई वास्तव में पढ़ता या अनुसरण नहीं करता है। वे समय के साथ अप्रचलित हो जाते हैं, और जैसे ही नए लोग टीम में जोड़े जाते हैं और बूढ़े लोग जाते हैं, वे बस बेवकूफ हो जाते हैं।
फिर, कुछ संघर्ष उत्पन्न होता है, और किसी को कोडिंग शैली के बारे में किसी और का सामना करने की असहज स्थिति में डाल दिया जाता है - इस प्रकार का टकराव उपकरण द्वारा किया जाना चाहिए, न कि लोगों द्वारा। संक्षेप में, प्रवर्तन की यह विधि कम से कम वांछनीय है, मेरी राय में, क्योंकि इसे अनदेखा करना बहुत आसान है और केवल प्रोग्रामर से बेवकूफ चीजों के बारे में बहस करने के लिए विनती करता है।
एक बेहतर विकल्प (फिर से, आईएमओ) को संकलन समय (या कुछ समान) पर चेतावनी दी जाती है, जब तक कि आपका निर्माण वातावरण इसका समर्थन करता हो। इसे VS.NET में कॉन्फ़िगर करना मुश्किल नहीं है, लेकिन मुझे अन्य विकास वातावरण से अनजान है जिनमें समान सुविधाएं हैं।
स्टाइल दिशानिर्देश बेहद महत्वपूर्ण हैं, चाहे वे डिज़ाइन या विकास के लिए हों, क्योंकि वे उन लोगों के संचार और प्रदर्शन को गति देते हैं जो सहयोगी रूप से काम करते हैं (या यहां तक कि अकेले, अनुक्रमिक रूप से, पुराने प्रोजेक्ट के टुकड़े उठाते समय)। किसी कंपनी के भीतर सम्मेलन की व्यवस्था होने के कारण लोगों को सिर्फ उतना ही अनुत्पादक होने के लिए कहा जा सकता है जितना वे कर सकते हैं। अधिकांश परियोजनाओं को सहयोग की आवश्यकता होती है, और यहां तक कि जो लोग हमारे प्रोग्रामिंग चॉप का उपयोग करने और वर्तमान रखने की हमारी प्राकृतिक इच्छा के प्रति संवेदनशील नहीं हो सकते हैं। सीखने की हमारी इच्छा हमारी स्थिरता के रास्ते में हो जाती है - जो कि अपने आप में और अच्छी बात है, लेकिन वे जिस नए सिस्टम पर कूद रहे हैं उसे सीखने की कोशिश कर रहे एक नए कर्मचारी को पागल कर सकते हैं।
किसी भी अन्य प्रणाली की तरह जो अच्छा और बुरा नहीं है, गाइड की असली शक्ति अपने लोगों के हाथों में है। डेवलपर्स स्वयं निर्धारित करेंगे कि आवश्यक और उपयोगी भाग क्या हैं और फिर, उम्मीद है कि उनका उपयोग करें।
कानून की तरह। या अंग्रेजी भाषा।
स्टाइल गाइड जितना गहरा होना चाहिए उतना गहरा होना चाहिए - यदि यह मंथन सत्र में आता है, तो इसे शामिल किया जाना चाहिए। यह अजीब बात है कि आपने सवाल कैसे कहा क्योंकि दिन के अंत में स्टाइल गाइड को "लागू" करने का कोई तरीका नहीं है क्योंकि यह केवल एक गाइड है।
आरटीएफएम, फिर अच्छी चीजें मिलें और इसके साथ आगे बढ़ें।
मुझे विश्वास नहीं है कि एक देव टीम के पास शैली के दिशानिर्देश होना चाहिए, उन्हें सामान्य नियम के रूप में पालन करना चाहिए। अपवाद हैं, उदाहरण के लिए the use of <> vs. "" in #include statements, लेकिन इन अपवादों को आवश्यकता से आना चाहिए।
लोगों को यह सुनाने का सबसे आम कारण है कि स्टाइल दिशानिर्देश आवश्यक क्यों हैं, एक सामान्य शैली में लिखे गए कोड को अलग-अलग शैलियों में लिखे गए कोड को बनाए रखना आसान है। मैं असहमत हूं। एक पेशेवर प्रोग्रामर फंस जा करने के लिए जब वे यह देखने नहीं जा रहा है:
for(int n = 0; n < 42; ++42) {
// blah
}
... जब वे इस को देखने के लिए उपयोग किया जाता है:
for(int n = 0; n < 42; ++42)
{
// blah
}
इसके अलावा, मैं ने पाया है कि यह वास्तव में आसान है कुछ मामलों में कोड बनाए रखें यदि आप प्रोग्रामर की पहचान कर सकते हैं जिन्होंने अपनी शैली को पहचानकर मूल कोड लिखा था। उनसे पूछें कि उन्होंने एक दिन के बेहतर हिस्से को खर्च करने के बजाय 10 मिनट में इस तरह के घुलनशील तरीके से जीजीएम को क्यों लागू किया, ताकि तकनीकी कारणों का पता चल सके कि उन्होंने कुछ अप्रत्याशित क्यों किया। सच है, प्रोग्रामर को अपने तर्क की व्याख्या करने के लिए कोड पर टिप्पणी करनी चाहिए थी, लेकिन असली दुनिया प्रोग्रामर अक्सर नहीं करते थे।
अंत में, यदि यह जो लेता है 10 मिनट & backspacing उसके घुंघराले ब्रेसिज़ चलती ताकि विधेयक 3 कम सेकंड खर्च कर सकते हैं कोड को देखते हुए, यह वास्तव में किसी भी समय बिल कुछ करना बनाने के लिए बचाने के लिए किया था कि उसे करने के लिए प्राकृतिक आता है ?
दो प्रकार के सम्मेलन हैं।
टाइप ए सम्मेलनों:
और प्रकार बी "इन कृपया, यह बेहतर है": "सड़क के दाहिने हाथ की ओर ड्राइव कृपया", जबकि यह दूसरे पक्ष पर ड्राइव करने के लिए ठीक है, के रूप में जब तक हर कोई एक ही तरह से करता है।
एक अलग टीम जैसी कोई चीज़ नहीं है। एक अच्छी फर्म में सभी कोड किसी भी तरह से जुड़ा हुआ है, और शैली सुसंगत होना चाहिए। बीस अलग शैलियों की तुलना में स्वयं को एक नई शैली में उपयोग करना आसान है।
इसके अलावा, एक नया डेवलपर मौजूदा कोडबेस के प्रथाओं का सम्मान करने और उनका पालन करने में सक्षम होना चाहिए।
आपका उत्तर बिल्कुल मेरे अनुभवों को बताता है। टीमों को अपने मानकों को परिभाषित करना चाहिए, जिसका लाभ यह है कि टीम के हर सदस्य ने उनमें एक कहा है (जिसे हम "खरीद-इन" कहते हैं)। हमारी टीम के नेता ने शायद ही कभी शैली पर "तानाशाही" निर्णय लिया, जब तक सर्वसम्मति तक नहीं पहुंचे, तब तक हमेशा चर्चा की जाती थी। –
मैं असहमत हूं। लोगों के बाद, एक सॉफ्टवेयर कंपनी का सबसे मूल्यवान संसाधन कोड है। टीमों के बीच मानकों की आवश्यकता होती है, अन्यथा प्रत्येक टीम एक द्वीप के अधिक से अधिक हो जाती है। और क्या होता है जब कोई टीम सदस्य किसी अन्य टीम में जाता है? ओह, नए "मानक" –
मुझे व्यक्तिगत अनुभव के माध्यम से मिला है और विभिन्न टीमों के साथ काम करना है जो प्रचार करने की सबसे आसान शैली है जो सबसे कमजोर है। यही है, विदेशी स्वरूपण, नामकरण योजनाओं आदि के साथ प्यार गिरने से बचें - पूरे केआईएसएस दर्शन। हम में से उन लोगों के लिए जिन्हें लेखकों की एक बड़ी विविधता से कोड के साथ काम करना पड़ा है, हम कई अलग-अलग शैलियों में उपयोग करते हैं ... वास्तव में उन विदेशी लोगों को छोड़कर जो सभी प्रकार के नए सम्मेलनों और स्वरूपण शैलियों को पेश करते हैं। इसे थोड़ा नीचे दबाएं और हम सभी के लिए एक ही पृष्ठ पर होना बहुत आसान होगा। – stinky472