एक टीम के भीतर विरोधाभासी जावा शैलियाँ

Question

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

स्पष्ट करने के लिए, मैं सोच रहा था कि क्या कोई ऐसा संगठन है जो उदाहरण के लिए चर और कार्यों के लिए उचित नामकरण सम्मेलन को निर्देशित करेगा। यह सर्वोपरि है क्योंकि इतनी कम समय सीमा के साथ हम एक दूसरे के कोड को समझने की कोशिश में समय नहीं लगा सकते।

Answer 1

ऐसा एक संगठन है: सन / ओरेकल ही। दस्तावेज़ को जावा प्रोग्रामिंग लैंग्वेज के लिए कोड कन्वेंशन कहा जाता है , और यह आपके द्वारा आवश्यक अधिकांश सम्मेलनों का वर्णन करता है। बस हर कोई इसे पढ़ने और इसकी सिफारिशों का पालन करने के लिए सहमत है।

Comments

यह एक अच्छी तरह से ज्ञात एसटीडी है, लेकिन जहां टीम सहमत है, वहां से विचलित होने से डरो मत। चौड़ाई में 80 वर्णों तक सीमित होना उदाहरण के लिए दर्दनाक हो सकता है।

— मार्टिज़न वर्बर्ग

@MartijnVerburg सीमा, गहरी इंडेंटेशन से बचने के लिए तरीकों और कक्षाओं में रिफैक्टिंग का संकेत दे सकती है।

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

— उपयोगकर्ता अज्ञात

@userunknown तुम सही हो। मैं भी सभी सम्मेलनों से सहमत नहीं हूँ। लेकिन यह ओपी की समय सीमा को देखते हुए एक अच्छा समझौता है।

— एंड्रेस एफ।

Answer 2

मैं वास्तव में एंड्रेस के जवाब पर टैग कर रहा हूं , और जावा कोड को समान रूप से प्रारूपित करने पर ध्यान केंद्रित कर रहा हूं ।

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

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

मुझे लगता है कि अन्य प्रमुख जावा आईडीई (IntelliJ और Netbeans) प्रारूप सेटिंग्स के निर्यात के लिए एक समान सुविधा है।

Comments

+1 अच्छा जवाब! आप चेकस्टाइल की तरह एक प्लगइन भी स्थापित कर सकते हैं और जब आप सम्मेलनों को तोड़ते हैं तो यह आपको चेतावनी देता है।

— एंड्रेस एफ।

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

हां, मैंने हाल ही में ऐसा करना शुरू किया। केवल एक चीज जिस पर मुझे यकीन नहीं है, वह यह है कि मैंने सेव ऑप्शन पर "अप्रयुक्त प्राइवेट वेरिएबल्स को हटा" का चयन किया। इसलिए जब मैं टीडीडी कर रहा हूं, तो मुझे लगता है कि अक्सर, मेरे चर गायब हो जाते हैं क्योंकि कोड का उपयोग करने से पहले सहेज लिया गया था ... लेकिन इसके अलावा, यह विकल्प बहुत अच्छा रहा है।

— सैम गोल्डबर्ग

Answer 3

यह [कोडिंग की विभिन्न शैली] इतनी छोटी समय सीमा के साथ सर्वोपरि है कि हम किसी अन्य कोड को समझने के लिए समय बिताने का जोखिम नहीं उठा सकते हैं।

वास्तव में। यह सर्वोपरि नहीं है।

एक सलाहकार के रूप में 30 वर्षों के बाद, मैंने बहुत सारे ग्राहकों से बहुत सारे कोड पढ़े हैं । यह ध्यान रखना महत्वपूर्ण है कि हर ग्राहक (और अक्सर एक ग्राहक संगठन के भीतर) अलग-अलग शैली होते हैं।

इतनी सारी शैलियों को पढ़ने के बाद, मैंने यह सीखा है।

स्टाइल मैटर नहीं है

कृपया उस कोड लिखने पर ध्यान दें जो हमेशा काम करता है, और इकाई परीक्षण लेखन जो यह साबित करता है कि यह हमेशा काम करता है।

यदि आपने वर्किंग कोड भेज दिया है, तो आप इसे ठीक कर सकते हैं यदि आप बग्स से बाहर निकल आए हैं, तो आप इसे ठीक कर सकते हैं और इंस्टॉल कर सकते हैं।

Comments

शायद यह बात नहीं है, लेकिन यह भी बहुत अच्छा है, और बहुत आसान है।

— केविन

स्टाइल मायने नहीं रखता, लेकिन स्थिरता मायने रखती है। असंगत शैली सॉफ़्टवेयर के रखरखाव को बहुत कठिन बना देती है।

— जेसपर

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

— S.Lott

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

— ब्रायन ओकले

"आप कोड" सर्वश्रेष्ठ "मामूली बेहतर" पर होंगे। और हाँ, यह लगभग शून्य लागत और निश्चित रूप से शून्य जोखिम है। परंतु। 100% परीक्षण कवरेज कहीं अधिक, अधिक मूल्यवान है जो निरंतरता है।

— S.Lott

Answer 4

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

संगति सहयोग में सुधार करती है, सहयोग संहिता में सुधार करता है।

यहां तक ​​कि अगर वास्तविक स्थिरता मदद नहीं करती है, तो यह तथ्य कि आपकी टीम ने एक समझौते पर आने के लिए एक साथ काम किया है वह एक अच्छी बात है। कोडिंग सम्मेलनों के रूप में सरल रूप में किसी चीज के लिए सहमत होने में उनकी असमर्थता कहती है कि सतह के नीचे बड़ी टीमवर्क समस्याएं हो सकती हैं।

Answer 5

ऊपर बताई गई सन जावा सीसी न केवल 13 साल पुरानी है और इसके कुछ नियम पुराने हैं (जैसे प्रति पंक्ति 80 वर्ण), लेकिन यह नामकरण सम्मेलनों को परिभाषित नहीं करता है, सिवाय सबसे सामान्य लोगों के लिए (कक्षाओं के लिए ऊंट आवरण, ब्लॉक राजधानियों) स्थिर अंतिम चर और पसंद के लिए)।

आपको विभिन्न प्रकार की कक्षाओं के लिए अपने स्वयं के मानकों को परिभाषित करने की आवश्यकता है , जैसे कि डीएओ, ईजेबी, संस्थाएं, जो भी आप उपयोग करते हैं। Sun Java CC एक एब्सट्रैक्ट बेस क्लास की तरह है जिसका विस्तार है :)

Comments

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

— एंड्रेस एफ।

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

— BillThor

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

— डोनल फैलो

@DonalFellows हाँ, इस दिन और उम्र में, 80 वर्णों की सीमा आपको रिफ्लेक्टर को याद दिलाने के लिए है, न कि छोटे टर्मिनल स्क्रीन के कारण।

— एंड्रेस एफ।

Answer 6

जैसा कि यहां दूसरों ने बताया है, आप जावा के लिए कुछ लोकप्रिय 'स्टाइल गाइड' में से 1 के लिए ऑनलाइन खोज कर सकते हैं और टीम में सभी को उनसे चिपके रहने के लिए राजी कर सकते हैं। जब आप ऐसा नहीं कर रहे हों तो आपके पसंदीदा आईडीई में कुछ कोड जाँच उपकरण आपको याद दिलाने में मदद कर सकते हैं।

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

इसलिए आपकी स्थिति पर भी विचार करना महत्वपूर्ण है।

Comments

यह कौन सा देश है? एक सांस्कृतिक चीज की तरह लगता है।

@ ThorbjørnRavnAndersen उनका कहना है कि "जब वे इतने लंबे कामों के लिए क्या कर रहे हैं तो लोग बदलाव के लिए प्रतिरोधी हो सकते हैं।" इस अर्थ में राजनीतिक सिर्फ "कार्यालय राजनीति" है

— रोबोटिक

Answer 7

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

Answer 8

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

मेरा सुझाव है कि आप स्पार्टन प्रोग्रामिंग में देखें ।

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