क्या कोडिंग मानकों में बहुत अधिक एकरूपता हो सकती है?

12

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

उदाहरण के लिए if, एक पंक्ति बनाम एक पंक्ति में कई कथनों का कथन, c # ??null-coalescing संचालक का उपयोग करने के बजाय कहना == null, indentations के लिए रिक्ति की मात्रा आदि।

ऐसा लगता है कि यह एक व्यक्तिगत शैली की पसंद में अधिक होने लगी है और किसी टीम या कंपनी में समान होने की आवश्यकता नहीं है। एक व्यक्ति जो सोचता है वह अधिक स्पष्ट रूप से पढ़ता है दूसरा नहीं हो सकता है। क्या इस "अतिरिक्त" एकरूपता का कुछ मूल्य है?

programming-practices team coding-standards

— Gratzy
स्रोत

2

हाय ग्रात्ज़ी, प्रोग्रामर्स । एस एक चर्चा बोर्ड नहीं है ; हम यहां उन वास्तविक समस्याओं को हल करने के लिए हैं जिनका आप सामना कर रहे हैं। क्या आपको कोई वास्तविक समस्या है जिसे आप हल करने की कोशिश कर रहे हैं? यदि हां, तो क्या आप अपने प्रश्न को रचनात्मक बना सकते हैं और उत्तर को चर्चा का विषय बनने से रोक सकते हैं?

1

@ इसे एक और तरीके से रखने के लिए, ऐसी स्थिति को देखते हुए जिसे आप व्यक्तिगत रूप से सामना कर रहे हैं, एक सही उत्तर के लिए क्या मापदंड होंगे?

2

@ मेक ट्रैप एफएक्यू के अनुसार ये एक प्रश्न के मानदंड हैं। सभी व्यक्तिपरक प्रश्नों के रचनात्मक होने की उम्मीद है। हम इसे कैसे परिभाषित करते हैं? रचनात्मक व्यक्तिपरक प्रश्न ... 1. "क्यों" और "कैसे" की व्याख्या करने वाले उत्तरों को प्रेरित करें। 2. लंबे होते हैं, लघु नहीं, उत्तर देते हैं। 3. एक रचनात्मक, निष्पक्ष और निष्पक्ष स्वर है। 4. विचारों को विचारों पर साझा करने के लिए आमंत्रित करें। 5. इस बात पर जोर दें कि तथ्यों और संदर्भों के साथ राय का समर्थन किया जाना चाहिए। 6. केवल नासमझ सामाजिक मजाक से अधिक हैं। मेरा मानना है कि मेरा प्रश्न पहले 4 को बहुत कम से कम

— ग्रैटी

2

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

2

@ मर्क ट्रैप मैं पहले ही स्वीकार्य जवाब के लिए मानदंड बता चुका हूं और हां जैसा कि मैंने कहा है कि यह एक वास्तविक समस्या है और इस प्रश्न में रुचि से काफी स्पष्ट है और मैं कहूंगा कि अन्य लोग सहमत हैं।

— ग्रात्ज़ी

16

एकरूपता कोई समस्या नहीं है (यह अच्छा है) लेकिन कठोरता या अनम्यता हो सकती है। यदि आप एकरूपता के लिए प्रयास कर रहे हैं तो आप हठधर्मी हो जाते हैं, तो आप टीम को जो नुकसान पहुंचा रहे हैं, वह (संभवतः) परिणामस्वरूप होने वाली एकरूपता से अधिक हो सकता है।

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

— निकोल
स्रोत

1

मैं वहाँ गया हूँ

+1, कहा कि मेरा क्या मतलब है, लेकिन बेहतर है!

— फ्रस्ट्रेटेडविथफॉर्म्सडिजेनर

@ पियरे यह है कि अब आप फ्रीलांस क्यों हैं? :)

— निकोल

वास्तव में नहीं है, लेकिन मैं दिशा-निर्देशों के बारे में कुछ लोगों से मिल रहा हूं। यह डरावना है कि यह चरम कैसे हो सकता है। मुझे लगता है कि आपने सीमा को अच्छी तरह से परिभाषित किया है।

7

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

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

— FrustratedWithFormsDesigner
स्रोत

हाँ, आप शायद वहाँ कहीं एक चींटी स्क्रिप्ट छड़ी सकता है।

— माइकल के

1

इंटेलीज, कम से कम, चेकइन से पहले सुधार कोड का एक विकल्प है।

— निकोल

3

ओवर-एकरूपता के एक मामले को मैंने देखा है कि एक एकल मानक है जो सभी प्रोग्रामिंग भाषाओं पर लागू होता है, भले ही उपयुक्तता की परवाह किए बिना:

हतोत्साहित gotoबिना सी जैसी भाषाओं में भी try... catch।
InitialCapsजावास्क्रिप्ट में नाम का उपयोग करना (जैसा कि माइक्रोसॉफ्ट के MFC और C # में है) जहां मानक पुस्तकालय है initialLowerCase।

— dan04
स्रोत

2

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

— JohnFx
स्रोत

2

@ तुंगानो मैं अधिक सहमत नहीं हो सका। कोडिंग मानकों का विरोधाभास यह है कि वे अच्छी तरह से लायक हैं, लेकिन वे बहस करने लायक नहीं हैं।

— चार्ल्स ई। ग्रांट

3

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

— JohnFx

1

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

— चार्ल्स ई। ग्रांट

1

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

— JohnFx

1

मैं हमारी जर्मन टीम, OSS परियोजनाओं के एक जोड़े और कुछ प्राचीन कोड के साथ-साथ हमारे वर्तमान सामान के कोड के साथ काम करता हूं। कुछ C, कुछ C ++, कुछ C # हैं। इसलिए मुझे हर समय कई अलग-अलग कोड शैलियों के साथ काम करना होगा। जब आप ऐसा करते हैं, तो आपको एहसास होता है कि मानकों में अनिवार्य होने वाले स्टाइल दिशा-निर्देश कितने कम हैं। अगर मैं एक से दूसरे प्रोजेक्ट में जा सकता हूं, तो मैं किसी को अपने {} को अलग-अलग जगहों पर रख सकता हूं। यही कारण है कि मुझे लगता है कि लानत के लायक एकमात्र मानक 1 नियम वाला है: "प्रत्येक परियोजना के भीतर स्थिरता"।

— gbjbaanb

2

मेरे पास एकरूपता के लिए 2 तर्क होंगे:

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

— जेबी किंग
स्रोत