उन सभी कोडिंग नियमों के बारे में क्या?

Question

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

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

Comments

यदि आप C # भाषा के रूप में उपयोग कर रहे हैं, तो StyleCop का उपयोग करें। यदि जावा का उपयोग कर रहे हैं ...

— नौकरी

@ जो - हां, हम ज्यादातर # का उपयोग कर रहे हैं। स्टाइलकॉप दिलचस्प लग रहा है।

— TheBoyan

Answer 1

उन्हें एक समस्या को ठीक करने में शामिल करें बल्कि नियमों से लड़ें। मैं व्यक्तिगत रूप से "स्टाइल गाइड", "कोडिंग मानकों" या कुछ इसी तरह के विचारों को पसंद करता हूं, इस उम्मीद में कि यह घुटने के झटके को रोकता है "नियम = खराब" प्रतिक्रिया।

लेकिन अगर ऐसा होता है - मुझे लगता है कि नियम एक कारण के लिए जगह में हैं, और कठिन नेतृत्व वाले लोगों को घुमाने के लिए उन्हें यह महसूस करने का तरीका है कि दिशानिर्देशों का पालन करके, वे कोड को आसान बनाने में मदद कर रहे हैं सभी के लिए पढ़ें।

कभी-कभी पीयर प्रेशर इसके लिए सबसे अच्छा उपाय है।

Comments

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

— बीकागुक

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

— २१:२० बजे betlakshmi

Answer 2

मेरे काम पर हम निम्नलिखित तीन समाधानों का उपयोग करते हैं:

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

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

3) कोड समीक्षा। उम्मीद है कि आप इन्हें वैसे भी कर रहे हैं, लेकिन एक बात पर प्रकाश डाला जाना चाहिए जहां कोडिंग नियम / शैली सम्मेलन को तोड़ रहे हैं।

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

Comments

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

— बिलथोर

Answer 3

इससे जो वास्तविक समस्या आती है, वह यह है कि उन हार्ड हेड्स को कैसे बनाया जाए, जो अगर स्टेटमेंट्स में ब्रैकेट्स का उपयोग करना पसंद नहीं करते हैं, या कोड में हर जगह समान कनेक्शन स्ट्रिंग का उपयोग करते हैं, या जो भी हो,

क्या उन्हें कोष्ठक का उपयोग नहीं करके "हार्ड हेड" किया जा रहा है या यह "हार्ड हेड" अनुरोध है?

अपनी लड़ाई उठाओ। मुझे संदेह है कि यह लेने लायक लोगों में से एक है। मैं कहीं भी काम करने का आनंद नहीं ले पाऊंगा जो कि "कोड में पहली जांच" पर इस स्तर के विस्तार के आस-पास कहीं भी अपेक्षित हो । यह एक लाल झंडा संकेतक है जिसे टीम रिफैक्टरिंग नहीं समझती है।

OO 101 : "रिफैक्टर जब उत्पाद करता है तो उसे क्या करना है"। पहले नहीं।

Comments

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

— TheBoyan

Answer 4

बड़ी टीमों में हर एक डेवलपर के कंधे पर बैठना बहुत मुश्किल है, यह सुनिश्चित करते हुए कि वे ब्रेसिज़ लगाते हैं जहां आपको लगता है कि उन्हें जाना चाहिए - उस पर मेरा विश्वास करो;)।

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

बेशक, कुछ कंपनियां जूनियर प्रोग्रामर से पूरी तरह से चेक-इन विशेषाधिकार ले लेती हैं। जब वे अंत में कंपनियों को नियम कोडिंग सीखते हैं, तो उन्हें विशेषाधिकार प्राप्त होता है।

Comments

अगर ब्रेस प्लेसमेंट आपकी सबसे बड़ी गुणवत्ता की समस्या है, तो मुझे लगता है कि आप बहुत भाग्यशाली हैं। क्या इस पर ध्यान देने का सही स्तर है?

— बो पर्सन

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

— मार्टिन ब्लोर

लेकिन ब्रेसिज़ जहां आपको लगता है कि उन्हें जाना चाहिए ... वह वॉल्यूम बोलता है। मुझे लगता है कि कोडिंग पठनीयता / कोडिंग मानकों के अधिक मूलभूत पहलू हैं तो ब्रेस प्लेसमेंट। मैं सहमत हूँ कि परियोजना पर सभी को एक ही मानक का पालन करना चाहिए, लेकिन दूसरे के यहाँ एक बात बहुत मायने नहीं रखती है। हो सकता है कि आप उन्हें कोडिंग मानकों पर आपके अन्य सुझावों को स्वीकार करने के बदले में ब्रेस प्लेसमेंट की लड़ाई को "जीतने" दें? इतना ही नहीं बल्कि वे समाधान का हिस्सा महसूस करेंगे अगर उनके ब्रेसिज़ प्लेसमेंट का विचार मानकों में है।

— गाइल्स

बिल्कुल सही। मैंने एक डेवलपर को इनलाइन ब्रैकेट्स के बजाय अपनी लाइन पर ब्रैकेट्स करने के लिए मनाने की कोशिश की, उसके बदले में SOLID और TDD सीखने के लिए ... एक बड़ा व्यापार जो मैं कहूंगा;)।

— मार्टिन ब्लेर

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

— ओसोडो

Answer 5

मुझे लगता है कि आप बहुत अलग स्तरों की समस्याओं के बारे में बात कर रहे हैं:

उन हार्ड हेड्स को कैसे बनाया जाए जो अगर स्टेटमेंट्स में ब्रैकेट्स का उपयोग करना पसंद नहीं करते हैं,

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

या कोड में हर जगह एक ही कनेक्शन स्ट्रिंग का उपयोग करें,

यदि आप जादू कॉन्स्टेंट का मतलब है, कि वास्तव में एक रखरखाव (प्लस संभावित सुरक्षा) समस्या है, और इस तरह के IMHO के रूप में किसी भी अनुभवी डेवलपर समझ जाएगा और स्वीकार करते हैं कि यह एक खराब बात है।

या जो भी हो, विचार का विरोध किए बिना कोडिंग नियमों का उपयोग करना?

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

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

Comments

"स्वीकार किए गए नियमों के अनुसार, चेक-इन पर स्वचालित कोड फ़ॉर्मेटिंग शुरू करना" ... यह दिलचस्प लगता है, आगे के विचारों पर जहां मुझे ऐसा कुछ मिल सकता है।

— TheBoyan

@bojanskr, आजकल के अधिकांश मुख्यधारा के IDE कुछ हद तक या उससे अधिक सीमा तक कोड कोडिंग नियमों का समर्थन करते हैं, और अपने कोड को सेव या चेकइन पर स्वतः प्रमाणित कर सकते हैं। जावा के लिए, एक्लिप्स और इंटेलीज दोनों करते हैं, मुझे लगता है कि नेटबीन्स भी हैं, लेकिन मुझे इसके साथ बहुत अनुभव नहीं मिला है। C # के लिए, @ नौकरी की टिप्पणी ऊपर देखें। लेकिन स्टैंडअलोन टूल भी हैं, जैसे कि C / C ++ के लिए आर्टिस्टिक स्टाइल। और अधिकांश SCCs मुझे पता है कि उदाहरण के लिए चेकइन पर उपयोगकर्ता-विशिष्ट स्क्रिप्ट / ट्रिगर्स के निष्पादन का समर्थन करता है।

— पेटर तोर्क

Answer 6

उन्हें नियम स्थापित करने में शामिल करें। यह आमतौर पर लोगों को उनका पालन करने के लिए प्रोत्साहित करने में मदद करता है।

Answer 7

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

Answer 8

हर जगह एक ही कनेक्शन स्ट्रिंग? इसका समाधान यह है कि जब तक आप सभी डुप्लीकेशन को हटा नहीं देते हैं तब तक रिफ्लेक्टर करना है। कॉपी-पेस्ट कोडर्स को प्रोग्रामर जेल में जाना चाहिए। (हँसो मत! स्टीव बाल्मर वार्डन हैं।)

लेकिन यहाँ वास्तविक समस्या आपकी क्रिया "मेक" है । आप प्रोग्रामर को कुछ भी नहीं कर सकते हैं, और यदि आप करते हैं, तो आप उनकी सबसे मूल्यवान विशेषता को बर्बाद कर रहे हैं: गहरी बौद्धिक सगाई जो आपके द्वारा परवाह की जाने वाली चीज़ पर काम करने से आती है।

जिस तरह से मैं इसे हल करेंगे:

1. जोर देकर कहते हैं कि टीम का एक सामान्य कोडिंग मानक है। यह 5 लाइनें लंबी हो सकती हैं, लेकिन इन सभी को सहमत होना होगा।
2. हर बार जब आप किसी तर्क पर ध्यान देते हैं, तो वे इसे एक साथ निपटाने और कोडिंग मानक में डालते हैं। यदि आप लोगों को आगे और पीछे की चीजों को सुधारते हुए देखते हैं, तो उसे एक तर्क के रूप में देखें।
3. जब भी एक मानक आइटम पर सहमति दी जाती है, तो देखें कि क्या एक उपकरण है जो एक बार में पूरे कोड आधार को साफ करेगा।
4. प्रत्येक दो महीने में, कोडिंग मानक से गुजरते हैं और देखते हैं कि कौन से अभी भी सही और प्रासंगिक हैं। मानक सिर्फ दस्तावेजों का है कि लोग क्या कर रहे हैं। और वस्तुओं को मानक में रखने का कोई मतलब नहीं है जो स्पष्ट हो गए हैं।

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