कोडिंग मानकों को कार्यान्वित और लागू करना

Question

मेरी टीम (जिसमें से मैं नवीनतम और सबसे जूनियर सदस्य हूं) आकार में 3 से 9 डेवलपर्स के आकार में लगभग 1 वर्ष में वृद्धि हुई है। हमारा प्राथमिक उत्पाद जटिलता में बढ़ गया है और हम सिल्वरलाइट को एक साल का लंबा बंदरगाह/पुनः लिखने वाले हैं। अतीत में कोई विशिष्ट शैली/मानक लागू नहीं किया गया है।

मैंने अपने मालिक को सुझाव दिया कि अब ऐसे मानकों को लागू करने का एक अच्छा समय होगा। मैंने उन्हें IDesign's दस्तावेज पास कर दिया और उन्हें विचार पसंद आया। उसके पास 2 चिंताएं हैं।

1. यह अवशोषित करने के लिए एक बड़ा दस्तावेज़ है। मेरा विचार यहां सबसे आम वस्तुओं के लिए एक स्लिम डाउन चीट-शीट विकसित करना है जिसे हम चलाने की संभावना रखते हैं, यह समझने के साथ कि आईडीसीन मानक "मास्टर" है और स्लिममेड डाउन संस्करण में शामिल कुछ भी नहीं देखा जाना चाहिए "मास्टर" दस्तावेज़ में ऊपर।

2. इसे लागू करने का सबसे अच्छा तरीका क्या है। यह निर्देश देने की कोशिश करने का सवाल नहीं है; यह किसी विशेष मानक के विकास के लिए उपयोग किए जाने वाले लोगों को प्राप्त करने का प्रयास करने का विषय है। टीम पर कम से कम 2 लोग हैं जो कई वर्षों से वर्तमान गैर मानक के लिए विकास कर रहे हैं। इस चिंता को हल करने के लिए, मैं यह देखना चाहता हूं कि कोई ऐसा उपकरण है जिसे इन मानकों को लागू करने के लिए कॉन्फ़िगर किया जा सकता है, या किसी संकलन-समय या डिज़ाइन-टाइम पर मानक के "उल्लंघनों" की न्यूनतम चेतावनी पर। मैंने माइक्रोसॉफ्ट स्टाइलकॉप पाया, लेकिन जो मैं निर्धारित करने में सक्षम हूं, यह कॉन्फ़िगर करने योग्य नहीं है और माइक्रोसॉफ्ट के मानक का पालन करने के लिए स्थापित है, जो पूरी तरह से IDesign के साथ जाल नहीं करता है।

उपकरण या दृष्टिकोण पर कोई भी इनपुट मेरी सराहना की जाएगी।

Answer 1

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

Answer 2

रीशेर्पर आज़माएं, यह आपके कोड को आपकी शैली में प्रारूपित कर सकता है। एक ही समय में पूरे समाधान को दोबारा सुधारें।

Answer 3

नियमित कोड समीक्षा जाने के लिए एक अच्छा तरीका होगा ...

मैंने पाया डेवलपर्स बेहतर सामना करने वाली सामना करने के लिए के बजाय एक विशेष मानक के लिए एक उपकरण के लिए पूरी तरह से इसे छोड़ने के बारे में विचार-विमर्श के जवाब देते हैं।

कोड समीक्षाओं के साथ एक उपकरण का उपयोग करना अच्छा होना चाहिए।

Answer 4

स्टाइलकॉप एक बड़ी मदद होगी।

Answer 5

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

Answer 6

आपकी सलाह के लिए सभी को धन्यवाद। मुझे और सुनना अच्छा लगेगा। जैसा कि होता है, जब मैं Ilya Ryzhenkov द्वारा अनुशंसित रिशेर्पर में देख रहा था, तो मुझे IDESign मानक फिर से डाउनलोड करना पड़ा, जो कि blog entry के लिंक के साथ एक ज़िप फ़ाइल में आता है। अच्छा हिस्सा यह है कि मैं उस मानक के लिए डिफ़ॉल्ट हूं जिसका उपयोग मैं करना चाहता हूं। यह सस्ता है (अगर आप दान नहीं करते हैं तो मुफ्त पढ़ें) और Code-Rush! and Refactor का बड़ा प्रशंसक बनने के लिए, इसलिए मेरे पास पहले से ही DXCore लोड हो गया है!

Answer 7

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

अलग-अलग टूल्स आपको डेवलपर्स को कोडिंग मानक के मूल्य को चित्रित करने का एक तरीका खोजना होगा। सरल लगता है लेकिन अब तक मेरे लिए यह सबसे कठिन हिस्सा रहा है। डेवलपर्स को दिखाएं कि कोड बेस बनाए रखने की बात आने पर थोड़ा सा प्रयास लंबा रास्ता तय कर सकता है।

Answer 8

कोडिंग मानकों के महत्व को ओवरस्टेट करना मुश्किल है। कुंजी यह है कि आपके पास एक सतत कोड आधार होना चाहिए जो हर कोई जल्दी से पढ़ और समझ सके। यह कम महत्वपूर्ण है कि आपके द्वारा चुने गए मानकों का सेट (जब तक हर कोई साइन अप करता है) - लेकिन यदि आप एक मानक चुनते हैं जिसका व्यापक रूप से उपयोग किया जाता है तो कम डेवलपर्स को अपनी शैली को समायोजित करना होगा। Microsoft Design Guidelines for Class Library Developers मेरे पसंदीदा हैं (और बहुत ReSharper दोस्ताना)।

मेरा एक सहयोगी (Howard van Rooijen) और उनकी ओपन-सोर्स टीम उत्कृष्ट StyleCop for ReSharper विकसित कर रही है जो आपको टाइप करते समय उन्हें हाइलाइट करके वास्तविक समय में शैली उल्लंघन दिखाती है! recent release रहा है जिसे दिल से अनुशंसा की जाती है।

Answer 9

मैंने हाल ही में रीशेपर और स्टाइलकॉप का उपयोग करने पर एक ब्लॉग लिखा है, और निरंतर एकीकरण (NANT का उपयोग करके) के माध्यम से इसे लागू किया है।

http://www.robertbeal.com/archives/47

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

मैं एक बार जवाब में यह भेजा गया, हिटलर की रात बिल्ड विफल: http://www.youtube.com/watch?v=Azl4nqLn4-Y

Answer 10

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

2 स्लाइड्स में कंपनी के पूर्ण कोडिंग दिशानिर्देश के सबसे महत्वपूर्ण पहलुओं को रखें (उदाहरण के लिए हमारे पास है: कोडिंग शैली, नामस्थान & समाधान संरचना, नामकरण सम्मेलन)।

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

Answer 11

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

एक जटिल सम्मेलन के लिए बेहतर है जो कि एक बड़े जटिल दस्तावेज़ के बाद पालन किया जाता है जिसका पालन नहीं किया जाता है।

एक तरफ, क्या आपने टीम से उचित सुनिश्चित किया है?

अल सबसे सब कोड के मानकों मैंने देखा है जो की तरह

public bool compare (Object other){ 
    if(other == null) throw new NullPointerException("You twit, don't give me a null pointer"); 
    if(!(other instanceof CustomerObject)) throw new UnsupportedArgumentException("Give me the right argument, dammit"); 
    ... 

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

Answer 12

मेरी वर्तमान कंपनी में कोडिंग मानकों पर खरीद-इन प्राप्त करने के अनुभव से मेरे अनुभव से नोट्स (कई परियोजनाओं के छोटे आकार के डेवलपर, प्रत्येक के साथ 1-6 प्रोग्रामर के साथ; हम मुख्य रूप से सी ++ हैं लेकिन मुझे लगता है कि उत्तर अभी भी लागू होंगे):

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

अपनी समीक्षा विभाजित करें। कुछ औपचारिक समीक्षा मांगते हैं, कुछ नहीं करते हैं।

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

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

मैं इस बिट पर पर्याप्त जोर नहीं दे सकता: छोटी सामग्री पर पसीना नहीं पड़ेगा। (अद्भुत सी ++ मानक पुस्तक कोडिंग की बात # 0 देखें।)

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

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

Answer 13

एक ग # आधार के साथ TFS और VS 2010, का उपयोग करना, हम इसे इस तरह कार्य करें:

हम अपने ऑन-पेपर कोड मानक के रूप में गैर-संपादित idesign मानक का उपयोग करें।

हम कोड विश्लेषण और स्टाइल कॉप परिभाषाओं का एक सेट बनाए रखते हैं जिसे हम शून्य सहनशीलता के साथ रिलीज बिल्ड पर चलाते हैं।

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

हम डेवलपर को रूट परिभाषा को ओवरराइड करने की अनुमति देते हैं।

मानक संघर्ष जो इन दो स्तरों द्वारा नहीं उठाए जाते हैं, फिर समीक्षा प्रक्रिया में पाए जाते हैं और हल किए जाते हैं। समीक्षा में जो पाया नहीं है कोड रखरखाव में पाया जाता है।