Yarn: हेल्पर बनाम यूटिल बनाम यूटिल्स

मुझे एकवचन Util सबसे अच्छा लगता है। यूटिल के लिए। हेल्पर के लिए, यूटिल्स के लिए

tbh मैं किसी भी तरह से जा सकता था, चलो लगातार बने रहें।

इसके अलावा, अगर हमारे पास क्रियाएं हैं तो हम -ing (gerund) का उपयोग कर सकते हैं, जैसे Chatting NetworkThreading , या बहुवचन संज्ञाएं, जैसे Projectiles Screenshots over Helper Util आदि।

इससे MathHelper -> Maths जैसी कुछ चीजों के लिए मुश्किल हो जाती है ?? या Util -> s ??

मैंने बहुत पहले Maths के लिए तर्क दिया है, यह देखते हुए कि यह Mathematics के लिए एक वैध संक्षिप्त नाम है। https://github.com/FabricMC/yarn/issues/249#issuecomment -446102638

यार्न अमेरिकी अंग्रेजी नामों का उपयोग करता है, जहां Maths Mathematics के लिए वैध संक्षिप्त नाम नहीं है।

इस मामले में जहां न तो गेरुंड और न ही बहुवचन लागू होता है, मेरा सुझाव है कि Helper प्रत्यय पर वापस जाएं। अन्यथा ing या s पसंद करें, जैसे Texts

इसके अलावा DrawableHelper एक उपयोगिता वर्ग नहीं है बल्कि एक कार्यात्मक इंटरफ़ेस या अमूर्त वर्ग है जिसमें बहुत से सुविधाजनक उदाहरण विधियां हैं

लिआच के प्रस्ताव के साथ -इंग और -s के साथ मेरा मुद्दा यह है कि यह कुछ भी सुसंगत बनाने के लिए बहुत कठिन बनाता है, इस मुद्दे के उद्देश्य को पूरी तरह से हरा देता है। आप इसे -s में समाप्त होने वाली संज्ञा उपयोगिता वर्गों की गणना कर सकते हैं, लेकिन फिर आपके पास अपवाद होने जा रहे हैं: Nbts , RailPlacements , Maps ? सुसंगत बनाना असंभव होगा।

हमें एक मानक अपनाना चाहिए और उस पर टिके रहना चाहिए। वोट को देखते हुए, वह या तो Helper या Util होना चाहिए, लेकिन Utils नहीं होना चाहिए।

Util से अधिक Helper के लिए एक तर्क यह है कि वर्ग Util स्वयं को Helper कहलाने का कोई मतलब नहीं है। मुझे लगता है कि MathHelper को MathUtil कहा जाना इतना बुरा नहीं होगा, यह सिर्फ इतना है कि हर किसी को इसका उपयोग MathHelper कहा जाता है। मैंने उन परियोजनाओं में काम किया है जहां गणित उपयोगिता वर्ग को MathUtil कहा जाता है, और यह बिल्कुल ठीक रहा है, इससे कोई फर्क नहीं पड़ता। MathUtil नाम पर MathHelper का नाम बदलने के मुद्दे पर भी चर्चा नहीं की गई थी।

वर्तमान में Util Helper कक्षाएं हैं, लेकिन कक्षाओं का वास्तव में कितनी बार उपयोग किया जाता है, इसके आधार पर इसे भारित करने की आवश्यकता है, इसलिए मैं अब उस पर गौर करने जा रहा हूं और परिणामों की रिपोर्ट करूंगा .

ऐसा लगता है कि अधिकांश लोग Helper प्रत्यय के लिए हैं। इसलिए मैं Util या Utils (वर्ग Util को छोड़कर) के साथ समाप्त होने वाली सभी मौजूदा कक्षाओं का नाम बदलने का प्रस्ताव करता हूं Helper । Helper में समाप्त होने वाली अन्य कक्षाओं के नामों पर अलग-अलग मुद्दों पर चर्चा की जा सकती है।

ऐसा लगता है कि अधिकांश लोग Helper प्रत्यय के लिए हैं।

नहीं?

ओह, ओह, मुझे अंधा होना चाहिए। फिर मेरा प्रस्ताव है कि हम Helper में समाप्त होने वाले सभी वर्गों का नाम बदलकर Util कर दें।

मैं प्रस्ताव करता हूं कि प्रत्यय शैतान का काम है और हम *elperer और *til में समाप्त होने वाले सभी वर्ग का नाम बदलकर उस प्रत्यय को नहीं रखते हैं।

MathHelper -> Maths ।

PiglinHelper -> Piglins

यार्न अमेरिकी अंग्रेजी नामों का उपयोग करता है, जहां Maths Mathematics के लिए वैध संक्षिप्त नाम नहीं है।

मैंने सोचा था कि Maths एक विशेष रूप से अमेरिकी शब्द था?

MathHelper -> Mathinator

Maps ? मैं

यह भी ध्यान दें कि अमरूद (मुझे लगता है कि यह अमरूद था?) बहुवचन पैटर्न का उपयोग करता है: Maps , Sets , Collections , Streams ।

बहुवचन का उपयोग करने में यह मेरी समस्या थी। हालाँकि नाम अच्छे लगते हैं, फिर भी बहुत सारे अपवाद हैं। या तो क्योंकि शब्द एक जन संज्ञा है (जैसे "गणित") और इसलिए इसका कोई बहुवचन नहीं है, या क्योंकि बहुवचन पहले से ही किसी अन्य पुस्तकालय (जैसे "मानचित्र") द्वारा लिया गया है। पहले स्थान पर उन्हें बदलने की बात को हराकर, लगातार बने रहना बहुत कठिन हो जाएगा।

बहुवचन रूप में ठीक होने वाले नाम:

• बफ़र
• डेटा स्ट्रीम
• ड्रॉएबल
• डिफ़ॉल्ट खाल
• मिपमैप
• एनबीटीएस
• रेल प्लेसमेंट
• spawns
• इनपुट
• मॉडल
• बनावट
• फ़ाइल नाम
• प्रोजेक्टाइल
• लक्ष्य देखें
• संरचना परीक्षण
• परीक्षण
• स्क्रीनशॉट
• Glआवंटन

नाम जो ठीक नहीं हैं क्योंकि वे जन संज्ञा हैं या संज्ञा नहीं हैं:

• जोंसो
• गणित
• इसके अलावा
• ग्लफ्स
• सहज बनाता है
• नुकसान (बहुवचन का एक अलग अर्थ है)
• नेटवर्क (यहाँ केवल एक नेटवर्क है)
• नेटवर्क थ्रेड्स (केवल एक नेटवर्क थ्रेड है)
• नेटवर्क एन्क्रिप्शन

नाम जो ठीक नहीं हैं क्योंकि वे पहले ही लिए जा चुके हैं:

• टोना
• एमएपीएस
• स्थिति प्रभाव
• पोशन

नाम जो विविध कारणों से ठीक नहीं हैं:

• Rotation3s (इस नाम पर अधिक विचार करने की आवश्यकता है)
• चैट (हालांकि तकनीकी रूप से चैट का बहुवचन, यह "चैट" के लिए एक उपयोगिता वर्ग के रूप में अच्छी तरह से फिट नहीं है, यह मानते हुए कि इसके लिए क्या है। यदि यह टेक्स्ट घटकों के लिए है, तो "टेक्स्ट" एक ठीक नाम होगा)
• Utils (हम इसका नाम बदलकर "s" lol नहीं कर सकते, इसे "Util" के रूप में ही रखा जाता है)

कुल मिलाकर, 18/34 नाम बहुवचन के रूप में ठीक होंगे, जिसका अर्थ है कि हमें अन्य 16 के लिए बेहतर नामों के साथ आना होगा। निरंतरता के लिए बहुत कुछ।

मैं बहुवचनों का उपयोग करने के साथ ठीक रहूंगा जहां यह समझ में आता है और एक यूटिल प्रत्यय पर वापस आ जाता है जहां यह समझ में नहीं आता है। फिर कम से कम हमारे पास "हेल्पर" और "यूटिल" के बीच बेतरतीब ढंग से चुनने के बजाय पालन करने के लिए एक नियम है, जो कि हम वर्तमान में करते हैं।

@Earthcomputer NetworkThreads ठीक काम करता है, हालाँकि। यह नेटवर्क थ्रेड्स के साथ काम करने के लिए उपयोगिताएँ हैं। कोई फर्क नहीं पड़ता कि उनमें से केवल एक ही है।

आप इनमें से एक या दो बिंदुओं पर मुझसे असहमत हो सकते हैं, लेकिन यह बात नहीं है, यह 18/34 के समग्र अनुपात को बहुत अधिक नहीं बदलता है।

मैं या तो Util या Helper के लिए बहस करूंगा, उन्हें पूरी तरह से हटाने से मुझे बहुत अधिक समझ में नहीं आता है।

वैसे, कुछ का नाम Util नहीं हो सकता। उदाहरण के लिए, DataStreamHelper एक उपयोग वर्ग नहीं है, यह एक ऑब्जेक्ट है जो डेटा स्ट्रीम को लपेटता है।