हंगेरियन नोटेशन का उपयोग नहीं करने के लिए संघर्ष

Question

मैंने सिस्टम हंगेरियन के खिलाफ और तर्कों को देखा है । कुछ वर्षों से मैं एक ऐसी विरासत परियोजना पर काम कर रहा हूं, जो इस प्रणाली का उपयोग हर चर का नामकरण करके करती है, चर प्रकार के उपसर्ग के साथ कार्य करती है (जैसे नाम, intAge, btnSubmit इत्यादि) (मुझे पता है कि मूल हंगेरियन एप्स किस तरह के हैं चर, प्रकार नहीं)। मैं अपनी अगली परियोजना को इसे पूरी तरह से त्याग देना चाहता हूं, लेकिन मुझे इसका सहारा लिए बिना समान चीजों को नाम देना कठिन लगता है।

आइए कहते हैं कि मेरे पास ईमेल पते एकत्र करने और उन्हें डेटाबेस तालिका में संग्रहीत करने के लिए एक वेबफॉर्म है, और बटन जो फ़ंक्शन को कॉल करता है जो पते को डीबी पर बचाता है।

अगर मैं हंगेरियन स्टाइल नोटेशन का उपयोग कर रहा हूं, तो मैं बॉक्स txtEmailको बटन btnEmailऔर टेक्स्टबॉक्स में निहित मूल्य कह सकता हूं strEmail। फिर मैं storeEmail(strEmail)ईमेल को स्टोर करने के लिए एक फ़ंक्शन का उपयोग कर सकता हूं । मेरा यहाँ एक स्पष्ट सम्मेलन है, यह स्पष्ट है कि प्रत्येक चर क्या है।

इन चरों के नामकरण के लिए सबसे अच्छा अभ्यास क्या होगा

• हंगरी सिस्टम का सहारा लिए बिना,
• उन्हें लंबे समय तक या भ्रमित किए बिना
• और मेरे पूरे प्रोजेक्ट में उपयोग करने के लिए एक स्पष्ट सम्मेलन के साथ?

Comments

शायद आपके बाकी नामकरण परंपराओं, या आपके कार्यों के आकार के साथ कुछ गड़बड़ है, अगर आपको अद्वितीय नाम खोजने में परेशानी होती है।

आप किस तकनीक का उपयोग कर रहे हैं? ये उपसर्ग खुद को वेब प्रपत्रों के लिए उधार देने लगते हैं।

— स्टुपरयूसर

मैं ASP.NET (C # पीछे के साथ) का उपयोग कर रहा हूं

— भयभीत हूं

@delnan - क्या आप कृपया विस्तार से बता सकते हैं? फ़ंक्शन का आकार विशिष्ट रूप से नामकरण को आसान क्यों बनाता है?

— भयभीत

@fearofours: एक छोटे फ़ंक्शन को कम चर की आवश्यकता होती है, और कम चर का मतलब स्पष्ट रूप से कम चर संघर्ष होता है। यह निश्चित रूप से आप हर चर को सबसे छोटे संभव दायरे में रखते हैं।

Answer 1

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

आपके अन्य दो बिंदु एक विकल्प के बारे में पूछ रहे हैं। मुझे यकीन नहीं है कि आपको एक विकल्प की आवश्यकता है; हंगेरियन के बारे में अब लोकप्रिय होने की बात यह है कि इसका उपयोग उस प्रकार के डिस्केब करने के लिए किया जाता था जब प्रकार प्रणाली और उपकरण थोड़े थे, हम कहेंगे, कम सख्त। Ie यदि आप सी में प्रोग्राम कर रहे थे और टाइप का ट्रैक रखने के लिए इधर-उधर से गुजर रहे थे तो हंगेरियन का उपयोग कर रहे थे। अब, यदि आप C # या Java जैसी भाषा का उपयोग कर रहे हैं, तो आप पॉइंटर्स (या बहुत कम) का उपयोग नहीं करेंगे, इसलिए किसी भी प्रकार के हंगेरियन की आवश्यकता दूर हो जाएगी। इसके अलावा, आधुनिक आईडीई आपको मूल घोषणा को देखने के लिए वेरिएबल पर मँडराते हुए या कुछ शॉर्ट कट का उपयोग करते हुए बहुत आसानी से टाइप करते हैं। इसलिए, मुझे नहीं लगता कि आपको किसी भी प्रकार के अंकन की आवश्यकता है, बस चर का नाम क्या है यह करता है। यदि यह एक ईमेल पता है तो बस "ईमेल" या "उपयोग करें"

Comments

यह थोड़ा पेचीदा हो जाता है जब फॉर्म / पेज / विंडो / जो भी ईमेल के लिए एक बटन है, ईमेल के लिए एक टेक्स्ट बॉक्स, और शायद ईमेल के लिए एक और विजेट / नियंत्रण ...

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner जरूरी नहीं है। पाठ बॉक्स emailAddressInput हो सकता है जहां बटन ईमेल के रूप में हो।

— योनातन

@ जोनाथन: अच्छी बात है।

— FrustratedWithFormsDesigner

Answer 2

वेब फॉर्म / विंडोज फॉर्म / अन्य ग्राफिकल सामान के साथ काम करते समय, सिस्टम हंगेरियन का उपयोग करने के लिए समझ में आता है क्योंकि आपके पास ऐसे नियंत्रण हो सकते हैं जो बहुत कसकर एक साथ बंधे हों - उदाहरण के लिए, एक टेक्स्ट बॉक्स और एक लेबल जो एक साथ चलते हैं; आप उन्हें नाम दे सकते हैं txtEmailऔर lblEmailउन्हें अलग कर सकते हैं। मेरे अनुभव में, यह आम है और वास्तव में उपयोगी है।

लेकिन आपके कोड-पीछे में, इस तरह का नामकरण अनावश्यक है। यदि आपके पास stringईमेल को संग्रहित करने के लिए उपयोग किया जा रहा प्रकार का एक चर है , तो इसे नाम दें email। यदि, किसी कारण से, आप भ्रमित हो जाते हैं, तो अधिकांश IDE को आपको इस पर मंडराने और इसके प्रकार को देखने की अनुमति देनी चाहिए। (आदर्श रूप में, OO सामान में, यह किसी वस्तु का एक गुण हो सकता है, और user.Emailइससे भी अधिक स्पष्ट है।)

मुझे लगता है कि अगर आपके पास आपके कोड में घोषित एक से अधिक ऑब्जेक्ट है जो कि GUI नियंत्रण नहीं है जिसे सही नाम दिया जा सकता है email, तो कुछ आपके डिजाइन के साथ स्वाभाविक रूप से गलत है।

Comments

वास्तविक txt और lbl हंगेरियन नहीं हैं, txt सिर्फ पाठ के लिए संक्षिप्त है और लेबल के लिए lbl छोटा है, कोई कारण नहीं है कि केवल एक प्रपत्र पर पूरी लंबाई के शब्द जैसे कि EmailText और EmailLabel का उपयोग न करें। हंगेरियन प्रकार होगा, जो इन दोनों मामलों में एक स्ट्रिंग है।

— स्टीव

@ स्तेव हैग - नहीं, मैं खुद नियंत्रणों के बारे में बात कर रहा हूं। आपके पास txtEmail नामक "textbox" का एक ऑब्जेक्ट है, और lblEmail नामक "लेबल" का ऑब्जेक्ट है। न ही वे तार हैं। उनके पास स्ट्रिंग गुण हो सकते हैं , लेकिन वे स्वयं तार नहीं हैं।

— एंड्रयू अर्नोल्ड

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

— स्टीव

Answer 3

क्या एक चर "लंबे समय से अधिक" बनाता है?

इसके बजाय txtEmail, btnEmailआप इस्तेमाल कर सकते हैं UserEmailText, UserEmailButtonऔर AdminEmailText,AdminEmailButton

इसके साथ समस्या यह है कि आप महसूस करना शुरू कर सकते हैं कि चर लंबा होना शुरू होता है:

AdminEmailIsValid सीमा पर शुरू होता है कि मैं चर को कितनी देर तक रहने दूंगा।

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

class EmailForm
  var textBox, button, text
  function storeEmail()

फिर आप एक वर्ग के रूप में एक नए चर को इंस्टाल कर सकते हैं, और अपने डेटा तक पहुंचने के लिए उसी डॉट नोटेशन का उपयोग कर सकते हैं:

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

बेशक, यह उन भाषाओं की ओर लक्षित है जो OOP प्रतिमान का उपयोग करते हैं, लेकिन बहुप्रचलित वेब विकास भाषाएं ऑब्जेक्ट-ओरिएंटेड हैं, या ऑब्जेक्ट-ओरिएंटेड कोड (PHP, पायथन, C #, C ++, जावा, जावास्क्रिप्ट, एक्शनस्क्रिप्ट आदि) के लिए अनुमति देते हैं। )।

Comments

मैं txtEmail को UserEmailText का लाभ देखने में विफल रहा हूँ - आप इसे टाइप करने के बजाय केवल टाइप प्रत्यय लगा रहे हैं। मुझे पसंद है "यह वही है जो ओओपी के लिए डिज़ाइन किया गया है", हालांकि।

— डरपॉफ़्स

@fearoffours, OP ने अद्वितीय नामों के साथ एक समस्या होने की बात स्वीकार की, मैंने उस उदाहरण को दो समान चर ( UserEmailTextऔर AdminEmailTextविशेष रूप से) के बीच अंतर करने के वर्णनात्मक तरीके के रूप में जोड़ा । मैं आमतौर पर प्रत्यय टाइप करता हूं क्योंकि यह खुद को एक कक्षा में ले जाने के लिए उधार देता है UserEmailText-> UserEmail.text-> User.email.textकितना अमूर्तता / कार्यक्षमता के आधार पर आवश्यक है।

— zzzzBov

ठीक है, देखें कि आप वहाँ कहाँ से आ रहे हैं। प्रत्यय / वर्ग की तुलना के लिए +1। ओह, और मैं ओपी हूं!

— डरपॉफ्स

@fearoffours, lol whoops ...

— zzzzBov