क्या यह समय-समय पर एक फॉर्मोसॉर पर कोड फॉर्मेटर्स चलाने के लिए एक बुरा विचार होगा?


68

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

अधिकांश प्रोजेक्ट जो ऑटोफ़ॉर्मेटर्स का उपयोग करते हैं, उन्हें एक गिट हुक में डालते हैं, लेकिन हर कुछ घंटों में स्वचालित रूप से ऐसा करने से प्रत्येक देवता के लिए गिट हुक स्थापित करने का बोझ दूर हो जाएगा।

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


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

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

13
मेरे पास एक ऑटोफ़ॉर्मर के साथ समस्याएँ हैं जो ठीक से अपडेट नहीं हो रही हैं और मेरे कोड को तोड़ रही हैं। मन में कुछ रखने के लिए।
isaacg

22
यदि यह आपके लिए महत्वपूर्ण है, तो आप कोड को सही ढंग से स्वरूपित नहीं करने पर निर्माण को विफल कर सकते हैं। यह थोड़ा कठोर है लेकिन एक उचित सहकर्मी समीक्षा कमोबेश यही काम करेगी।
एर्नो

18
यह एक उत्कृष्ट विचार है यदि आपका लक्ष्य लोगों को आपसे घृणा करना है। यह बहुत कम प्राप्त करता है, लेकिन निश्चित रूप से अप्रत्याशित समस्याओं का कारण होगा।
टोनीके

जवाबों:


130

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

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


50
इसके अलावा यह थोड़े VCS को तोड़ता है। आप यह नहीं जान पाएंगे कि किसने दोष के साथ आसानी से एक पंक्ति लिखी है, और यदि कोई संघर्ष है, तो आपका वीसीएस यह नहीं जान पाएगा कि उपकरण के परिवर्तन सिर्फ शैली के लिए हैं और इसे हर बार छोड़ दिया जाना चाहिए।
पियरे.ससौलस

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

20
@JeffO git blameसिर्फ यह पता लगाने के लिए नहीं है कि किसकी गलती बग है, यह प्रतिबद्ध है जब कुछ जोड़ा / हटा दिया गया था, जो कई कारणों से उपयोगी हो सकता है।
प्रोक्यू 2222

2
"हमारे पास एक नियम है जो गुणों और विधियों को वर्णानुक्रम में आदेश देता है" लड़का, यह भयानक लगता है! आपको फ़ाइल के चारों ओर लगातार उम्मीद करनी होगी
अलेक्जेंडर

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

72

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

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


7
"हाथ में एक फॉर्मैटर जहां आप 100% सुनिश्चित हैं कि यह कुछ भी नहीं तोड़ता है" - जब आपने कभी कोड के एक टुकड़े में भाग लिया है जो आप थे, ईमानदारी से, 100% यकीन है कि कभी नहीं टूटेगा?
ज़िबोबोज़

2
@Zibbobz: कोड को एडिट करने और लिंक करने के लिए हम जो भी टूल्स का इस्तेमाल कर रहे हैं, उनमें से कोई भी और VCS भी, बग्स हो सकते हैं, फिर भी जो हमें वर्किंग प्रोग्राम्स डेवलप करने की कोशिश में नहीं रोकता;; लेकिन मेरे एडिट को देखते हैं।
डॉक ब्राउन

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

@Zibbobz काफी बार! ध्यान दें कि 100% किसी चीज़ के बारे में सुनिश्चित होने का मतलब यह नहीं है कि यह सच होने की 100% संभावना है।
इबिबिस

@ आईमाइबिस: आपको याद हो सकता है कि कुछ दिनों पहले मेरे उत्तर से हटाए गए वाक्य को संदर्भित टिप्पणी।
डॉक ब्राउन

37

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


10
मुझे लगता है कि अगर वह एक रिपॉजिटरी में एक बॉट की चीजों की जांच कर रहा है, तो वीसीएस दिया गया है?
StarWeaver

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

14
यह है ... मैं जाने के लिए बुरे सपने अब जा रहा हूँ>।>
StarWeaver

7
@StarWeaver आपको क्यों लगता है कि मैं 14 साल बाद भी उस माहौल को याद करता हूं?)
jwenting

28

मुझे विश्वास है कि यह एक अच्छा विचार है (स्वचालित रूप से कोड फ़ॉर्मेटर्स चलाने के लिए), लेकिन यह सिर्फ मेरी राय है।

मैं समय-समय पर उन्हें नहीं चलाऊंगा, लेकिन यदि संभव हो तो संस्करण नियंत्रण शुरू होने से पहले।

गिट के साथ , एक पूर्व-प्रतिबद्ध हुक करना जो उपयोगी होगा। कुछ Makefile के साथ निर्मित कई C या C ++ प्रोजेक्ट्स में , मैं कुछ indentलक्ष्य जोड़ रहा हूं (जो उपयुक्त कोड फॉर्मेटर्स जैसे indentया astyle) चलाते हैं और योगदानकर्ताओं से make indentनियमित रूप से चलने की अपेक्षा करते हैं । BTW, आप makeयह सुनिश्चित करने के लिए कुछ नियम जोड़ सकते हैं कि गिट हुक स्थापित किए गए हैं (या उन्हें स्थापित करने के लिए)।

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

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

BTW, विभिन्न समुदायों और विभिन्न प्रोग्रामिंग भाषाओं में कोड स्वरूपण पर अलग-अलग विचार हैं। उदाहरण के लिए, गो में केवल एक कोड स्वरूपण शैली है, लेकिन C या C ++ उनमें से बहुत कुछ है।


सही, लेकिन इसका मतलब है कि प्रत्येक डेवलपर को कमिट हुक स्थापित करने की आवश्यकता है।
bigblind

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

ठीक है, इसलिए आप कह रहे हैं कि गिट हुक लगाने का सामाजिक नियम, एक स्वचालित प्रणाली से बेहतर है जो इसे करता है? (गंभीर सवाल, एक बयानबाजी के रूप में नहीं, टोन इंटरनेट पर व्यक्त करने के लिए कठिन है :))
bigblind

15
हां, मैं ऐसा कह रहा हूं।
बेसिल स्टारीनेवविच

17

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

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

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


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

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

@ 18446744073709551615 मैं स्वचालित स्वरूपण का सुझाव नहीं दे रहा हूँ, मैं स्वत: जाँच का सुझाव दे रहा हूँ । आपके नियम उन चीजों की अनुमति दे सकते हैं।
कैप्टन मैन

16

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

@ BasileStarynkevitch की अनुशंसा के अनुसार एक ही नस में, हम कोड शैली के बारे में "सलाहकार ईमेल" भेजने के लिए git सर्वर-साइड पोस्ट-प्राप्त हुक का उपयोग करते हैं।

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

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

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

जैसा कि @DocBrown कहता है, एक अन्य विकल्प आपके IDE के भीतर कोड शैली लागू करना है। कई सामान्य शैली की त्रुटियों को ठीक करने के लिए हम Visual Studio के साथ CodeMaid का उपयोग करते हैं। यह कोड फ़ाइलों को सहेजने पर चलेगा, जिसका अर्थ है कि खराब-शैली कोड को कभी भी रेपो में नहीं बनाना चाहिए ... सिद्धांत :-)।


मैंने इसे एक को उकेरा, क्योंकि यह सीधे दोनों पक्षों (बिल्ड को तोड़ने से बेहतर कोड + सुरक्षा की इच्छा) को संबोधित करता है। बाद कोड बेस वास्तव में अच्छी हालत में है, हालांकि, मैं विचार करूँगा "बुरा विचार" भविष्य में परिवर्तन स्वचालित के लिए कुछ हद तक मजबूत शब्दों किया जाना है।
डॉनजेडियो

10

हां, मुझे लगता है कि यह एक बुरा विचार है। मुझे गलत मत समझो, ऐसा करने का कारण बहुत अच्छा लगता है, लेकिन परिणाम अभी भी भयानक हो सकता है।

ट्रैक की गई शाखा को खींचते समय आपके पास संघर्ष होगा, कम से कम मुझे डर है कि मामला होगा, मैं हालांकि गलत हो सकता हूं।

मैं काम पर अभी इसका परीक्षण नहीं करना चाहता, लेकिन आपको इसे स्वयं आज़माना चाहिए।

वास्तव में आप हाल ही में एक कमिटमेंट देख सकते हैं। एक नई शाखा बनाएं, कुछ पेटीएम, चेरी पिक या मर्ज करें जिसमें कोई ऑटोकॉमिट न हो।

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

इसके बजाय आप संभावित रूप से इसे रात के निर्माण या साप्ताहिक निर्माण में डाल सकते हैं।

लेकिन एक रात भी एक बुरा विचार हो सकता है।

आप या तो इसे साप्ताहिक रूप से चला सकते हैं, जब आपको यकीन है कि कोई मर्ज टकराव नहीं होगा क्योंकि सब कुछ सोमवार को समाप्त हो गया है।

अन्यथा इसे वर्ष में 1-2 बार छुट्टियों के मौसम में चलाएं, जब मर्ज का टकराव नहीं होगा।

लेकिन समाधान कोड शैली के लिए आपकी प्राथमिकता पर निर्भर हो सकता है।

मुझे लगता है कि सेटअप स्क्रिप्ट बनाना जो स्वचालित रूप से गिट रिपॉजिटरी बनाता है और सेट करता है कि प्रोजेक्ट के लिए हुक बेहतर होगा।

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


7

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


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

7

यह एक भयानक विचार है।

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

यदि आप नियमित रूप से ऐसा करना चाहते हैं, तो यह बहुत ही भयानक है।

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

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


4

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


यह वही है, जो मर्क्यूरियल का उपयोग करते हुए, उदाहरण के लिए, करता है। किसी ऐसी चीज को धक्का देना, जिसके तहत अनियंत्रित नहीं go fmtहै, स्वचालित रूप से अस्वीकार कर दिया जाता है।
जोर्ग डब्ल्यू मित्तग

1

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


1

यह विचार कुछ अन्य उत्तरों के समान है, लेकिन मैं अपने सुझावों पर टिप्पणी नहीं कर सकता।

एक विकल्प यह है कि प्रतिबद्ध कार्य के लिए उपनाम (या हुक, या जो कुछ भी) निर्धारित किया जाए, जो प्रतिबद्ध होने से पहले कोड-टू-टू-प्रतिबद्ध कोड पर रन करता है।

इसके 2 (या अधिक) परिणाम हो सकते हैं:

1) उपयोगकर्ता को प्रस्तावित परिवर्तनों को दिखाएं और परिवर्तनों को लागू करने और प्रतिबद्ध करने के लिए उनकी स्वीकृति के लिए पूछें।

2) प्रस्तावित परिवर्तनों को अनदेखा करें और मूल कोड को प्रतिबद्ध करें।

आप इन विकल्पों में और अधिक लचीलापन भी जोड़ सकते हैं, जैसे कि विकल्प 1 में प्रस्तावित परिवर्तनों को संपादित करने की क्षमता। एक अन्य विचार (सिस्टम इन कोडिंग मानकों को कितना कठिन बनाना चाहता है) पर निर्भर करता है कि क्या सिस्टम आपको किसी प्रकार की रिपोर्ट भेजता है जब विकल्प 2 का चयन किया गया है।

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


0

मैं इसे रिपॉजिटरी पर नहीं करूंगा, लेकिन अगर टूल इसे सपोर्ट करता है तो मैं इसे सेव पर करूंगा। ग्रहण एक है और इसके अलावा मैं कोड सफाई भी करूंगा जिसमें छँटाई भी शामिल है।

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

एक अतिरिक्त बोनस मर्ज को काफी सरल बनाया जाएगा क्योंकि चीजें इधर-उधर नहीं होंगी।

कोड समीक्षाएँ किसी भी गलत लोगों को रोकेंगी।

एक और जगह मैं यह करूँगा यह निर्माण का हिस्सा है। मेरे मामले में मेरे पास ऐसा है कि मावेन बिल्ड एक्सएमएल को सुधार देगा और पोम फाइलों को साफ करेगा और कोड को सुधार देगा।

इस तरह से जब डेवलपर्स इसे आगे बढ़ाने के लिए तैयार होंगे तो यह सब उनके पुल अनुरोध के लिए साफ हो जाएगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.