हाल ही में, मैं कई परियोजनाओं और विकास के वातावरण के बीच स्विच कर रहा हूं। प्रत्येक में स्टाइल कोडिंग के लिए उम्मीदें अलग हैं।
अब, मेरा प्रश्न तीन भाग है, पहला, जिज्ञासा का:
जवाबों:
№1। # आपने अपनी कोडिंग शैली को कैसे परिभाषित किया और पाया?
कोड नमूनों के माध्यम से पहले पुस्तकों में, फिर MSDN ग्रंथों और लेखों में, फिर ब्लॉगों और अन्य वेब साइटों पर।
№2। आप इसे कैसे बढ़ाते और सुधारते रहते हैं?
मैं अपनी नज़र उन सभी सुझावों पर रखता हूँ जो लोग करते हैं। मैं उन्हें आज़माता हूं, अगर वे मेरे लिए काम करते हैं, तो वे चिपक जाते हैं। मैं भी समय-समय पर प्रयोग करता हूं, जो चीजें बेहतर होती हैं, वह मेरे साथ रहती है।
№3। आप इसे कैसे बनाए रखेंगे? (मानसिक नोट्स से, एक दस्तावेज रखते हुए, स्टाइलकॉप जैसे उपकरण का उपयोग करके)
मुझे अपनी शैली याद है और इसे हर जगह स्वचालित रूप से लागू किया जाता है।
नोट 1. करंट रहने के लिए आंख खुली रखना और कान तेज रखना बेहद जरूरी है। वर्षों पहले मुझे पता चला कि हंगरी की धारणा दूसरों से थी इसलिए मैंने इसका अनुसरण किया। जब समुदाय को एहसास हुआ कि यह इतना महान नहीं है तो मैं हर किसी के साथ बदल गया।
नोट 2. यह अक्सर महत्वपूर्ण नहीं होता है कि आप किस विशेष शैली के तत्व को अपनाते हैं, बल्कि यह कि आप अपनी शैली को अपने कोड के अनुरूप बनाए रखते हैं। एक टीम के लिए भी यही बात लागू होती है। कुछ स्टाइल चुनें लेकिन फिर उससे चिपके रहें।
नोट 3. विभिन्न भाषाओं के लिए कोडिंग शैली भिन्न हो सकती है। C ++ एक शैली का हकदार है, जावा दूसरा। HTML और CSS में उनकी विशेषताओं के लिए फिर से कुछ अलग शैली की आवश्यकता होती है।
नोट 4. जो भी शैली आप चुनते हैं, समझें और स्वीकार करें कि यह 100% काम नहीं करेगा। कभी-कभी आपके पास कुछ कोड होते हैं जिनके लिए एक अलग शैली की आवश्यकता होती है, या तो मल्टीलाइन विभाजित करें, अलग संरेखण या जो कुछ भी उस विशेष कोड टुकड़े को अधिक पठनीय रखने के लिए। हर जगह अपनी शैली को धक्का न दें, कोड पठनीयता पर ध्यान केंद्रित करें। यदि यह स्पष्ट है, तो शैली इस विशेष स्थान पर काम नहीं करती है, एक अपवाद बनाएं।
नोट 5. एक धर्म के लिए एक कोड शैली का पालन न करें। कोड शैली को लागू करने वाले उपकरण अच्छे हैं, लेकिन कभी-कभी आपको पागल बना सकते हैं। उदाहरण के लिए मैंने Visual Studio के स्वचालित कोड स्वरूपण को अक्षम कर दिया क्योंकि यह मुझे पागल कर रहा था। यदि कोई उपकरण एक बाधा बन जाता है, तो बस एक अपवाद जोड़ें और चिंता न करें कि आपका कोड 100% अनुरूप नहीं है। यह वास्तव में महत्वपूर्ण नहीं है और पूर्णता प्राप्त करने योग्य नहीं है।
मुझे नहीं लगता कि कोई समय था जहां मैंने कहा: "ठीक है यह मेरी शैली है"। विशिष्ट वातावरण या भाषा पर ध्यान केंद्रित करें। आपकी शैली को एक निश्चित समस्या का सामना करने के तरीके को प्रतिबिंबित करना चाहिए।
मैंने एक बंद स्रोत गेम के साथ एक टीम में काम किया जिसे मैं प्यार करता था और मुख्य डेवलपर ने मुझे सलाह दी, और मैंने उससे भी पूछने के बाद अपने कौशल को सुधारने में मेरी मदद की।
उन्होंने सुझाव दिया, और मैंने Zend फ्रेमवर्क के कोडिंग स्टाइल (http://framework.zend.com/manual/en/coding-standard.html) को अपनाया।
मैंने विभिन्न शैलियों की विशेषताओं को अपनाते हुए समाप्त किया - जिसमें MSDN पर प्रतिबिंबित शैलियाँ भी शामिल हैं। मैं फिर वीएस में टेम्प्लेट सेट करता हूं जो मेरे #region/#endregionब्लॉक और कुछ और प्रदान करता है जो बेहतर है।
मैं अन्य शैलियों का अध्ययन करना जारी रखता हूं जो मुझे अनुसंधान और पढ़ने के माध्यम से मिलते हैं। अगर मुझे लगता है कि कुछ ऐसा है जो बाहर खड़ा है और पठनीयता, रखरखाव या संगठन में अपनी शैली में सुधार कर सकता है, तो मैं इसे आज़माता हूं। यदि एक नई शैली समायोजन क्रम में है, तो मैं वीएस में टेम्पलेट्स को अपडेट करूंगा या मानसिक नोट्स बनाऊंगा।
जब अकेले कोडिंग, मैं संक्षिप्तता के लिए लक्ष्य; स्पार्टन प्रोग्रामिंग पूरी हो सकती है , बल्लेबाज़ पागलपन ... लेकिन यह शायद मेरे पंथ के सबसे करीबी परिचित चीज़ है।
जब दूसरों के साथ कोडिंग, विशेष रूप से रखरखाव कोडिंग, मेरा लक्ष्य गिरगिट होना है - मेरे बदलावों में सुधार होना चाहिए कि वे जगह से बाहर देखे बिना क्या संशोधित करते हैं।
आपने अपनी कोडिंग शैली को कैसे परिभाषित किया और पाया?
सादगी और पठनीयता पर ध्यान केंद्रित करके (पठनीयता! == समझने की क्षमता , संयमी प्रोग्रामिंग देखें )
आप इसे कैसे बढ़ाते और सुधारते रहते हैं?
दूसरों की समीक्षा और 'मेरा अपना कोड' (और यहां तक कि स्वयं मानकों को कोड करना)।
आप इसे कैसे बनाए रखेंगे? (मानसिक नोट्स से, एक दस्तावेज रखते हुए, स्टाइलकॉप जैसे उपकरण का उपयोग करके)
मैं dokuwiki का उपयोग करता हूं , सेटअप करने के लिए एक हवा (कोई डेटाबेस नहीं), पदानुक्रमित संरचना, दानेदार नियंत्रण (बॉक्स से बाहर एसीएल), वास्तव में अच्छा लग रहा है, और अच्छी तरह से, यह एक विकी है, इसलिए कोई भी योगदान कर सकता है। साथ ही, सादगी और पठनीयता के आधार पर योगदान / परिवर्तन हमेशा सर्वसम्मति और उचित होते हैं।
यह एक अजीब जवाब की तरह है, लेकिन मुझे वास्तव में प्रोग्रामिंग लेने में वास्तव में लंबा समय लगा। मैंने खुद को प्रोग्रामर मानने से पहले 'आर्ट्स' में काम करने में बहुत समय बिताया।
कोडिंग करते समय, मैं लेखन - पैराग्राफ, वाक्यांश इत्यादि जैसी इकाइयों में सोचना पसंद करता हूं। इस वजह से, मैं इसे कहानी / निबंध / आदि की तरह पठनीय बनाने के लिए अधिक पंक्तियों में कोड फैलाऊंगा। मुझे बहुत गुस्सा आता है जब डेवलपर्स एक पंक्ति में या एक छोटी सी जगह पर जितना संभव हो उतना रटना करने की कोशिश करते हैं, क्योंकि यह लेखक को चतुर बनाने और किसी भी भविष्य के पाठकों को परेशान करने के अलावा कुछ भी पूरा नहीं करता है।
अगर मुझे दक्षता के लिए कुछ अजीब करने की आवश्यकता है, तो मैं इसे समझाने के लिए टिप्पणी करूंगा कि यह ऐसा क्यों है।
मुझे शायद इसके लिए कोई उथल-पुथल नहीं मिलेगी, लेकिन शायद इससे कुछ चर्चा छिड़ जाएगी।
तकनीकी पक्ष के लिए, कोष्ठक की नियुक्ति और जैसे, मैं उन्हें संरेखित करता हूं क्योंकि परिणाम पठनीयता बढ़ जाती है।
1. How did you define and find your coding style?
मैं पहले से ही विकसित शैली गाइड को अपनाने के लिए जाता हूं जो बड़े पैमाने पर विकसित और व्यापक रूप से स्वीकार या एक बड़ी कंपनी / परियोजना द्वारा लोकप्रिय है।
मैं इसे कई कारणों से करता हूं, लेकिन मुख्यतः क्योंकि इस तरह के स्टाइल गाइड को डेवलपर्स द्वारा तुरंत अपनाया जा सकता है। एक स्टाइल गाइड केवल उतना ही लायक है जितना डेवलपर्स इसे छड़ी करने के लिए तैयार हैं।
ऐसे उदाहरण हैं पायथन के PEP 8 , Android के जावा के लिए स्टाइल गाइड , jQuery के कोर स्टाइल गाइड या Google के पायथन स्टाइल गाइड ।
2. How do you keep augmenting and improving it?
इस तरह के स्टाइल गाइड के लिए सबसे बड़ा तर्क यह है कि वे नॉट इनवेंटेड हियर थे और नॉट इन्वेंटेड बाई मी। यह डेवलपर्स के स्कोर को ले गया, आपकी कंपनी / टीम की तुलना में कोड और अधिक समय से डराने वाली लाइनें कभी भी स्टाइल गाइड को विकसित करने और बनाए रखने में निवेश करने के लिए तैयार होंगी।
सुधारों के रूप में, कभी भी एक स्टाइल गाइड नहीं रहा है जो आपको जानने के लिए आवश्यक हर चीज का तुरंत जवाब देता है। लेकिन, ज्यादातर मामलों में मैंने जो सुधार देखा है उसे आगे धकेला गया था, स्टाइल गाइड पहले से ही एक अधिक वर्बोज़ संस्करण था, जो इसे लिखने वाले कोड के पास था।
ऐसे मामलों में जब आप विकृति के एक ब्लॉक में भाग लेते हैं, तो आपको इसे एक गिस्ट में या किसी अन्य उपयुक्त कोड स्निपेट शेयरिंग टूल में कलर-सिंटैक्स सपोर्ट के साथ पेस्ट करना चाहिए और अन्य डेवलपर्स के साथ कहीं पर चर्चा करनी चाहिए। महान बात यह है कि ऐसे उदाहरणों में आपकी रुचि नहीं है कि कोड क्या करता है, लेकिन बस कोड कैसे दिखाई देता है, इसलिए आप उस ब्लॉक को संदर्भ से बाहर ले जा सकते हैं और चर्चा कर सकते हैं कि आपको इसे सुधारने के बारे में कैसे जाना चाहिए, इसकी तुलना में जो पहले से ही निर्दिष्ट है। चर्चा के लिए मुख्य प्रारंभिक बिंदु के रूप में शैली गाइड।
3. How do you maintain it?
खैर, बड़ी बात यह है कि आपके पास पहले से मौजूद दस्तावेज़ होंगे जो सार्वजनिक रूप से ऑनलाइन बनाए हुए हैं।
जब कोड फ़ॉर्मेटिंग की बात आती है, तो आप अतिरिक्त मील भी जा सकते हैं और अपनी टीम को उनके पसंदीदा संपादक के लिए फ़ॉर्मेटर कॉन्फ़िगरेशन प्रदान कर सकते हैं, जिसे टिप-टॉप दिखावे को बनाए रखने पर क्रूड और अनुमान लगाना चाहिए। वास्तव में, मैं इसे अतिरिक्त मील नहीं कहूंगा, लेकिन विकास का एक अभिन्न अंग है - ऐसा कुछ भी बदतर नहीं है जहां 90% कोड परिवर्तन किसी ऐसे व्यक्ति को करना है जो ठीक से स्वरूपित / स्टाइल कोड का चेक-इन था क्योंकि कोई भूल गया था इससे पहले कि वे एक बड़ी नई विशेषता को साफ करें।
यदि आप एक टीम का हिस्सा हैं, तो आपको हमेशा टीम के मानक को जोड़ना चाहिए। जेनेरिक लेआउट का उपयोग करने के लिए बहुत कुछ कहा जा सकता है और आपका अपना व्यक्तिगत नहीं। यह आपके कोड को दूसरों द्वारा पढ़ना और समझना आसान बनाता है जो कि आवश्यक है।