क्या ऑटो प्रारूप का उपयोग करके ग्रहण में कोड को प्रारूपित करना एक अच्छा विचार है

Question

मैं कोडिंग के लिए ग्रहण का उपयोग करता हूं, और जिस भाषा का हम उपयोग करते हैं वह जावा है। एक बार जब किसी ने यह सुझाव दिया था कि कोड को ठीक से प्रारूपित करना है, तो ऑटो फॉर्मैटर (CTRL + SHIFT + F) का उपयोग करते हुए, जबकि यह कमांड कोड को प्रारूपित करता है, लेकिन कभी-कभी मुझे लगता है कि समग्र रूप अजीब हो जाता है, और यह वास्तव में बहुत पठनीय नहीं है।

तो क्या यह एक अनुशंसित बात है? यदि नहीं तो ग्रहण में हमारे कोड को प्रारूपित करने से बेहतर क्या है?

Comments

मैं हर समय emacs की ऑटो-स्वरूपण क्षमता का उपयोग करता हूं - टक्करों के लिए क्षमताएँ हैं (जैसे SC विलय के साथ) .. लेकिन कुल मिलाकर, आपके प्रारूप का मानकीकरण अत्यंत मददगार है

— वॉरेन

Answer 1

सख्त कोड स्वरूपण नियम उपयोगी होते हैं जब कई डेवलपर एक संस्करण नियंत्रण प्रणाली का उपयोग करके एक ही कोड पर काम करते हैं। मर्जिंग एक दर्द हो सकता है अगर अलग-अलग डेवलपर्स के पास अलग-अलग स्वरूपण नियम हैं क्योंकि एक ही कोड विलय टूल के लिए अलग होगा।

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

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

Comments

एक बार जब आप अपना फ़ॉर्मेटर सेटअप कर लेते हैं तो आप इसे पसंद कर लेंगे। एक "निर्यात" बटन है जो आपको एक .xml फ़ाइल में सहेजने की अनुमति देगा। हम इसे अपने एसवीएन रिपॉजिटरी में डालते हैं, इसलिए जब वे इस परियोजना की जांच करते हैं, तो हर किसी के पास इसका उपयोग होता है।

— क्रिस

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

— मुफासा

यदि आप कोड स्वरूपण सेटिंग्स को अनुकूलित करते हैं, तो उन सेटिंग्स को स्रोत नियंत्रण में धकेल दें ताकि सभी डेवलपर्स उन्हें प्राप्त करें, या उन्हें किसी तरह के विकी या डेवलपर प्रलेखन में प्रकाशित करें ताकि हर कोई शैली पर सहमत हो सके।

— मुफ्ता

Answer 2

मैंने ऑटोफोरमैटर को बहुत उपयोगी पाया है। कोड को फॉर्मेट कैसे किया जाना चाहिए, इस पर लगातार माइक्रोडेसिस लेने के बजाय - कुछ ऐसा है जो त्रुटि-प्रवण है और "संज्ञानात्मक घर्षण" का कारण बनता है - आप प्रारूपण नियमों को सेट कर सकते हैं और ग्रहण कोड को आपके लिए प्रारूपित कर सकते हैं (आदर्श रूप से स्वचालित रूप से "सहेजें क्रियाओं का उपयोग करके") )। बेशक, इसके लिए आवश्यक है कि आपके पास सुसंगत प्रारूपण के साथ एक कोड आधार हो, या आपके पास आपके द्वारा निर्धारित नियमों के अनुसार कोड को पुन: स्वरूपित करने का जनादेश हो।

"ऑटोफ़ॉर्मेट-ऑन-सेव" सक्षम होने के कारण वृद्धिशील संकलन करना थोड़ा पसंद है, यह आपके मस्तिष्क को कोड स्वरूपण या वाक्यविन्यास जैसे तुच्छ मुद्दों से संबंधित होने के बजाय कोड पर ही केंद्रित रहने की अनुमति देता है।

लेकिन हां, कभी-कभी ऑटोफॉमरेट आपके पास कुछ अच्छी तरह से स्वरूपित तालिका को गड़बड़ कर देगा। ऐसे मामलों में मैं "पर / बंद टैग" का उपयोग करता हूं। इन्हें कोड स्वरूपण प्रोफ़ाइल में "चालू / बंद टैग" टैब के तहत कॉन्फ़िगर किया गया है। उनका उपयोग करके, आप अपने कोड के क्षेत्रों को स्वचालित रूप से फ़ॉर्मेट होने से बाहर कर सकते हैं:

// @formatter:off

... my nicely formatted table here ...

// @formatter:on

Comments

+1: मुझे कभी भी पता नहीं था (या अधिक सटीक होने के लिए, मैंने ऑन / ऑफ टैग के बारे में पता लगाने के लिए कभी परेशान नहीं किया)।

— पॉल कैगर

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

— मुफ्ता

@ मुफासा हां, आप सही कह रहे हैं।

— जेसपेरे

जब आप प्रारूप टिप्पणी नहीं चाहते हैं तो आप लिख सकते हैं / * - मेरा सुपर प्रारूप * / ग्रहण इस तरह की टिप्पणी को प्रारूपित नहीं करते हैं :)

— दाविद दाजद

Answer 3

यह अनुशंसित है या नहीं, यह इस पर निर्भर करेगा कि आप किससे पूछते हैं।

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

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

एक अच्छा आईडीई या उपकरण अक्सर आपके लिए कोड को प्रारूपित करने में एक अर्ध-सभ्य काम कर सकता है, लेकिन हमेशा इसे आप के लिए पठनीय नहीं बना सकते।

इसलिए, मेरी सलाह: जब तक आप किसी और से कोड प्राप्त नहीं करते हैं, तब तक इसका उपयोग न करें, और यह ऐसी गड़बड़ है कि आप इसे अन्यथा नहीं पढ़ सकते हैं।

Answer 4

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

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

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

Answer 5

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

विशेष रूप से यदि आपके पास "कोड क्लीनअप" + "फॉर्मैटर" है, तो सक्षम करें कि हर सेव पर इंडेंट फिक्स्ड / अनफिक्स हो जाते हैं।

ग्रहण के प्रत्येक नए संस्करण में फॉर्मेटर (बेहतर के लिए) बदल सकता है, लेकिन महत्वपूर्ण बदलावों का परिचय देगा जैसे कि JavaDocs अंत में उस अतिरिक्त स्थान को हटा देता है, *लेकिन जो कुछ समय बाद हेलिओस के साथ पेश किया गया है और बहुत सारे उद्यम ग्रहण के पुराने तर्कसंगत सॉफ्टवेयर संस्करण का उपयोग कर रहे हैं। यह आधार के रूप में हेलियोस का उपयोग करता है।

कोड फॉर्मेटर जो एक्लिप्स द्वारा प्रदान किया गया है, उनके एपीआई के प्रति वास्तव में एक्स्टेंसिबल नहीं है, यह स्पष्ट रूप से बताता है

इस वर्ग को ग्राहकों द्वारा उपवर्गित करने का इरादा नहीं है।

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