क्या एक ओपन सोर्स प्रोजेक्ट पर कोडिंग शैली में बदलाव करना ठीक है जो सर्वोत्तम प्रथाओं का पालन नहीं करता है?

Question

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

अब, इन अपराधों के अधिकांश, एकल उद्धरण (जब प्रक्षेप नहीं) के बजाय दोहरे उद्धरण चिह्न का उपयोग कर का पालन नहीं कर स्तर नियम के अनुसार 2 रिक्त स्थान, 80 चरित्र लाइन की लंबाई नियम से अधिक, या का उपयोग शामिल है {और }बहु लाइन ब्लॉकों के लिए।

[]] रूबी स्टाइल गाइड सर्वोत्तम प्रथाओं की सिफारिश करता है ताकि वास्तविक दुनिया रूबी प्रोग्रामर कोड लिख सकें जिसे अन्य वास्तविक दुनिया रूबी प्रोग्रामर द्वारा बनाए रखा जा सके। ~ स्रोत: रूबी स्टाइल गाइड

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

लोग निरंतरता की सराहना करते हैं इसलिए इस तरह के बदलाव करना रूबी समुदाय के लिए सामान्य तौर पर सही काम करना है?

[रूबी स्टाइल गाइड के लेखक) अभी तक के सभी नियमों के साथ नहीं आए - वे ज्यादातर एक पेशेवर सॉफ्टवेयर इंजीनियर, प्रतिक्रिया और रूबी समुदाय के सदस्यों और विभिन्न सुझावों के रूप में मेरे व्यापक कैरियर पर आधारित हैं। "प्रोग्रामिंग रूबी 1.9" और "द रूबी प्रोग्रामिंग लैंग्वेज" जैसे अत्यधिक माना जाने वाला रूबी प्रोग्रामिंग संसाधन। ~ स्रोत: रूबी स्टाइल गाइड

क्या समुदाय कोडिंग शैली सम्मेलनों और सर्वोत्तम प्रथाओं का पालन नहीं करना मूल रूप से बुरी प्रथाओं को प्रोत्साहित करना है?

Comments

इसी तरह का प्रश्न: क्या मुझे कोड जलवायु से एक एफ क्लास को रिफलेक्टर करना चाहिए? , लेकिन वास्तुकला पर अधिक ध्यान देने के साथ।

— आमोन

thecodelesscode.com/case/123

— आर्य

इन शैली मुद्दों में से कई, बहुत मामूली tbh ध्वनि।

— JL235

देखें: en.wiktionary.org/wiki/bikeshging

— kdgregory

@MathewFoscarini नहीं, वे क्या पूछ रहे हैं, "अगर मैं एक रडार बंदूक खरीदता हूं, तो क्या मैं यह तय कर सकता हूं कि स्थानीय ड्राइविंग कानून क्या हैं?"

— जॉन हैना

Answer 1

रखवाले से पूछो।

कोडिंग शैली एक बहुत ही व्यक्तिपरक चर्चा है, और 80 वर्णों की अधिकतम लाइन लंबाई जैसे नियम काफी व्यक्तिपरक हैं - जबकि सामान्य समझौता यह होना चाहिए कि छोटी लाइनें पढ़ने के लिए बेहतर हैं, 80 आज के स्क्रीन आकार और आईडीई के साथ कुछ के लिए बहुत अधिक प्रतिबंधात्मक हो सकती हैं।

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

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

Comments

कई अनुचर भी बड़े बदलावों को पसंद नहीं करते हैं जो कड़ाई से आवश्यक नहीं हैं क्योंकि वे मर्ज संघर्षों को पैदा करते हैं जो कड़ाई से आवश्यक भी नहीं हैं।

— Jan Hudec

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

— साथियों

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

— पीटर कॉफ़लर

मर्ज संघर्ष पर +1। मैंने सिर्फ एक कोडिंग स्टाइल रीवर्क को स्वीकार किया है और मेरी इच्छा है कि मैं ऐसा न करूं, क्योंकि यह अन्य लोगों के पीआर के साथ मर्ज संघर्ष का कारण है। इसे हल करना आसान है, लेकिन मैंने इसे टुकड़े-टुकड़े कर दिया है

— डेन्थ

यह आईडीई है जो प्रतिबंधक है अगर यह दो अलग-अलग फ़ाइलों को साइड-बाय-साइड दिखाने की अनुमति नहीं देता है, न कि शॉर्ट-लाइन कोड की गलती।

— unperson325680

Answer 2

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

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

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

Comments

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

— क्रिस कील

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

— मील्स राउत

Answer 3

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

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

क्या उन्हें सिर्फ नजरअंदाज किया जाना चाहिए? नहीं, जो देखने की जरूरत है उसका सामान्य विचार प्राप्त करने के लिए उपकरणों का उपयोग करने के लिए योग्यता है, लेकिन अब और नहीं।

यह आश्चर्य है कि कितनी बार जूनियर प्रकार तथ्य के लिए राय को भ्रमित करते हैं।

Comments

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

— Jan Hudec

Answer 4

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

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

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

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

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

ब्रांचिंग, मर्जिंग और फिक्सिंग एकमात्र समाधान लगता है।

Comments

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

— रफ

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

— रिएक्टगुलर

क्या मैं मतलब फिक्सिंग अपराधों एक वैध कारण हो द्वारा भविष्य योगदानकर्ताओं को लाभ होता था के लिए इस तरह के सुधारों के साथ एक पीआर विलय? अनुरक्षक को ऐसे पीआर का विलय क्यों करना चाहिए? शायद मेरे सवाल का शब्दांकन थोड़ा हट कर था।

— रफ

@RafalChmiel एक कारण के रूप में आप जो कुछ भी कहते हैं वह सिर्फ आपकी राय है। यदि यह आक्रामक कोड है जो बैल की तरह दिखता है, तो एक मुद्दे में अपने डर को लिखें। यदि लेखक इस तरह के खिंचाव के खिलाफ बचाव करता है, तो अपने आँसू एक ऊतक से पोंछ लें।

— रिएक्टगुलर

Answer 5

रूबोकॉप साइट से ही लिया गया (जोर मेरा):

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

कृपया समझे:

कोई आधिकारिक रूबी स्टाइल गाइड नहीं है

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

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

क्या आप सिर्फ स्टाइल गाइड का सुझाव नहीं दे सकते?

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

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

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

Answer 6

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

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

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

आपको कुछ चीजों के बारे में पता होना चाहिए, हालांकि:

• कुछ लोग स्टाइल को लेकर धार्मिक होते हैं। अगर यह स्पष्ट हो जाता है कि वे हिलना नहीं चाहते हैं, तो परेशान न हों।

• यह एक बड़ा बिकेशेड मुद्दा है। हर व्यक्ति और उनके भाई की इन बातों के बारे में एक राय है। इस तरह के एक पुल अनुरोध को मर्ज करना इस वजह से मुश्किल हो सकता है।

• इस तरह के पुल अनुरोध को मर्ज करना भी कठिन हो सकता है क्योंकि यह बहुत तेज़ी से मर्ज संघर्ष प्राप्त करेगा; मूल रूप से जब भी कोडबेस के किसी भी हिस्से को आपने संशोधित किया, भले ही इसके तुच्छ तरीकों से।

मैं "पहले पूछो" दृष्टिकोण के साथ रहना होगा। यदि वे इसके लिए खुले हैं, और आप पुल के अनुरोध को पूरा करने के लिए तैयार रहना चाहते हैं, तो इसके लिए जाएं।

Answer 7

मैं एक अच्छा स्टाइल गाइड होने पर बड़ा हुआ करता था, लेकिन रूबी के मामलों को देखते हुए, "मैं आगे बढ़ा हूं"।

मूल रूप से मैं जो काम कर रहा हूं उसके साथ रहता हूं और अन्यथा मैंने कई नौकरियों से सीखे सामान्य सम्मेलनों का पालन किया।

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

प्रत्येक शैली के उदाहरण (मेरी राय में):

रूबी के लिए विश्वविद्यालय द्वारा स्वीकृत:

• रिक्त स्थान टैब नहीं
• दो अंतरिक्ष संकेत
• method_names_use_underscores
• लगातार कैप्स के साथ शुरू होता है।

सामान्यतः स्वीकार्य:

• यदि आवश्यक न हो तो कोष्ठक का प्रयोग न करें
• { }एक लाइन ब्लॉक के लिए और do endमल्टी-लाइन ब्लॉक के लिए उपयोग करें ।
• CONSTANTS_ARE_IN_ALL_CAPS
• यदि अभिव्यक्ति 1 पंक्ति पर फिट बैठती है, तो पूर्वानुमान कथन ( cond ? true : false) का प्रयोग करें if then।

व्यक्तिगत वरीयताओं:

• 120 वर्ण रेखाओं की रेखा लंबाई
• केस whenस्टेटमेंट केस केस 2 से इंडेंट किए जाते हैं।
• सिंगल कोट्स का उपयोग करें जब तक कि डबल की आवश्यकता न हो।

कोई समझौता नहीं:

• केस स्टेटमेंट
• रेखा लंबाई

सर्वोत्तम प्रथाएं:

• छोटी विधियाँ, यदि संभव हो तो <= 5 पंक्तियाँ।
• छोटी कक्षाएं, यदि संभव हो तो <= 100 लाइनें।
• स्थिरांक से बचें
• कोड में परीक्षण हैं

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

Answer 8

यद्यपि वे छोटे और आसानी से तय होते हैं, क्या आपको लगता है कि अपराधों को ठीक करने और पुल अनुरोध करने से एक ओपन सोर्स प्रोजेक्ट की कोडिंग शैली को बदलना ठीक है?

संक्षेप में, नहीं!

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

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

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

Answer 9

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

Answer 10

मेरे पास मामूली रूप से सफल .NET प्रोजेक्ट्स की एक जोड़ी है, और मेरे पास उन लोगों के पीआर के कुछ जोड़े हैं जो ReSharper और StyleCop के साथ कोड के माध्यम से चले गए हैं और सामान का "निश्चित" निर्धारित किया है। मैं उन पीआर को स्वीकार नहीं करता, कुछ कारणों से:

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

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

Answer 11

आपको यह पता लगाने की ज़रूरत है कि क्या अनुचर इन कोडिंग शैली के उल्लंघन को एक दोष मानते हैं, या यदि परियोजना में कोडिंग शैली के लिए एक अलग मानक है।

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

Comments

यह एक और जवाब है कि इस एक से पहले कई घंटे पोस्ट किया गया था पर कुछ भी मूल्यवान की पेशकश करने के लिए प्रतीत नहीं होता है

— gnat