क्रिएटिव शब्दावली

Question

मैं ऐसे नोड, संपत्ति, बच्चों (आदि) के रूप में भी अक्सर नरम शब्दों का प्रयोग करने लगते हैं, और मुझे डर है कि कोई और मेरे कोड को समझने के बस क्योंकि भागों के नाम अस्पष्ट हैं कठिनाई के लिए होता है , सामान्य शब्द।

कक्षाओं और घटकों के लिए उन्हें और अधिक यादगार बनाने के लिए रचनात्मक नाम कैसे मिलते हैं?

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

Answer 1

मेरे पास वास्तव में कोई जवाब नहीं है, लेकिन आपके बारे में सोचने के लिए तीन चीजें हैं।

1. देर से फिल कार्लटन ने प्रसिद्ध रूप से कहा: "कंप्यूटर विज्ञान में केवल दो कठिन समस्याएं हैं। कैश अमान्यता और नामकरण चीजें।" तो, तथ्य यह है कि आपको अच्छे नामों के साथ आने में परेशानी हो रही है पूरी तरह से सामान्य है और यहां तक ​​कि उम्मीद है।
2. ओटीओएच, चीजों को नाम देने में परेशानी होने से भी खराब डिजाइन का संकेत हो सकता है। (और हाँ, मुझे पूरी तरह से पता है कि # 1 और # 2 एक-दूसरे से विरोधाभास करते हैं। या शायद किसी को इसे एक-दूसरे को संतुलित करने की तरह सोचना चाहिए।), अगर किसी चीज़ की बहुत ज़िम्मेदारियां हैं, तो यह आना बहुत असंभव है एक अच्छे नाम के साथ। (खराब ओओ डिज़ाइनों में सभी "सेवा", "मॉडल", "मॉडल" और "प्रबंधक" कक्षाओं को गवाह करें। "ManagerFactoryFactory" के लिए Google Code Search का एक उदाहरण यहां दिया गया है।)
3. इसके अलावा, आपके नामों को डोमेन शब्दकोष में मानचित्र करना चाहिए विषय के विशेषज्ञ। यदि आपको विषय वस्तु विशेषज्ञ नहीं मिल रहा है, तो यह एक संकेत है कि आप वर्तमान में उस कोड के बारे में चिंता कर रहे हैं जिसके बारे में आपको चिंता करने की आवश्यकता नहीं है।(असल में, कोड जो आपके कोर बिजनेस डोमेन को कार्यान्वित करता है उसे कार्यान्वित और डिजाइन किया जाना चाहिए, सहायक डोमेन में कोड को कार्यान्वित और डिजाइन किया जाना चाहिए, और अन्य सभी कोड को लागू या डिजाइन नहीं किया जाना चाहिए, लेकिन एक विक्रेता से खरीदा जाना चाहिए, जहां क्या आप खरीद रहे हैं उनके मुख्य व्यवसाय डोमेन है। [कृपया व्याख्या "खरीदने" और "विक्रेता" उदारतापूर्वक। समुदाय से विकसित फ्री सॉफ्टवेयर ठीक है।])

ऊपर # 3 के बारे में, यदि आप किसी अन्य में बताया गया टिप्पणी करें कि आप वर्तमान में एक पेड़ डेटा संरचना को लागू करने पर काम कर रहे हैं। जब तक आपकी कंपनी पेड़ डेटा संरचनाओं को बेचने के व्यवसाय में नहीं है, यह आपके मूल डोमेन का हिस्सा नहीं है। और कारण है कि आपको अच्छे नाम खोजने में परेशानी हो सकती है कि आप अपने मूल डोमेन के बाहर काम कर रहे हैं। अब, "पेड़ डेटा संरचनाओं को बेचने" बेवकूफ लग सकता है, लेकिन वहां वास्तव में कंपनियां हैं जो ऐसा करती हैं। उदाहरण के लिए, माइक्रोसॉफ्ट के डेवलपर डिवीजन के अंदर बीसीएल टीम: वे वास्तव में बेचते हैं (अच्छी तरह से, "बिक्री" की कुछ परिभाषाओं के लिए, वैसे भी) .NET फ्रेमवर्क के बेस क्लास लाइब्रेरीज़, जिनमें पेड़ डेटा संरचनाएं शामिल हैं। लेकिन ध्यान दें कि उदाहरण के लिए माइक्रोसॉफ्ट की सी ++ कंपाइलर टीम वास्तव में (सचमुच) अपने एसटीएल को तीसरे पक्ष के विक्रेता से खरीदती है - वे समझते हैं कि उनका मूल डोमेन कंपाइलर्स लिख रहा है, और वे पुस्तकालयों के लेखन को एक कंपनी को छोड़ देते हैं जो एसटीएल लिखने पर विचार करता है उनके कोर डोमेन। , पेड़ डेटा संरचनाओं की बिक्री है (और वास्तव में, AFAIK, कि कंपनी कुछ भी नहीं लेकिन लिखने एसटीएल कार्यान्वयन बेचने करता है और। यही कारण है कि उनका एकमात्र उत्पाद है।)

यदि फिर भी, अपने मूल डोमेन है, तो नाम आप सूचीबद्ध हैं बस ठीक। वे नाम हैं जो विषय विशेषज्ञ विशेषज्ञ (प्रोग्रामर, इस मामले में) पेड़ डेटा संरचनाओं के डोमेन के बारे में बात करते समय उपयोग करते हैं।

Answer 2

जवाब देना मुश्किल है। मैं उन्हें इसलिए ढूंढता हूं क्योंकि वे 'फिट' लगते हैं।

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

मैं 'यादगार', केवल 'सटीक' होने के बारे में बहुत चिंतित नहीं हूं।

मुझे कुछ नाम देने के बारे में जोर से सोचने के लिए बैठने के लिए जाना जाता है। अपना समय लें, और सुनिश्चित करें कि आप नाम से वाकई खुश हैं। सामान्य/सरल शब्दों का उपयोग करने से डरो मत।

Answer 3

'रूपक' का उपयोग करना चुस्त (और पैटर्न) साहित्य में एक आम विषय है।

'बच्चे' (आपके प्रश्न में) एक रूपक का एक उदाहरण है जिसका व्यापक रूप से उपयोग किया जाता है और अच्छे कारणों से।

तो, मैं रूपकों के उपयोग को प्रोत्साहित करता हूं, बशर्ते वे लागू हों और कल्पना का विस्तार न करें।

रूपक कंप्यूटिंग में हर जगह हैं। फाइलों से लेकर बग्स तक पॉइंटर्स तक स्ट्रीम ... आप उनसे नहीं बच सकते हैं।

Answer 4

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

Answer 5

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

Answer 6

मेरा मानना ​​है कि उद्देश्य के लिए मानकीकरण और संचार के, डिजाइन पैटर्न के लिए एक ही मामले में, एक सामान्य vocab का उपयोग करना अच्छा है। मुझे एक प्रोग्रामर के साथ समस्या है जो अपनी शर्तों का आविष्कार करता रहता है और मुझे उसे समझने में परेशानी होती है। (उन्होंने 'स्क्रिप्टिंग' या 'एफसीएफएस प्रक्रिया' के बजाय 'इवेंट ऑर्केस्ट्रेटिंग' शब्द का उपयोग करना जारी रखा। हालांकि रचनात्मकता के लिए कुडोस!)

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

Answer 7

कई भाषाएं और कोडिंग शैलियों वर्णनात्मक उपसर्गों के सभी प्रकारों का उपयोग करना पसंद करती हैं। PHP में कोई स्पष्ट प्रकार नहीं हैं, इसलिए इससे बहुत मदद मिल सकती है। इसके बजाय

$isAvailable = true; 

करने का कोशिश

$bool_isAvailable = true; 

यह बेशक एक दर्द है, लेकिन आम तौर पर अच्छी तरह से समय के लायक।

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

$leftNode->properties < $leftTreeNode->arrayOfNodeProperties; 

refactor करने के लिए और अगर सब कुछ विफल हो। क्यों एक ठोस सितारा युद्ध थीमाधारित कार्यक्रम पर वापस नहीं आते हैं।

$luke->lightsaber($darth[$ewoks]); 

और अंत में, कॉलेज में मैं अपने वर्गों मेरी प्रोफेसर के नाम पर रखा है, और फिर मेरी कक्षा तरीकों सब बातों मैं उस झटका करने के लिए करना चाहता था।

$Kube->canEat($myShorts, $withKetchup); 

Answer 8

मुझे लगता है कि नोड, बच्चे और संपत्ति महान नाम हैं। मैं पहले से ही सिर्फ अपने "नरम" नाम से, अपनी कक्षाओं के बारे में निम्नलिखित अनुमान लगा सकते हैं:

• नोड - इस चर से संबंधित नोड्स की एक सूची रखता है - इस वर्ग वस्तुओं
• बच्चों का ग्राफ का हिस्सा है नोड युक्त

मुझे नहीं लगता कि "नोड" या तो अस्पष्ट या सामान्य है, और यदि आप एक सामान्य डेटा संरचना कोडिंग कर रहे हैं, तो संभवतः सामान्य नाम होना ठीक है! (ऐसा कहा जा रहा है कि, यदि आप एक पेड़ को कोड कर रहे हैं, तो आप ट्रीनोड जैसे कुछ का उपयोग कर सकते हैं ताकि नोड एक पेड़ का हिस्सा हो।) एक तरीका है कि आप डेवलपर्स का जीवन बना सकते हैं जो आपके एपीआई का उपयोग आसान करेंगे पुस्तकालयों में आपके मंच के निर्माण के नामकरण सम्मेलन। यदि हर कोई नोड को नोड कहता है, और एक इटरेटर एक इटरेटर होता है, तो यह जीवन को आसान बनाता है।