अनुभव से बोले ...
जब मैंने पहली ओपन सोर्स परियोजना में योगदान दिया था, तब मैं सभी पेशाब और सिरका से भरा हुआ था जब मैंने पहली बार भी शुरुआत की थी।
मैंने जो तुरंत किया वह स्रोत फ़ाइलों के एक समूह के माध्यम से जाना था और अपनी व्यक्तिगत प्राथमिकताओं में चीजों को स्टाइल करना शुरू कर दिया, एक बड़े पैमाने पर पैच बनाया, और इसे प्रस्तुत किया।
यदि आप किसी ऐसे व्यक्ति के साथ काम कर रहे हैं जो 'अच्छा' है (जैसे मैं था) तो वह तुरंत पैच को अस्वीकार कर देगा। ज्यादातर इसलिए, क्योंकि जब आप एक ओपन सोर्स प्रोजेक्ट में योगदान करते हैं, तो आपसे यह अपेक्षा की जाती है कि आप अपने फ़िक्सेस को एक साइज़ के पते के काटने वाले हिस्से में तोड़ दें। 'हटाए गए सभी गोटो' परमाणु प्रतिबद्धता का एक अच्छा उदाहरण नहीं है। यहां तक कि अगर आप इसे छोटे में तोड़ते हैं, तो पहले से ही अच्छी तरह से प्रलेखित किया जाता है, फिर भी इसे अस्वीकार किया जा सकता है।
इसका कारण यह है, क्योंकि समय के साथ कई लोगों द्वारा (विभिन्न शैलियों के साथ) कोड पर काम किया जाता है, एक विकासकर्ता की शैली के अनुरूप पूरे पुस्तकालय में परिवर्तनों को स्वीकार करना वास्तव में संभव नहीं है। अगर शैली की खातिर बदलती शैली संभव थी, तो हर ओपन सोर्स प्रोजेक्ट कभी आगे नहीं बढ़ेगा, क्योंकि कोड को लगातार विभिन्न देव शैलियों के अनुरूप बनाया जाएगा।
कोड को फिर से भरना और कार्यक्षमता जोड़ना (या हटाए गए क्रेफ़्ट को हटाना) आमतौर पर 'सफाई' कोड पर पूर्वता लेता है।
एक ओपन सोर्स प्रोजेक्ट पर काम करने का सबसे कठिन और सबसे फायदेमंद हिस्सा है, आपसे पूछा जाएगा कि आप सबमिट करने के लिए बदलाव करने का प्रस्ताव क्यों दे रहे हैं। यदि आप एक अच्छा कारण दे सकते हैं तो बेहतर मौका है कि आपका पैच जमा हो जाएगा।
मेरी सलाह है कि आप पहले क्या करने की कोशिश कर रहे हैं, इसका स्वाद देने के लिए एक स्रोत फ़ाइल पर इन परिवर्तनों में से कुछ करें। यदि परिवर्तन अच्छी तरह से उचित और स्वीकार किए जाते हैं, तो पूछें कि क्या अधिक परिवर्तन जैसे कि यह परियोजना की गुणवत्ता में सुधार करेगा। इस तरह आप भविष्य में अपने पैच खारिज कर दिया जाता है, तो कुछ भी नहीं के लिए बहुत प्रयास बर्बाद नहीं होगा।
ओपन सोर्स डेवलप करना कोड लिखने से ज्यादा है। आप एक विश्वास संबंध बनाने के लिए काम कर रहे हैं क्योंकि द्वारपाल (धक्का पहुंच को नियंत्रित करने वाले देव) परियोजना की अखंडता की रक्षा के लिए क्या करेंगे । जैसा कि आप अधिक पैच जमा करते हैं, गेटकीपर को आपकी शैली के लिए बेहतर महसूस होगा और आपको अपने परिवर्तनों को अधिक से अधिक औचित्य देने की आवश्यकता नहीं होगी।
यह एक प्रक्रिया है जिसमें समय लगता है लेकिन यह बहुत फायदेमंद है। न केवल आप को देखने में सक्षम होने से बहुत कुछ सीखना होगा, और किसी को elses 'कोड को क्रिटिक करना, लेकिन आप अपनी शैली पर आलोचना करेंगे ।
इससे पहले कि आप बहुत समय बर्बाद करते हैं, 'दूसरे की कोडिंग शैली की त्रुटियों को ठीक करने की कोशिश कर रहे हैं'
क्या वे परिवर्तन हैं जो आप परियोजना में मूल्य जोड़ने के आधार पर प्रस्तावित कर रहे हैं या वे आपके स्वयं के आंतरिक शैलीगत धर्म पर आधारित हैं।
वहाँ एक है बहुत स्टैक ओवरफ़्लो (और संबंधित स्टैक एक्सचेंज साइटों) पर धर्म के। मेरा मतलब बहुत है । लोग शैली के बारे में अंतहीन रूप से सोचते हैं और बात करते हैं, जैसे कि आप इसके बारे में जितना अधिक बात करते हैं, आप 'सही, आदर्श, अविनाशी, अचूक' कोडिंग शैली के करीब पहुंचते हैं। मैं इसके बारे में बहुत अधिक बात करता हूं क्योंकि यह मजेदार है।
ओपन सोर्स की दुनिया में, शैली इतनी महत्वपूर्ण नहीं है। समारोह है ।
नोट: इस सलाह के सभी मानते हैं कि आपका द्वारपाल एक उचित और प्रतिभाशाली प्रोग्रामर है। यदि वह है, तो अपने आप को भाग्यशाली मानें कि आप किसी के साथ अटक नहीं गए हैं b @ & # es जिसका एकमात्र चिंता उनके 'बच्चे' की रक्षा करना है। वे करते हैं जंगली में बाहर मौजूद हैं, इसलिए यदि आप एक मुठभेड़ है आश्चर्यचकित नहीं किया।
gotoजरूरी नहीं कि गड़बड़ हो। ऐसे कई मामले हैं जब इसका उपयोग पूरी तरह से उचित है।