क्या सभी डेवलपर्स के लिए समान विचारधारा एक अच्छा विचार है?


88

हम अपनी परियोजना में एकल मानक कोड प्रारूप (ऑटो फॉर्मेट इन एक्लिप्स में बचत कार्यों के साथ) लगाने पर विचार कर रहे हैं। कारण यह है कि वर्तमान में कई (> 10) डेवलपर्स द्वारा उपयोग किए जाने वाले कोड प्रारूपों में एक बड़ा अंतर है जो एक डेवलपर के लिए दूसरे डेवलपर के कोड पर काम करना कठिन बनाता है। एक ही जावा फ़ाइल कभी-कभी 3 विभिन्न स्वरूपों का उपयोग करती है।

इसलिए मेरा मानना ​​है कि लाभ स्पष्ट (पठनीयता => उत्पादकता) है लेकिन क्या इसे लागू करना अच्छा होगा? और यदि नहीं, तो क्यों?

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


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

9
क्या यह वास्तव में एक डेवलपर के लिए दूसरे के कोड पर काम करना कठिन बनाता है, या क्या डेवलपर्स को थोड़ा अलग कोड पढ़ने से एलर्जी हो रही है?
जोरिस टिम्मरमन्स 14

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

4
मैं यहाँ मार्टिन से असहमत हूँ, अच्छी तरह से। मेरे अंगूठे का नियम यह है कि यदि आप एक तार्किक / शब्दार्थ परिवर्तन करते हैं, तो आपको आपके द्वारा परिवर्तित लाइनों के प्रारूप को बदलने की अनुमति दी जाती है, अन्यथा आपको लाइनों के प्रारूप को केवल इसलिए बदलने की अनुमति नहीं है क्योंकि आप इसे कल्पना करते हैं। पेटी सुधार परिवर्तनों के साथ अपने संस्करण नियंत्रण लॉग को रोकना न करें।
बेनेडिक्ट

3
दूसरी ओर: यदि हर कोई एक ही प्रारूप का उपयोग करता है, तो केवल सब कुछ सुधार के लिए पहली प्रतिबद्धता से भरा होगा। बाकी सब कुछ सिर्फ स्थानीय परिवर्तनों को छूएगा, जो मेरी राय में स्वीकार्य है।
जीरो वेनवेल

जवाबों:


107

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

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

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

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

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


20
+100 प्रोग्रामर के अहं (और स्वामित्व) को समीकरण से बाहर ले जाने पर। प्रोग्रामर कोड के हिस्सों के लिए "दावा" करते हैं, यह उत्पादकता में योगदान नहीं करता है क्योंकि यह ज्ञान साझा करने में बाधा डालता है और इसका मतलब है कि एक संकेत दिया गया है जो सभी प्रोग्रामर कोड के समान टुकड़े पर काम नहीं कर सकते हैं।
मार्को

यह तय करना मुश्किल था कि कौन से उत्तर को स्वीकार करना है लेकिन मैंने पाया कि यह सबसे अच्छा तर्क है और वास्तविक सवाल का सबसे अच्छा समाधान है।
स्टिजेन ज्यूकेन्स

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

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

कड़ी चेतावनी और त्रुटियाँ एक अच्छी बात है।
क्रिस्टोफ रूसो

37

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

कई सॉफ्टवेयर डेवलपर्स इंजील युद्धों को छेड़ते हैं ......

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


Tx, मुझे पता है कि आपका क्या मतलब है
Stijn Geukens

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

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

2
इन पवित्र युद्धों में से अधिकांश को आज़माने और दूर करने का सबसे अच्छा तरीका भाषा की चूक को स्वीकार करना है जहां कभी भी संभव हो। हां, इसका मतलब है कि आपकी कोडिंग शैली भाषाओं में भिन्न होगी (पूर्व C # कोड में अलग-अलग लाइनों पर {java के पास पूर्व पंक्ति में होंगे, और पास्कलडेड या कैमल कैडेड अलग-अलग होंगे); जब आप प्रोजेक्ट पर नए डेवलपर्स लाएंगे तो प्रत्येक व्यक्तिगत भाषा स्रोत 'सामान्य' दिखाई देगा।
डैन नीली

1
@ruakh MSDN C # कोड के नमूने को देखें, कैसे Visual Studio सुधारों को C # डिफ़ॉल्ट रूप से देखें: {यह स्वयं की रेखा पर है। ओरेकल के दस्तावेज़ीकरण में जावा के लिए अभ्यास दोहराएं और कोडेट में सुधार करते समय ग्रहण की चूक: {ऊपर की लाइन पर है।
दान नीली

30

हां, यह अच्छा है कि सभी डेवलपर्स के लिए एक कोड प्रारूप शैली हो।

कोड शैली प्रारूप डिज़ाइन करें और आयात करें कि सभी डेवलपर ग्रहण करें।

यह तब मदद करेगा जब हम merging'संस्करण नियंत्रण' प्रणाली के कोड होंगे।


5
विलय और अलग उपकरण का उल्लेख करने के लिए +1। जब कोडिंग डेवलपर्स के बीच संगत नहीं होती है तो कोड बेस के दो संस्करणों के बीच अंतर जानने की कोशिश करना एक वास्तविक दर्द है।
pgras

1
+1, मैं अत्यधिक संस्करण नियंत्रण प्रणाली का तर्क देता हूं। (लेकिन यह ज्यादातर इंडेंटेशन नियमों के कारण है। नामकरण परंपराओं जैसी चीजों का उतना प्रभाव नहीं होता है)
BiAiB

जब आप किसी कक्षा में मौजूद किसी विधि को जानते हैं, तो आपको यह पता लगाने में मदद मिलती है कि नामकरण परंपराएँ क्या हैं।
दान नीली

1
@ जियोर्जियो वास्तव में डेवलपर्स हैं जो ऐसा करते हैं। अन्य परिवर्तनों के साथ भी मिश्रण करते समय (जैसे, महत्वपूर्ण बग फिक्स)। हमें कोशिश करने के लिए कुछ चीजें भेजी जाती हैं ...
डोनल फेलो

1
@ डॉनल फेलो: आप सही हैं। मैं उस सिद्धांत का पालन करता हूं जो आप प्रत्येक स्रोत फ़ाइल में टाइप करते हैं (1) एक संभावित त्रुटि (2) एक परिवर्तन का परिचय देती है जिससे कोड को बाद में पहचानना मुश्किल हो जाता है। इसलिए मेरी राय में प्रत्येक परिवर्तन यथासंभव छोटा होना चाहिए। लेकिन, हाँ, ऐसे डेवलपर हैं जो बहुत ज्यादा सोचे बिना कोड बदल देते हैं। मुझे आश्चर्य है कि अगर कोड का एक स्वचालित पुन: स्वरूपण समस्या को हल कर सकता है। मैं इसके बजाय कोड स्वामित्व के पक्ष में होगा (उदाहरण के लिए paulgraham.com/head.html पर बिंदु 7 देखें )।
जियोर्जियो

16

आप क्या हासिल करने की कोशिश कर रहे हैं, आप इसे लागू करने के लिए कितने प्रतिशोधी हो रहे हैं (और अपने "नियम" के बारे में विस्तार से बताएंगे), क्या आप इसे अलग-अलग भाषाओं में लिखे कोड पर लागू करने की कोशिश करने जा रहे हैं, क्या आप मौजूदा कोड पर इसे पुनः लागू करने का प्रयास करने जा रहे हैं?

  1. एक आम देखो और महसूस करने के लिए कोड वास्तव में कोड को और अधिक पठनीय बनाने में मदद कर सकता है, लेकिन यह गलत दिखने और महसूस होने पर चीजों को भी बदतर बना सकता है। _hngarian_lpfstr नोटेशन एक प्रमुख उदाहरण है :)
  2. मैंने "कोड मानकों" को टिप्पणी ब्लॉकों में व्हाट्सएप के रिक्त स्थान की संख्या को लागू करते हुए देखा है, विधि के नाम के वर्णानुक्रम क्रम और अन्य बकवास। ऐसा मत करो।
  3. अलग-अलग भाषाओं के अलग-अलग मानक हैं, जिनका उपयोग लोग करते हैं, जो उनके उपयोग में अनुभवी हैं। कुछ भी इन मानकों को जनादेश देते हैं (लगता है कि पायथन, कोबोल, विजुअल स्टूडियो स्वचालित रूप से C ++ शैली ब्रेसिंग सम्मेलनों को लागू करता है, जबकि जावा कन्वेंशन, आदि द्वारा सी शैली का उपयोग करता है)।
  4. इसे बदलने के लिए मौजूदा कोड को कभी न बदलें, आप केवल इस तरह से नई समस्याओं को पेश कर रहे हैं। और इसका मतलब है कि कोड अनुभागों के साथ-साथ संपूर्ण स्रोत फाइलें भी हैं। जब कोई 1000 लाइन की फाइल में किसी एक लाइन को बदलता है तो मौजूदा कोड में सुधार नहीं करता है।
  5. अनुभवी प्रोग्रामर बहुत अधिक उत्पादक हो सकते हैं यदि उन्हें आधे समय तक सोचने की ज़रूरत नहीं है कि वे जो लिख रहे हैं वह स्वचालित अनुमोदन प्रणाली, या समीक्षक के लिए "सही" दिखाई देगा। वे साफ-सुथरे कोड लिखने की आदत में होने जा रहे हैं, क्योंकि यह काम करता है, भले ही उनकी प्राकृतिक शैलियों के बीच छोटे अंतर हों।



इसलिए जब एक विशिष्ट शैली और मानक थोपने के अच्छे कारण हैं, तो ऐसा न करने के अच्छे कारण भी हैं (बहुत सख्ती से)।


1
1-2-3: यह जावा है और कोड प्रारूप सूर्य से एक है; यह केवल स्वरूपण है इसलिए विधियों या चर नामों का आदेश नहीं दे रहा है; 4-5: ठीक है, विचार स्वचालित रूप से सेव (एक्लिप्स सेव एक्शन) पर फॉर्मेट करने का होगा, इसलिए कोई अतिरिक्त काम नहीं (आपको कोडिंग करते समय फॉर्मेट के बारे में सोचने की भी जरूरत नहीं है) लेकिन निश्चित रूप से मौजूदा फाइलों को भी रिफॉर्मेट किया जाएगा ( पहली बार)।
४६

1
KISS के लिए +1। @Stijn रिफॉर्मैट पुराने कोड क्यों? जब आपको इसे संशोधित करने की आवश्यकता हो तो बस इसे हिट करें।
एरिक रेपेन

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

4
मैं आमतौर पर @StijnGeukens से सहमत हूं; न केवल मर्ज कारणों के लिए, बल्कि इसलिए कि कोई भी बड़े पैमाने पर प्रारूपण सफाई को एक दोष उपकरण में परिवर्तन के बाद के इतिहास को कठिन बना देगा। यदि आपके सभी शोर परिवर्तन एक ही स्थान पर हैं, तो आप हमेशा उस बिंदु से पहले शुरू करने के लिए हमेशा दोष लगा सकते हैं और फिर पुराने इतिहास को देखने की आवश्यकता होने पर पहले एक दूसरे दौर को रोक सकते हैं।
दान नीली

2
आप एक और कारण भूल गए Dan: बड़े पैमाने पर स्वरूपण परिवर्तन आसानी से अप्रत्याशित स्थानों में नए बग को पेश कर सकते हैं।
jwenting

11

हां, संगति एक अच्छा विचार है, जिन कारणों से दूसरों ने उल्लेख किया है

मैं बस कुछ बिंदु जोड़ना चाहता था जो कहीं और इस्तेमाल नहीं किए गए हैं:

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

9

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

(हमारे निर्णयों के उदाहरण: 72 अक्षर चौड़ा बहुत छोटा है, लेकिन 120 बेहतर था; स्थैतिक फाइनल में _ALLCAPS का उपयोग करना बेहतर है; एक फ़ंक्शन से एकल-निकास को लागू करना एक अच्छा विचार है।)

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

(संगत स्वरूपण की तुलना में कोड की गंध को हटाना अधिक महत्वपूर्ण है। यह स्वचालित टूल का लाभ है।)

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


5
एकल निकास बिंदु? कुछ शैली सिद्धांत हैं जिनसे मैं वास्तव में सहमत नहीं हूं। (यदि एकाधिक निकास एक समस्या है, तो फ़ंक्शन / विधि पहले स्थान पर बहुत लंबी है ...)
डोनल फैलो

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

6

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

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

व्यक्तिगत प्राथमिकताएं बस और शायद ही कभी उत्पादन में सुधार करती हैं: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

यदि ऐसा होता है, तो इस पर काबू पाएं और कुछ हासिल करें।


6

मैं दृढ़ता से सलाह देता हूं कि मनुष्य कोड फॉर्मेटिंग को लागू करते हैं, और यह कि छोटे उल्लंघन को गंभीरता से अनदेखा या स्पर्श किया जाता है। इसके कारण हैं, संक्षेप में,

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

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

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

मुझे लगता है कि इस उत्तर का विषय है, करो कोड की समीक्षा और संस्कृति से प्रवाह की समीक्षा और समीक्षा प्रक्रिया से बाहर निकलने दो।


टीएक्स, यह देखने का एक बुरा बिंदु नहीं है। लेकिन फिर, यह अतिरिक्त काम है अगर प्रत्येक समीक्षा के दौरान समीक्षक को प्रारूप की भी जांच करनी होगी।
स्टिजेन जुकेंस ने

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

4

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

मैंने कभी भी कोड स्वरूपण नियमों का एक सेट नहीं देखा है जो सभी मामलों में पठनीयता का अनुकूलन करता है। इसी तरह अंग्रेजी में 100% लागू व्याकरण के नियम नहीं हैं: हमारे दिमाग को इस तरह से तार नहीं दिया जाता है। इसलिए दिशानिर्देशों का उपयोग करें, लेकिन डेवलपर्स को उन्हें ओवरराइड करने की स्वतंत्रता दें क्योंकि वे फिट दिखते हैं।

ऐसा कहा जा रहा है, "कोड कॉन्फ्रेंस का पालन करने का एक कठिन नियम जो फ़ाइल / प्रोजेक्ट में पहले से मौजूद है" एक अच्छा है।

लेकिन ध्यान रखें कि स्वरूपण पठनीयता में बहुत कम योगदान देता है, बस यह कि तार्किक रूप से कोड कैसे व्यवस्थित होता है। मैंने बहुत सारे अपठनीय स्पेगेटी कोड w / परिपूर्ण स्वरूपण देखे हैं!


2

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

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

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

तो मैं यहाँ जो बिंदु बना रहा हूँ वह यह है कि अनम्य होने का जवाब नहीं है, लेकिन वाइल्ड वेस्ट में होना भी नहीं है। असली जवाब उस जगह को ढूंढना है जो सबसे अधिक समझ में आता है, जो मेरी राय में सामान की जांच करने वाले स्वचालित उपकरण नहीं है, लेकिन हवा के लिए सम्मेलन को फेंकना नहीं है, या तो।


2

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

मैं ग्रहण से परिचित नहीं हूँ लेकिन एक भयानक विचार की तरह लगता है पर ऑटो प्रारूप। एक डेवलपर को कोडिंग शैली लगाए जाने या न होने की परवाह किए बिना अपने कोड पर पूरा नियंत्रण होना चाहिए। 'सेव' ऑपरेशन को उपयोगकर्ता से स्पष्ट सहमति के बिना एक भी वर्ण नहीं बदलना चाहिए।

यदि आपकी कंपनी सोर्स कोड बेचती है तो कोडिंग स्टाइल अधिक महत्वपूर्ण है लेकिन यदि आप संकलित कोड बेचते हैं तो यह बहुत कम प्रासंगिक है।

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

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

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


2

उन सभी पर शासन करने के लिए एक प्रारूप ... क्या यह वास्तव में इष्टतम है?

यह किसी और की कार चलाने जैसा है ...

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

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

अब तक उल्लिखित सभी लाभों के लिए +1, लेकिन ...

स्वचालित प्रवर्तन लागतों पर विचार किया जाना चाहिए:

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

कभी-कभी इन चीजों पर वर्कअराउंड होते हैं, लेकिन डेवलपर्स के पास अपने दिमाग को लगाने के लिए अधिक महत्वपूर्ण चीजें होती हैं कि कैसे कोड को प्रबंधित करने से स्वचालित फॉर्मेटर को रखा जाए।

प्रारूपण नियम हैं, लेकिन सामान्य ज्ञान को लागू करने के लिए कुछ स्वतंत्रता की अनुमति दें।


2
मैं पूरी तरह से सहमत हूं! ऑटोफ़ॉर्मेटर्स गूंगे हैं।
ukasz विकटोर

1

अच्छे डेवलपर्स रचनात्मक लोग हैं, उन्हें कुछ कलात्मक लाइसेंस देते हैं। "इसे सरल रखें" प्रोग्रामर मंत्र होना चाहिए। मेरे दो नियम हैं:

नियम 1: चर / श्राप देने वाले / वस्तु / प्रक्रिया / जो कुछ भी नाम दें। अस्पष्ट नाम जो आपके कोड में अर्थ और समझ लाते हैं।

नियम 2: अपने कोड की संरचना दिखाने के लिए इंडेंटेशन का उपयोग करें।

बस।


1
क्या आप बता सकते हैं कि ऐसा क्यों है? प्रत्येक डेवलपर के पास कुछ कलात्मक लाइसेंस (जो एक ही परियोजना पर डेवलपर्स के बीच भिन्न होते हैं) को एक बेहतर विचार के लिए बनाते हैं, क्योंकि उन सभी का प्रारूप समान है? क्या कोई समस्या है जो आपके हल करती है कि विकल्प नहीं है? और इसके विपरीत?

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

विचार करें कि क्या मेरे पास ग्रहण में एक कोड फॉर्मेटर है जो एक तरह से सेट है और मैं हमेशा अपने कोड को पुन: स्वरूपित करता हूं ... और आपने एक अलग तरीके से सेट किया है ... और हम उसी कोड को संशोधित करते रहते हैं। क्या इस 'कलात्मक लाइसेंस' के कारण कोई समस्या है?

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

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

0

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


-1

स्टाइल गाइड विभिन्न विश्लेषणात्मक उद्देश्यों के लिए कोड के आसान प्रोग्रामेटिक पार्सिंग को भी सक्षम करते हैं।

Google ने इसके बारे में एक पेपर प्रकाशित किया है जिसका नाम है "सर्चिंग फॉर बिल्ड डेट: एक्सपर्ट्स मैनेजिंग टेक्निकल डेट एट गूगल"


-1

यह भाषाएँ नहीं कोड हैं। हम मनुष्यों के पास 6000 से अधिक भाषाएँ हैं इसलिए हम उनका अनुवाद करते हैं। इसलिए यदि आप चाहते हैं कि आपके "कोड" संवाद करने के लिए आपको अपना समायोजन करना होगा। आप देखते हैं कि हमारे उपयोगकर्ताओं को हमारे डेटा प्रारूप बदलने होंगे ताकि हम अपना डेटा ढीला न करें।


-2

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

अवधारणा के साथ मेरे सबसे बड़े मुद्दे हैं

  1. अगर मैं एक प्रारूप में कोड लिख रहा हूं और यह स्वचालित रूप से सुधारित है, तो वास्तव में उस प्रारूप को सीखने के लिए क्या प्रोत्साहन है?
  2. उस पिछले बिंदु के बाद, यदि आप प्रारूप नहीं सीखते हैं, तो ऑटोफ़ॉर्मेटिंग (कोड को अधिक आसानी से पढ़ने और संशोधित करने के लिए) का पूरा बिंदु पूरी तरह से खो जाता है। आपको अभी भी फॉर्मेटिंग का पता लगाने के लिए समय निकालना होगा क्योंकि आप कोड पढ़ रहे हैं क्योंकि आपने उस प्रारूप को नहीं सीखा है
  3. मुझे लगता है कि एक दिन एक कक्षा लिखने, इसे बंद करने, और अगले दिन वापस लौटने के लिए यह पूरी तरह से अलग है, यह एक भयावह अनुभव होगा। इसका मतलब है कि न केवल दूसरों को आपका कोड सीखना है, आपको अपना कोड सीखना होगा।
  4. यह आलसी कोडिंग को भी प्रोत्साहित कर सकता है। प्रारूप सीखने के लिए देव को धक्का देने के बजाय, वे सूर्य के नीचे किसी भी प्रारूप में लिख सकते हैं और यह स्वचालित रूप से जिस तरह से हर कोई इसे चाहता है, उसे देखेगा। यह # 2 पर वापस जाता है जहां आप शैली नहीं सीखते हैं और फिर भी इसे सही ढंग से नहीं पढ़ सकते हैं।

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

मूल रूप से: कंपनी की शैली सीखने के लिए कर्मचारी पर जिम्मेदारी डालें, उनके कोड को ऐसा कुछ होने के लिए मजबूर न करें जो यह नहीं है।


+1: अच्छे बिंदु, हालांकि मुझे यकीन नहीं है कि वे स्वचालित सुधार के पक्ष में कारणों से आगे निकल गए हैं। डाउनवोट (ओं) को क्यों?
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.