व्यापक प्रश्न:
क्या आपने कभी इस तरह के मानक लगाए जाने के बारे में सुना है? यदि हां, तो इसके पीछे क्या कारण था?
हां, मैंने इसके बारे में सुना है, और पूरी तरह से योग्य वस्तु नामों का उपयोग करके नाम टकराव को रोकता है। हालांकि दुर्लभ, जब वे होते हैं, तो वे असाधारण रूप से पता लगाने के लिए कांटेदार हो सकते हैं।
एक उदाहरण:
उस प्रकार के परिदृश्य को शायद एक उदाहरण के साथ बेहतर ढंग से समझाया गया है।
मान लीजिए कि हमारे पास Lists<T>दो अलग-अलग प्रोजेक्ट हैं।
System.Collections.Generic.List<T>
MyCorp.CustomCollections.Optimized.List<T>
जब हम पूरी तरह से योग्य ऑब्जेक्ट नाम का उपयोग करते हैं, तो यह स्पष्ट है कि List<T>इसका उपयोग किया जा रहा है। यह स्पष्टता स्पष्ट रूप से वाचालता की कीमत पर आती है।
और आप बहस कर रहे होंगे, "रुको! कोई भी कभी भी दो सूचियों का उपयोग नहीं करेगा!" वह वह जगह है जहां मैं रखरखाव परिदृश्य को इंगित करता हूं।
आप Fooअपने निगम के लिए लिखित मॉड्यूल हैं , जो स्वीकृत, अनुकूलित निगम का उपयोग करता है List<T>।
using MyCorp.CustomCollections.Optimized;
public class Foo {
List<object> myList = ...;
}
बाद में, एक नया डेवलपर आपके द्वारा किए जा रहे काम का विस्तार करने का निर्णय लेता है। कंपनी के मानकों के बारे में पता नहीं होने के कारण, वे usingब्लॉक को अपडेट करते हैं :
using MyCorp.CustomCollections.Optimized;
using System.Collections.Generic;
और आप देख सकते हैं कि कैसे जल्दी में चीजें खराब हो जाती हैं।
यह इंगित करने के लिए तुच्छ होना चाहिए कि आपके पास एक ही नाम के दो मालिकाना वर्ग हो सकते हैं लेकिन एक ही परियोजना के भीतर विभिन्न नामस्थानों में। तो यह सिर्फ .NET फ्रेमवर्क आपूर्ति की गई कक्षाओं से टकराने की चिंता नहीं है।
MyCorp.WeightsAndLengths.Measurement();
MyCorp.TimeAndSpace.Measurement();
वास्तविकता:
अब, क्या अधिकांश परियोजनाओं में ऐसा होने की संभावना है? नहीं वास्तव में नहीं। लेकिन जब आप बहुत सारे इनपुट के साथ एक बड़े प्रोजेक्ट पर काम कर रहे होते हैं, तो आप पूरी कोशिश करते हैं कि आप पर चीजें फटने की संभावना कम से कम हो।
कई योगदान करने वाली टीमों के साथ बड़ी परियोजनाएं आवेदन की दुनिया में एक विशेष प्रकार की जानवर हैं। नियम जो अन्य परियोजनाओं के लिए अनुचित लगते हैं, परियोजना के लिए इनपुट धाराओं और इस संभावना के कारण अधिक प्रासंगिक हो जाते हैं कि योगदान करने वालों ने परियोजना के दिशानिर्देशों को नहीं पढ़ा है।
यह तब भी हो सकता है जब दो बड़ी परियोजनाओं को एक साथ मिला दिया जाता है। यदि दोनों परियोजनाओं में समान रूप से नामित कक्षाएं थीं, तो जब आप एक परियोजना से दूसरी परियोजना का संदर्भ देना शुरू करेंगे, तो आप टकराव देखेंगे। और परियोजनाएं रिफ्लेक्टर के लिए बहुत बड़ी हो सकती हैं या प्रबंधन रिफैक्टरिंग पर खर्च किए गए समय को निधि देने के लिए खर्च को मंजूरी नहीं देगा।
विकल्प:
जब आप नहीं पूछते हैं, तो यह इंगित करने के लायक है कि यह समस्या का एक महान समाधान नहीं है। ऐसी कक्षाएं बनाना अच्छा नहीं है जो उनके नाम स्थान की घोषणा के बिना टकराएंगी।
List<T>, विशेष रूप से, एक आरक्षित शब्द के रूप में माना जाना चाहिए और आपकी कक्षाओं के नाम के रूप में उपयोग नहीं किया जाना चाहिए।
इसी तरह, परियोजना के भीतर अलग-अलग नामस्थानों को अद्वितीय वर्ग नाम रखने का प्रयास करना चाहिए। कोशिश करना और याद रखना कि Foo()आप किस नामस्थान के साथ काम कर रहे हैं, मानसिक ओवरहेड है जो सबसे अच्छा बचा जाता है। एक और तरीका कहा: होने MyCorp.Bar.Foo()और MyCorp.Baz.Foo()अपने डेवलपर्स यात्रा करने के लिए जा रहा है और सबसे अच्छा बचा।
यदि और कुछ नहीं, तो आप अस्पष्टता को हल करने के लिए आंशिक नाम स्थान का उपयोग कर सकते हैं। उदाहरण के लिए, यदि आप पूरी तरह से किसी भी Foo()वर्ग का नाम नहीं बदल सकते हैं तो आप उनके आंशिक नामस्थान का उपयोग कर सकते हैं:
Bar.Foo()
Baz.Foo()
आपके वर्तमान प्रोजेक्ट के विशिष्ट कारण:
आपने उस मानक के बाद अपने वर्तमान प्रोजेक्ट के लिए दिए गए विशिष्ट कारणों से अपने प्रश्न को अपडेट किया। आइए उन पर एक नज़र डालें और वास्तव में नीचे बनी पगडंडी को खोदें।
पूरी तरह से योग्य प्रकार प्राप्त करने के लिए नाम पर माउस को मँडराना बोझिल है। हर समय पूरी तरह से योग्य प्रकार दिखाई देना बेहतर है।
"बोझिल?" उम नहीं। शायद कष्टप्रद। ऑन-स्क्रीन पॉइंटर को शिफ्ट करने के लिए प्लास्टिक के कुछ औंस को स्थानांतरित करना बोझिल नहीं है । लेकिन मैं पीछे हटा।
तर्क की यह रेखा किसी भी चीज़ की तुलना में कवर-अप की तरह अधिक लगती है। ऑफहैंड, मुझे लगता है कि एप्लिकेशन के भीतर कक्षाएं कमजोर रूप से नामित हैं और आपको क्लास नाम के आसपास की अर्थ सूचना की उचित मात्रा को चमकाने के लिए नेमस्पेस पर भरोसा करना होगा।
यह पूरी तरह से योग्य वर्ग नामों के लिए एक वैध औचित्य नहीं है, शायद यह आंशिक रूप से योग्य वर्ग नामों का उपयोग करने के लिए एक वैध औचित्य है।
ईमेल कोड स्निपेट में पूरी तरह से योग्य नाम नहीं है, और इसलिए इसे समझना मुश्किल हो सकता है।
यह (जारी?) तर्क की पंक्ति मेरे संदेह को पुष्ट करती है कि कक्षाएं वर्तमान में खराब रूप से नामित हैं। फिर से, गरीब वर्ग के नाम रखने के लिए पूरी तरह से योग्य वर्ग नाम का उपयोग करने के लिए सब कुछ की आवश्यकता के लिए एक अच्छा औचित्य नहीं है । यदि कक्षा के नाम को समझना मुश्किल है, तो पूरी तरह से योग्य वर्ग के नामों को ठीक करने की तुलना में बहुत अधिक गलत है।
विज़ुअल स्टूडियो (नोटपैड ++, उदाहरण के लिए) के बाहर कोड को देखने या संपादित करते समय, पूरी तरह से योग्य प्रकार का नाम प्राप्त करना असंभव है।
सभी कारणों में से, इस एक ने मुझे अपना पेय थूक दिया। लेकिन फिर, मैं पचाता हूं।
मुझे आश्चर्य हो रहा है कि विज़ुअल स्टूडियो के बाहर टीम अक्सर एडिटिंग या कोड क्यों देख रही है? और अब हम एक औचित्य को देख रहे हैं जो कि नाम स्थान प्रदान करने के लिए बहुत अच्छी तरह से रूढ़िवादी है। यह एक टूलिंग समर्थित तर्क है जबकि नामस्थान कोड को संगठनात्मक संरचना प्रदान करने के लिए हैं।
ऐसा लगता है कि यह परियोजना डेवलपर्स के साथ खराब नामकरण सम्मेलनों से ग्रस्त है जो टूलींग उनके लिए क्या प्रदान कर सकते हैं इसका लाभ नहीं उठा रहे हैं। और उन वास्तविक मुद्दों को हल करने के बजाय, उन्होंने लक्षणों में से एक पर एक बैंड-सहायता को थप्पड़ मारने का प्रयास किया है और पूरी तरह से योग्य वर्ग नामों की आवश्यकता है। मुझे लगता है कि इसे एक पथभ्रष्ट दृष्टिकोण के रूप में वर्गीकृत करना सुरक्षित है।
यह देखते हुए कि खराब रूप से नामित कक्षाएं हैं, और यह मानते हुए कि आप रिफ्लेक्टर नहीं कर सकते हैं, इसका सही उत्तर विज़ुअल स्टूडियो आईडीई को इसके पूर्ण लाभ के लिए उपयोग करना है। संभवतः वीएस पावरटूल पैकेज जैसे प्लगइन में जोड़ने पर विचार करें। फिर, जब मैं देख रहा हूं तो मैं AtrociouslyNamedClass()कक्षा के नाम पर क्लिक कर सकता हूं, F12 दबाएं और इसे बेहतर तरीके से समझने के लिए कक्षा की परिभाषा में सीधे ले जाया जाए कि यह क्या करने की कोशिश कर रहा है। इसी तरह, मैं कोड-एफ 12 पर क्लिक करके कोड के सभी स्पॉट ढूंढ सकता हूं जो वर्तमान में उपयोग करने से पीड़ित हैं AtrociouslyNamedClass()।
बाहरी टूलींग चिंताओं के बारे में - सबसे अच्छी बात यह है कि इसे रोकना है। अगर वे तुरंत स्पष्ट नहीं करते हैं कि क्या संदर्भित है, तो आगे और पीछे ईमेल स्निपेट न करें। विज़ुअल स्टूडियो के बाहर अन्य उपकरणों का उपयोग न करें क्योंकि उन उपकरणों में कोड के आसपास की बुद्धि नहीं होती है जो आपकी टीम को चाहिए। नोटपैड ++ एक भयानक उपकरण है, लेकिन यह इस कार्य के लिए कट आउट नहीं है।
इसलिए मैं आपके द्वारा प्रस्तुत किए गए तीन विशिष्ट औचित्य के संबंध में आपके आकलन से सहमत हूं। उन्होंने कहा, मुझे लगता है कि आपको बताया गया था कि "हमारे पास इस परियोजना पर अंतर्निहित मुद्दे हैं जो संबोधित नहीं कर सकते हैं / यह नहीं है और यह है कि हमने उन्हें कैसे तय किया है।" और यह स्पष्ट रूप से टीम के भीतर गहरे मुद्दों पर बात करता है जो आपके लिए लाल झंडे के रूप में काम कर सकते हैं।