काम पर कोडिंग मानकों को संभालना (मैं मालिक नहीं हूं)


40

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

या फिर मैं एक फ़ाइल खोलूंगा और कुछ पंक्तियों में उसी लाइन पर घुंघराले कोष्ठक हैं जैसे कि स्थिति है जबकि अन्य अगली पंक्ति में हैं। फिर से, मुझे कोई आपत्ति नहीं है कि जब तक वे सभी समान हैं।

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

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

आपका समय देने के लिए आभार।

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

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


3
कुछ मर्ज टूल व्हॉट्सएप डिफरेंस को नजरअंदाज करने का विकल्प देते हैं। यह मूल कारण को हल नहीं करेगा, लेकिन मध्यवर्ती दर्द को कम कर सकता है ...
FrustratedWithFormsDesigner

5
जब आप स्रोत नियंत्रण में धकेल दिए जाते हैं तो आप कोड को प्रारूपित करने के अपने प्रबंधक के समाधान को पसंद क्यों नहीं करते?
लैरी कोलमैन

5
मुझे लगता है कि यह एक सामाजिक समस्या है, न कि तकनीकी समस्या। यदि टीम मानकों पर सहमत नहीं हो सकती है, तो IMO तकनीक की कोई राशि मदद करने वाली नहीं है।
ब्रायन ओकले

11
हर व्यक्ति को एक ही सेटिंग के साथ आईडीई ऑटोफार्माट का उपयोग करना चाहिए। बस कर दो।

1
@ थोरबजोरन - सहमत। हमने कल ही वैश्विक आईडीई सेटिंग जारी की।
एड्रियन जे। मोरेनो

जवाबों:


73

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

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

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


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

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

2
+1 यह बिल्कुल वैसा ही है कि हमने उसी स्थिति को संभाला है। मैंने पाया है कि उदाहरण के लिए अग्रणी अक्सर एक विकास की दुकान में कई समस्याओं को हल करता है - लेकिन आपको दूसरों से जीत खरीदना पड़ता है। यदि आप केवल एक ही रास्ता धधक रहे हैं, तो आपको संभवतः पहले स्थान पर पथ का पुनर्मूल्यांकन करना चाहिए।
जुडुव

1
जोएल, इस कहानी ने मेरे सहकर्मियों को प्रेरित किया है और मैं आपकी कहानी को एक टेम्पलेट के रूप में उपयोग करते हुए मशाल उठा रहा हूं।
जोश जॉनसन

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

6

मानकों को किसी प्रबंधक द्वारा परिभाषित और लागू नहीं किया जाना चाहिए। एक पूरे के रूप में टीम मानकों के लिए सहमत होना चाहिए। यदि वे मानकों के एक सामान्य सेट पर सहमत नहीं हो सकते हैं, तो उन पर मानकों को लागू करने के लिए एक प्रबंधक प्राप्त करना विफल हो जाएगा।

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

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


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

3
खैर तकनीकी रूप से वहाँ है : एक एक सच्चे ब्रेस शैली en.wikipedia.org/wiki/Indent_style#Variant:_1TBS
को पुनः स्थापित मोनिका

@ सेमज: मैं पूरी तरह से असहमत हूं। यह प्रबंधक तक नहीं होना चाहिए। थोड़ा भी नहीं।
ब्रायन ओकले

दूसरी ओर, आप एक प्रोग्रामिंग टीम, किसी के कर्मचारी, हिप्पी कम्यून नहीं हैं। यदि परियोजना विफल हो जाती है तो किसका सिर घूमता है? मैं किसी के किए की गारंटी देता हूं। अगर हर कोई जिम्मेदार है, तो कोई भी नहीं है। देखें इस , यह , यह , आदि
क्रेग

"कौन का सिर घूमता है," मेरा मतलब था। जाहिर है ...
क्रेग

5

क्या आप इसके कारण होने वाली समस्याओं के कारण बर्बाद होने वाले समय का कुछ सबूत दिखा सकते हैं?

यदि आप इन समस्याओं को पूरा करने के लिए समय की एक महत्वपूर्ण राशि खर्च कर रहे हैं, या यह बगों को ठीक करने में समय लगा रहा है, तो यह एक लागत है जिसे आप कोडिंग मानकों को अपनाकर काफी कम कर सकते हैं।

इसलिए आपके द्वारा सामना की जाने वाली समस्याओं और उन्हें हल करने में लगने वाले समय का एक लॉग रखें - आपके लिए और आपके सहयोगियों के लिए दोनों (जहाँ आप उनके बारे में जानते हैं)।

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


3

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

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


3
मैं जो भी लाइन पर ब्रेस के साथ ठीक हूं। जब दोनों शैलियाँ एक ही फ़ाइल में होती हैं, तो मैं बंद हो जाता हूं । इसे स्कैन करना कठिन बनाता है।
जोश जॉन्सन

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

2

कोडिंग मानकों के बारे में: मैं यह कहते हुए लगभग सभी के साथ बोर्ड पर चढ़ जाऊंगा कि कोडिंग मानक एक "अच्छी बात है" (बनाम कोई मानक नहीं)।

हालाँकि, दूर मत जाओ। मैंने कुछ परियोजनाओं पर काम किया है, जो एक विशिष्ट इंडेंटेशन शैली को निर्देशित करती हैं, वर्णों की संख्या के ठीक नीचे (और जब प्रोजेक्ट उस पर चलते हैं, तो वे अनिवार्य रूप से 8 स्पेस इंडेंट की तरह कुछ बेवकूफ चुनते हैं)। छोटे सामान पसीना मत करो।

एक सरल समाधान: डेवलपर्स को ब्रेस और इंडेंटेशन के लिए विकल्पों का एक सीमित सेट दें, लेकिन यह निर्धारित करें कि ब्रेस स्टाइल और इंडेंटेशन एक मॉड्यूल के अनुरूप होना चाहिए। (आप एक ही शैली का पालन करने के लिए foo.h और foo.cpp चाहते हैं, क्या आप नहीं?) बनाए रखने के लिए मौजूदा शैली के अनुकूल होना चाहिए; वे अपनी सनकी शैली के अनुरूप एक मॉड्यूल को फिर से नहीं लिख सकते हैं। एक मॉड्यूल के भीतर कई शैलियों बस भ्रामक है और ढलान का संकेत है। जब मैं उस बकवास को देखता हूं तो मुझे आश्चर्य होता है कि और क्या गलत है।

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

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


3
या आप सिर्फ टैब और अलग-अलग देवों का उपयोग कर सकते हैं जो भी चाहें उन्हें आकार दे सकते हैं ..
मोनिका

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

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

2
यह बाद में रिक्त स्थान हैं जो इस विचार को मारते हैं। "नो फाइल्स इन सोर्स फाइल्स" नियम कई, कई कोडिंग मानकों के लिए सामान्य है। इसका एक कारण है।
डेविड हैमेन

1

यह उन क्षेत्रों में से एक है जिसमें कुछ शोध किए जाते हैं। मूल रूप से मुख्य प्रश्न यह है कि क्या आप कोड समीक्षा कर रहे हैं। कोड समीक्षाएँ एक शक के बिना हैं कोड गुणवत्ता में सुधार करने के लिए सबसे कुशल साधन। (स्रोत: सॉफ्टवेयर इंजीनियरिंग संस्थान, सीएमयू)। यह निश्चित रूप से एक अतिरिक्त परीक्षक की तुलना में अधिक कुशल है।

अब, कोड समीक्षाएँ एक सामान्य कोडिंग मानक से लाभ उठाती हैं, क्योंकि इससे अन्य लोगों के कोड को पढ़ना आसान हो जाता है। कोडिंग मानकों को पेश करने के लिए आपको दो-चरणीय तर्क प्रदान करता है: अंत में, यह अच्छे कोड का उत्पादन करने के लिए सस्ता बनाता है।


1

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

फिर, देखें कि क्या आप सभी कुछ बुनियादी अवधारणाओं पर सहमत हो सकते हैं। प्रत्येक मॉड्यूल के भीतर एक ही शैली का उपयोग करने का सुझाव जो @David Hammen ने लाया है वह एक अच्छी शुरुआत है, और मुझे लगता है कि अधिकांश डेवलपर्स आसानी से सहमत हो सकते हैं।

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

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


1

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

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

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

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


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

0

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

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

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

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


0

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

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

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


0

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


0

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

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


0

यह कोशिश मत करो!

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

यदि आप अपने सहकर्मियों (!!) के बहकावे में नहीं आते हैं, तो आप एक कोडिंग मानक के साथ समाप्त हो सकते हैं।

जाहिर है, यह एक उच्च जोखिम रणनीति है ... :-)


असल में, कुछ लोग हैं जो अब इसे आज़मा रहे हैं और कई लोग जिन्होंने इस रणनीति का इस्तेमाल किया है। उनके सर्वोत्तम प्रयासों के बावजूद, कोई भी मानक इस प्रकार सामने नहीं आए हैं :(
जॉनसन जॉन

@ जॉन जॉनसन - उन्होंने स्पष्ट रूप से पर्याप्त प्रयास नहीं किया है। सभी पहचानकर्ताओं पर ROT-13 का उपयोग करने पर विचार करें :-)
स्टीफन C
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.