प्रकार

Question

के लिए छोटे नामकरण सम्मेलन मैं एक ढांचा विकसित कर रहा हूं, और कुछ वस्तुओं में लंबे समय से लंबे नाम हैं। मुझे यह वास्तव में पसंद नहीं है, लेकिन मुझे या तो शब्दकोष पसंद नहीं है। मैं "EventModelSocket" के लिए एक छोटे से नाम के साथ आने की कोशिश कर रहा हूं, मूल रूप से नेट सॉकेट क्लास के चारों ओर एक रैपर जो विभिन्न घटनाओं को लागू करता है, और फाइलें, ऑब्जेक्ट इत्यादि भेजने के तरीके। कुछ वस्तुओं के कारण वास्तव में लंबे नाम हैं , उदाहरण के लिए "EventModelSocketObjectReceivedEventArgs" जैसे।

मैंने थिसॉरस से सब कुछ करने की कोशिश की है, घंटों के लिए यहाँ बैठने के लिए एक शब्दकोश में।

जब आप इस तरह की स्थितियों पर आते हैं, तो कुछ नाम देने का सबसे अच्छा तरीका क्या है?

Answer 1

इसमें से कुछ को नामस्थान में पुश करें।

उदाहरण के लिए:

EventModelSocketObjectReceivedEventArgs 

EventModel.Sockets.ReceivedEventArgs 

Answer 2

ठीक है, क्या लंबे नाम कुछ नुकसान पहुंचा रहे हैं?

(संपादित करें) दो अन्य विचार: सी # 3.0 में

• उपयोग var - कि, यदि आप एक फ़ाइल में प्रकार कई बार उपयोग कर रहे हैं आधी चौड़ाई

• बचा सकते हैं एक प्रकार उर्फ ​​पर विचार

  using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;

Answer 3

मैं एक का उपयोग लंबे nam के लिए: अगर यह आपको कष्टप्रद है ई। इंटेलिजेंस नाम टाइप करने के साथ यह महत्वपूर्ण नहीं है, जब तक कि आप 15 इंच की मॉनीटर का उपयोग नहीं कर लेते।

अगर मुझे नाम कम करना पड़ा तो मैं EvtMdlSck के साथ जा सकता हूं बस काम को कम कर देता हूं लेकिन अभी भी समझ में आता है। भले ही यह मेरी वरीयता नहीं है।

Answer 4

मैं सिर्फ सबसे संक्षिप्त नामकरण उस वस्तु का वर्णन करता है का उपयोग करते हुए सुझाव है कि हो जाता है। यदि EventModelSocketObjectReceivedEventArgs ऐसा करता है, तो आगे बढ़ें। मेरा 2 सेंट।

Answer 5

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

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

Answer 6

यदि आपको वैकल्पिक नाम खोजने के लिए इतना प्रयास करना है, तो आपके पास पहले से ही सही नाम है। ऑब्जेक्ट/विधि/संपत्ति नाम स्वयं दस्तावेज होना चाहिए। अगर वे अपने सटीक उद्देश्य का वर्णन नहीं करते हैं तो उनका गलत नाम है। लंबे नामों में कुछ भी गलत नहीं है अगर वे उस वस्तु के उद्देश्य की सबसे स्पष्ट समझ देते हैं।

इंटेलिजेंस और बड़े मॉनीटर की इस उम्र में वास्तव में नामकरण में जितना संभव हो उतना वर्णनात्मक नहीं होने का कोई बहाना नहीं है।

Answer 7

अपने नामकरण पर कुछ आलोचनाओं ...

क्यों अपने घटक अपने नाम में शब्द "मॉडल" है - नहीं है कि एक सा अनावश्यक।

चूंकि आपका घटक किसी प्रकार का मैसेजिंग हब प्रतीत होता है क्यों इसके नाम पर संदेश शामिल नहीं है। MessageSender के बारे में क्या।

अपनी समस्या का समाधान करने के लिए मैं एक इंटरफ़ेस बनाउंगा और इसे संदेशदाता और एक कार्यान्वयन जैसे सामान्य नाम दिया गया है, जहां आप RandomFailingSocketMessageSender जैसे नाम के भीतर तकनीक शामिल करते हैं।

भी इस का एक अच्छा उदाहरण पाने के लिए जावा या नेट पुस्तकालयों पर एक नज़र डालें चाहता है ..

जावा से

। इंटरफेस - कक्षा/कार्यान्वयन ... मानचित्र - हैश मैप, लिंक्ड हैश मैप। सूची - लिंक्डलिस्ट

उपयोग की जाने वाली तकनीक या ढांचे के बारे में विवरण जैसे "सॉकेट" या शायद एक प्रदूषित उदाहरण "एमक्यूएसरीज़" का उपयोग करने के लिए इंटरफ़ेस नाम का हिस्सा नहीं होना चाहिए।

संदेशदाता आपके घटक के उद्देश्य को IMHO समझाता है। यह अजीब लगता है कि आपकी चीज जो "फाइलें" और "घटनाओं" भेजती है उनमें उन दो वर्णनात्मक शब्दों को शामिल नहीं किया गया है। आपके नामकरण में आपके द्वारा उपयोग की जाने वाली सामग्री अनिवार्य है और IMHO घटक के आपके वर्णन से मेल नहीं खाती है।

Answer 8

स्वरों या उस तरह पागल कुछ न हटाएं।

मैं "लंबे नाम के साथ छड़ी" लोगों के साथ हूं।

एक विचार यह है कि यदि नाम अजीब हैं, तो सिस्टम की कुछ गहरी पुनर्विचार की आवश्यकता है।

Answer 9

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