क्या लघु चर नामों का बहाना है?

Question

यह उस कोडबेस के साथ एक बड़ी हताशा बन गया है जिसमें मैं वर्तमान में काम कर रहा हूं; हमारे कई चर नाम छोटे और अवांछनीय हैं। मैं प्रोजेक्ट पर एकमात्र डेवलपर रह गया हूं, और उनमें से अधिकांश के रूप में प्रलेखन नहीं है, इसलिए मुझे जो प्रतिनिधित्व करते हैं उसे ट्रैक करने के लिए अतिरिक्त समय बिताना होगा।

उदाहरण के लिए, मैं कुछ कोड पर पढ़ रहा था जो एक ऑप्टिकल सतह की परिभाषा को अद्यतन करता है। प्रारंभ में निर्धारित चर इस प्रकार थे:

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

शायद यह सिर्फ मेरे लिए है, लेकिन इसने मुझे अनिवार्य रूप से कुछ भी नहीं बताया कि वे क्या प्रतिनिधित्व करते हैं, जिसने कोड को समझना और कठिन बना दिया है। मुझे केवल इतना पता था कि यह एक विशिष्ट तालिका से कहीं विशिष्ट पंक्ति को पार करने वाला चर था। कुछ खोज के बाद, मुझे पता चला कि उनका क्या मतलब है:

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

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

Comments

यह मुझे प्रतीत होता है कि उस विशिष्ट मामले में, वे चर नाम हैं जिन्हें एक लंबे गणित सूत्र से सीधे कॉपी किया जाता है।

— डेव नी

केवल एक ही बहाना मैं स्वीकार करूंगा "मेरे सहकर्मी ने बताया कि कोड की समीक्षा करने के बाद यह ठीक है"

— gnat

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

— रेक्स केर

कोई भी पहचानकर्ता जिसे गधा काँग के नाम पर अनुमोदित किया गया है dK = conic constant:।

— थॉमस एडिंग

इसके विपरीत, कोई पूछ सकता है कि क्या डोमेन क्षेत्र की अज्ञानता उसके सम्मेलनों की उपेक्षा करना उचित है। अंत में, यह संदर्भ पर निर्भर करता है।

— डेनियल सी। सोबरल

Answer 1

ऐसा लगता है कि ये चर नाम उन संक्षिप्तीकरणों पर आधारित हैं जिनकी अपेक्षा आप एक भौतिकी पाठ्यपुस्तक में कर सकते हैं जो विभिन्न प्रकाशिकी समस्याओं पर काम कर रही है। यह उन स्थितियों में से एक है जहां छोटे चर नाम अक्सर चर नामों के लिए बेहतर होते हैं। यदि आपके पास भौतिक विज्ञानी (या ऐसे लोग हैं जो हाथ से बाहर समीकरणों को काम करने के आदी हैं) जो कि रिन, राउत, आदि जैसे सामान्य संक्षिप्ताक्षर का उपयोग करने के आदी हैं, तो कोड उन क्लीयर से अधिक स्पष्ट होगा, जितना कि यह लंबे चर नामों के साथ होगा। यह सुनिश्चित करने के लिए कोड के साथ कागजात और पाठ्यपुस्तकों के फॉर्मूलों की तुलना करना भी बहुत आसान बनाता है ताकि कोड वास्तव में गणनाओं को ठीक से कर सके।

प्रकाशिकी से परिचित कोई भी तुरंत रिन जैसी चीज को आंतरिक त्रिज्या के रूप में पहचान लेगा (भौतिकी पेपर में, inएक सबस्क्रिप्ट के रूप में प्रस्तुत किया जाएगा), बाहरी त्रिज्या के रूप में रूट, आदि। हालांकि वे लगभग निश्चित रूप से मानसिक रूप से कुछ अनुवाद करने में सक्षम होंगे। की तरह innerRadiusअधिक परिचित नामकरण के, ऐसा करने से कोड कम उस व्यक्ति को स्पष्ट करना होगा। यह उन मामलों को और अधिक कठिन बना देता है जहां एक परिचित सूत्र को गलत तरीके से कोडित किया गया था और इससे समीकरणों को कोड में और उन समीकरणों से अनुवाद करना अधिक कठिन हो जाएगा जो उन्हें एक पेपर या एक पाठ्यपुस्तक में मिलेंगे।

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

Comments

और अगर कर्मचारियों पर कोई भौतिक विज्ञानी या गणितज्ञ नहीं हैं? कोड अनिवार्य रूप से मेरे लिए छोड़ दिया गया था। यह काफी हद तक अनिर्दिष्ट है। क्या वर्णनात्मक नामों को पढ़ना अधिक कठिन होगा ?

— KChaloux

+1 एक प्रोग्रामर से यह अपेक्षा करना अनुचित नहीं है कि वह जिस डोमेन में काम कर रहा है, उसे समझने के लिए। दूसरी ओर, गणितीय कार्यों में, चर को आमतौर पर एक सुविधाजनक स्थान पर परिभाषित किया जाता है। इस तरह के कोड में मैं लंबी टिप्पणी दिखाते हुए एक प्रमुख टिप्पणी की उम्मीद करूंगा।

— कार्ल बेवफेल्ट्ट

+1: आप जो मूल रूप से कह रहे हैं, वह यह है कि एक प्रोग्रामर जो डोमेन को समझ रहा है, वह चर नामों को समझेगा। कई प्रोजेक्ट्स में वैसा ही होने जा रहा है, यहां तक ​​कि लंबे वैरिएबल नामों से भी। जैसे। एक columnसैन्य रणनीति खेल में नामित एक चर बहुत संभावना है कि यह चार्टिंग सॉफ़्टवेयर में होने वाली तुलना में कुछ अलग है।

— स्टीवन एवर्स

चिकित्सा प्रोग्रामिंग में आपको अक्सर ऐसे शब्द मिलेंगे जो प्रोग्रामिंग क्षेत्र में बने रहते हैं। नेत्र विज्ञान के उदाहरण के लिए आप OU, OD और OS देखेंगे। ये निरूपित करते हैं कि कौन सी आंख, उदाहरण के लिए ouSphere दाईं आंख के लिए एक चश्मा पर्चे के 'गोले' घटक को संदर्भित कर सकती है। यदि आप उस व्यावसायिक डोमेन को समझते हैं, जिसके लिए आप प्रोग्रामिंग कर रहे हैं, तो आप एक बेहतर प्रोग्रामर होंगे।

— बिल

+1 उन लघु नामों को नोट करने के लिए जो कागजात और ग्रंथों से समीकरणों और सूत्रों में मेल खाते हैं। जब मैं ऐसा करता हूं, तो मैं उन टिप्पणियों को शामिल करता हूं जहां मूल संदर्भ सामग्री ढूंढनी है।

— जे एलिस्टन

Answer 2

छोटे जीवनकाल वाले चर को शीघ्र ही नाम दिया जाना चाहिए। एक उदाहरण के रूप में, आप नहीं लिखते हैं for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { ...। इसके बजाय, आप उपयोग करते हैं for(int i ...।

अंगूठे के सामान्य नियम में यह कहा जा सकता है कि चर का दायरा जितना छोटा होगा उतना छोटा नाम होना चाहिए। लूप काउंटर अक्सर केवल एक अक्षर होते हैं, कहते हैं i, jऔर k। स्थानीय चर की तरह कुछ कर रहे हैं baseया fromऔर to। उदाहरण के लिए, वैश्विक चर कुछ अधिक विस्तृत हैं EntityTablePointer।

शायद आपके साथ काम करने वाले कोडबेस के साथ इस तरह के नियम का पालन नहीं किया जा रहा है। यह कुछ refactoring हालांकि करने के लिए एक अच्छा कारण है!

Comments

सरणी सूचकांकों के लिए i, j और k कम से कम फोरट्रान के लिए एक परंपरा का प्रतिनिधित्व करते हैं। कोई भी स्वाभिमानी प्रोग्रामर इस सम्मेलन से परिचित होगा।

— डोमिनिक क्रोनिन

मैं आमतौर पर नहीं लिखते i, j, k, मैं की तरह कुछ लिखने personPosक्योंकि तब मैं नहीं भूल जाएगा कि मैं क्या पर पुनरावृत्ति कर रहा हूँ और क्या सूचकांक प्रतिनिधित्व करता है।

— माल्कम

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

— ओलेग वी। वोल्कोव

काउंटर एक संज्ञा या एक विशेषण है। गिनती एक संज्ञा या एक क्रिया है। बेशक, मैं अभी भी कुछ फोन नहीं होगा arrayCounter, मैं का उपयोग करें personIndexया rowया जो कुछ भी बताया कि मैं कम से देख रहा हूँ।

— वेन वर्नर

जब मैं एक ही लूप कर रहा हूं, तो मैं उपयोग करता हूं i। लेकिन जैसे ही मैं एक नेस्टेड लूप में संक्रमण करता हूं, मैं iनामकरण को छोड़ देता हूं । इसका कारण यह है क्योंकि मैं वास्तव में ट्रैक करना चाहता हूं कि किस लूप चर के साथ काम किया जा रहा है, और iबनाम jघने कोड में काफी धोखा हो सकता है। इसे और अधिक पठनीय बनाना, और अधिक व्हाट्सएप को जोड़ना, मेरे लिए स्वाभाविक रूप से आवश्यक है।

— 18

Answer 3

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

कोड केवल समस्या-डोमेन परिचितता मानता है।

यह ठीक है, क्योंकि समस्या-डोमेन परिचित को कोड को समझने और बनाए रखने के लिए आवश्यक है, विशेष रूप से किसी ऐसे व्यक्ति की भूमिका में जो इसे "मालिक" करता है, इसलिए यह आपको नाम प्राप्त करने के बजाय परिचित नाम प्राप्त करने की अनुमति देता है।

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

Comments

अंत में इस तरह से कुछ के साथ जा रहा है।

— KChaloux

ये गलत है। लोगों को अधिक समय "सीखने" के लिए मजबूर करने के लिए आपके कोड को पढ़ने के लिए कठिन बनाने का कोई कारण नहीं है। आप सिखा नहीं रहे हैं, आप बस लोगों को धीमा कर रहे हैं। इसके अलावा, वस्तुतः कोड का एक भी मालिक हमेशा के लिए नहीं होता है। आप अल्पदर्शी और स्वार्थी हो रहे हैं।

— xaxxon

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

— कज़

Answer 4

कुछ चरों के लिए जो समस्या डोमेन में अच्छी तरह से जाना जाता है - जैसे आपके यहाँ मामला है - उलट चर नाम उचित हैं। मैं एक खेल पर काम कर रहा हूँ, तो मैं अपने खेल संस्थाओं स्थिति चर करना चाहते हैं xऔर y, नहीं horizontalPositionऔर verticalPosition। इसी तरह पाश काउंटर अनुक्रमण से परे किसी भी अर्थ विज्ञान की जरूरत नहीं है कि, मैं देखने की उम्मीद i, j, k।

Comments

मेरा तर्क है कि cv, din, और dout तुरंत स्पष्ट नहीं हैं (हालांकि स्पष्ट रूप से वे विशिष्ट क्षेत्रों में स्थापित हैं)। मैं एक्स और वाई के बारे में बहस नहीं करूंगा, यह देखते हुए कि कार्टेशियन निर्देशांक किसी भी संख्या में फ़ील्ड के लिए लागू होते हैं, और सभी को मध्य और उच्च विद्यालय में पढ़ाया जाता है।

— KChaloux

और xऔर y, जबकि आम, जैसी निहित महत्वपूर्ण पहलुओं ले नहीं है जहां में मूल।

— रॉस पैटरसन

@RossPatterson: हालाँकि, ऐसे कई संदर्भ हैं जहाँ यह महत्वपूर्ण नहीं है। उदाहरण के लिए, एक लूप पर विचार करें जैसे for (x,y) in list_of_coordinates: print x,y: कोड को समझने की कोशिश करते समय मूल रूप से कोई फर्क नहीं पड़ता।

— ब्रायन ओकले

Answer 5

"क्लीन कोड" की रिकॉर्डिंग:

परिवर्तनीय नाम चाहिए:

• आशय प्रकट करना
• विघटन से बचें
• सार्थक भेद करो
• उच्चारण योग्य हो
• खोजा जा सकता है

अपवाद i,j,k,m,nछोरों के लिए इस्तेमाल की जाने वाली कहावत है।

चर नाम, सही, शिकायत ऊपर के कुछ भी नहीं के बारे में। वे नाम बुरे नाम हैं।

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

यह नाम बेहतर हैं:

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

एक टिप्पणीकार का कहना है कि यह लंबे चर नामों के साथ बहुत जटिल होगा:

लघु चर नाम इसे सरल भी नहीं बनाते हैं:

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

जवाब लंबे नाम और मध्यवर्ती परिणाम है जब तक आप इसे अंत में प्राप्त नहीं करते हैं:

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

Comments

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

— MarkJ

@ मर्कज आप सही कह रहे हैं।

— ट्यूलेंस कोर्डोवा

इंटरमीडिएट परिणामों में प्रोग्रामिंग त्रुटियों को कम करने और अलग करने का अतिरिक्त लाभ है। हमारा दिमाग एक समय में केवल सूचना के इतने सारे टुकड़ों को संसाधित कर सकता है, और कुछ में त्रुटि को दूर करना मुश्किल है जैसेfnZR = (r^2/fnR(1+Math.sqrt((1+k)) * (r^2/R^2))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

— पलक

यह इतना कठिन नहीं है अगर वह आपकी रोटी और मक्खन है।

— राडु

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

— स्लीवेटमैन

Answer 6

विरासत कोड में चर का नाम नहीं बदलने के दो अच्छे कारण हैं।

(1) जब तक आप एक स्वचालित रीफैक्टरिंग उपकरण का उपयोग नहीं कर रहे हैं, तब तक बग को शुरू करने की संभावना अधिक है। इसलिए, "अगर यह टूटा नहीं है, तो इसे ठीक न करें"

(2) आप पिछले संस्करणों के साथ वर्तमान संस्करणों की तुलना करेंगे, ताकि यह देखा जा सके कि क्या बदल गया है, असंभव है। इससे भविष्य में कोड का रखरखाव और कठिन हो जाएगा।

Comments

बिल्कुल सही है, लेकिन समझ की कमी का खतरा बहुत अधिक है।

— रॉस पैटरसन

यदि आपके उपकरण आपके द्वारा बताई गई सरल समस्याओं को संभाल नहीं सकते हैं तो आपके पास बड़ी समस्याएं हैं।

— एंडो यूकोड

उत्तर (1) उचित स्वचालित परीक्षण कवरेज और साने एनकैप्सुलेशन, (2) संस्करण नियंत्रण के साथ प्रवीणता।

— अदामंतिश

Answer 7

क्या इस तरह से चर नाम रखने का एक अच्छा कारण है, या क्या मैं उन्हें अधिक वर्णनात्मक नामों को अपडेट करने में उचित हूं, क्योंकि मैं उनके आसपास आता हूं?

छोटे नामों का उपयोग करने का कारण यह है कि अगर मूल प्रोग्रामर को उनके साथ काम करना आसान लगता है। संभवत: उनके पास यह अधिकार है कि वे ऐसा ही हो, और आपके पास वैसी ही व्यक्तिगत प्राथमिकताएं न हों, जैसी अधिकार आपके पास हैं। व्यक्तिगत रूप से, मुझे लगता है ...

dDin better than dDinnerAperture
dDout better than dDouterAperture

... अगर मैं उन्हें लंबे, जटिल गणनाओं में उपयोग कर रहा था। गणित की अभिव्यक्ति जितनी छोटी होती है, उतनी ही आसानी से एक ही बार में पूरी बात देख लेते हैं। हालांकि अगर ऐसा था, तो वे dIn और dOut के रूप में बेहतर हो सकते हैं, इसलिए एक दोहरावदार डी नहीं था जिससे एक आसान टाइपो बन सके।

दूसरी ओर, यदि आपको इसके साथ काम करना कठिन लगता है, तो अपने आप को खटखटाएं और फिर नाम बदलकर उनके लंबे रूप में ले जाएं। खासकर यदि आप उस कोड के लिए जिम्मेदार हैं।

Comments

बहुत कम से कम मैं निश्चित रूप से सिस्टम हंगेरियन नोटेशन से छुटकारा पा रहा हूं ...

— 21

अग्रणी dहंगरी है? मैंने सोचा कि यह पथरी के रूप में था dx^2/dx = 2x।

— शान्नोन सेवेरेंस

अगर मैंने dDinnerApertureखुद देखा , तो मैं इसे "डिनर एपर्चर" के रूप में पढ़ूंगा, और आश्चर्य होगा कि क्या यह "आपका मुंह" कहने का एक अजीब तरीका है। "कैपिटल लेटर के बाद लोअर-केस वर्ड) स्टाइल का प्रशंसक कभी नहीं रहा। बहुत भ्रमित करने वाला।

— डारेल हॉफमैन

+1 यह जवाब है। लंबे गणित के फार्मूले छोटे चर नामों के साथ पढ़ने में बहुत आसान होते हैं। ये चर शायद कोड में गणितीय सूत्रों में उपयोग किए जाते हैं। लघु चर नामों के साथ गणितीय सूत्र पढ़ना बहुत आसान है। मैं अपने अधिकांश कोड में लंबे चर नामों का उपयोग करता हूं, लेकिन गणित लघु चर नामों के साथ बेहतर है। यादृच्छिक उदाहरण: विचार करें कि यह लंबे चर नामों के साथ कितना लंबा होगा।

— MarkJ

@ShannonSeverance मैं आपसे सहमत हूँ। इंजीनियरिंग की पृष्ठभूमि से आने वाले, गणितीय अर्थों में चर नामों का उपयोग करते समय डी को निश्चित रूप से कैलकुलस के लिए आरक्षित किया जाना चाहिए (जैसा कि अक्सर यहां बताया गया है)।

— कोडमोंकी

Answer 8

आम तौर पर, मेरा मानना ​​है कि इसके लिए नियम यह होना चाहिए कि आप अत्यंत छोटे परिवर्तनशील नामों का उपयोग कर सकते हैं, जहाँ आप जानते हैं कि जो लोग आपके विशेष कोड के "कला में कुशल" हैं, वे उस चर नाम के संदर्भ को तुरंत समझ जाएंगे। (आपके पास वैसे भी इस मामले के अपवाद के लिए टिप्पणियां हैं), और यह कि चर का स्थानीयकृत उपयोग कैसे किया जाता है, इसके संदर्भ के आधार पर आसानी से समझा जा सकता है।

इस पर विस्तार करने के लिए, इसका मतलब है कि आपको अपने चर नामों को बाधित करने के लिए अपने रास्ते से बाहर नहीं जाना चाहिए, लेकिन, आप अपने चर नामों के लिए संक्षिप्त रूप का उपयोग कर सकते हैं, जहां आप जानते हैं कि केवल वे लोग ही समझते हैं जो आपके कोड की अंतर्निहित अवधारणा को समझते हैं। वैसे भी इसे पढ़ने के लिए।

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

इस सुंदर वर्ग को बनाने के लिए , मैंने शायद आधा दर्जन संसाधनों, खगोल विज्ञान पंचांग, ​​और अन्य भाषाओं के स्निपेट, (PHP, जावा, सी आदि) का उल्लेख किया।

लगभग इन सभी में, उन्होंने समान समरूप संक्षिप्तीकरणों का उपयोग किया, जिनके चेहरे पर इसका मतलब पूर्ण रूप से कुछ भी नहीं था।

K, T, EPS, deltaPsi, eot, LM,RA

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

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, longitudeMean, rightAscension।

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

Answer 9

बिलकुल है; अक्सर एक लघु चर नाम वह सब होता है जो आवश्यक होता है।

मेरे मामले में, मैं अपने वरिष्ठ रोबोटिक कक्षा में वेपॉइंट नेविगेशन कर रहा हूँ, और हम KISS-सी में हमारे रोबोट कार्यक्रम। हमें वर्तमान और गंतव्य (x, y) सह-निर्देशांक, (x, y) दूरियां, वर्तमान और गंतव्य शीर्षकों के साथ-साथ बारी कोणों के लिए चर की आवश्यकता है।

विशेष रूप से x और y को-ऑर्डिनेट्स के मामले में, एक लंबा वैरिएबल नाम पूरी तरह से अनावश्यक है, और एक्ससी (करंट x), yD (डेस्टिनेशन y), और pD (डेस्टिनेशन फी) जैसे नाम, पर्याप्त और समझने में आसान हैं इस मामले में।

आप तर्क दे सकते हैं कि ये प्रोग्रामर प्रोटोकॉल के रूप में 'वर्णनात्मक चर नाम' नहीं हैं, लेकिन चूंकि नाम एक साधारण कोड (d = गंतव्य, c = वर्तमान) पर आधारित हैं, इसलिए शुरुआत में एक बहुत ही सरल टिप्पणी में सारा विवरण है उन्हें ज़रूरत है।

Answer 10

क्या इस तरह से चर नाम रखने का एक अच्छा कारण है, या क्या मैं उन्हें अधिक वर्णनात्मक नामों को अपडेट करने में उचित हूं, क्योंकि मैं उनके आसपास आता हूं?

आमतौर पर, जटिल एल्गोरिदम को मटलब (या समान भाषा) में लागू किया जाता है। मैंने जो देखा है, वह लोग केवल चर नाम को ले रहे हैं। इस तरह, कार्यान्वयन की तुलना करना सरल है।

अन्य सभी उत्तर लगभग सही हैं। ये संक्षिप्तीकरण गणित और भौतिकी में पाए जा सकते हैं, सिवाय इसके कि वे d(आपके उदाहरण के अनुसार) शुरू नहीं करते हैं । डी के साथ शुरू होने वाले चर को आमतौर पर भेदभाव का प्रतिनिधित्व करने के लिए नामित किया जाता है ।

सभी सामान्य कोडिंग गाइड्स वेरिएबल्स को नाम नहीं बता रहे हैं कि पहला अक्षर टाइपिंग का प्रतिनिधित्व करता है (जैसा कि आपके मामले में), क्योंकि सभी आधुनिक आईडीई में कोड ब्राउज़ करना इतना आसान है।

Comments

ठीक है, उस तत्व की परवाह किए बिना जो लोग खत्म हो गए थे दूर जा रहे थे। वहाँ एक आधा हंगेरियन हाफ नहीं सिज़ोफ्रेनिया कोडबेस में चल रहा है जिसे मैं अपडेट कर रहा हूं जैसा कि मुझे लगता है।

— KChaloux

Answer 11

मैं चर नामों के लिए एक कारण के बारे में सोच सकता हूं।

छोटे नाम छोटी आँख-अवधि का उपयोग करके पढ़ना आसान है, इसलिए एक छोटा ध्यान अवधि।

उदाहरण के लिए, एक बार जब मुझे इस तथ्य की आदत हो जाती है कि svdb का अर्थ है "डेटाबेस में सहेजें", स्रोत कोड को स्कैन करने की दर बेहतर हो जाती है क्योंकि मुझे केवल SaveToDatabase (14 वर्णों, चीज़ों को खराब करने) के बजाय 4 वर्णों को जल्दी से स्कैन करना पड़ता है अधिक जटिल ऑपरेशन नामों के लिए)। मैं कहता हूं "स्कैनिंग" नहीं "पढ़ना", क्योंकि यह स्रोत कोड का विश्लेषण करने का एक बड़ा हिस्सा लेता है।

जब स्रोत कोड की बड़ी मात्रा के माध्यम से स्कैनिंग, यह अच्छा प्रदर्शन लाभ प्रदान कर सकता है।

इसके अलावा, यह सिर्फ आलसी प्रोग्रामर को कोड लिखते समय इन छोटे नामों को टाइप करने में मदद करता है।

बेशक, इन सभी "शॉर्टहैंड्स" को स्रोत कोड में कुछ मानक स्थान में सूचीबद्ध किए जाने की उम्मीद है।

Comments

हम शब्दों को पात्रों के एक सेट के रूप में नहीं पढ़ते हैं, हम उन्हें आकृतियों के रूप में पढ़ते हैं और विवरणों को सशर्त रूप से हल करते हैं, जब एक-नज़र में विफलता विफल हो जाती है। जिस शब्द को पढ़ने में अधिक समय लगना चाहिए वह 4 वर्णों से कहीं अधिक है, और हम शब्द सीमा के रूप में परिवर्तनीय नाम शब्दों को तोड़ने के लिए मानसिक रूप से कैमलकेस और अन्य साधनों को संसाधित करने में सक्षम हैं। मुझे संदेह है कि एक रीडिंग टेस्ट यह दावा करेगा कि छोटे नाम पढ़ने की गति में सुधार करते हैं; इसके बजाय, पहचानने योग्य शब्दों को हटाने से, नए शब्द को आत्मसात करने तक गति में कमी आएगी (जिसे आप स्वयं इंगित करते हैं)।

— पलकहीनता

Answer 12

फ़्रेम करने के लिए जो @zxcdw ने कुछ अलग तरीके से कहा, और दृष्टिकोण के संदर्भ में उस पर विस्तृत करें:

फ़ंक्शंस शुद्ध , संक्षिप्त और कुछ कार्यक्षमता का एक सटीक एनकैप्सुलेशन होना चाहिए : ब्लैक बॉक्स लॉजिक , चाहे वह 40 साल से अछूता बैठा हो, यह उस कार्य को करना जारी रखेगा, जिसे इसके लिए डिज़ाइन किया गया था, क्योंकि इसका इंटरफ़ेस (इन और आउट) ध्वनि है, यहां तक ​​कि जैसा कि आप इसके कुछ भी नहीं जानते हैं।

यह उस तरह का कोड है, जिसे आप लिखना चाहते हैं: यह वह कोड है जो पिछले रहता है, और पोर्ट के लिए सरल है।

जहां आवश्यक हो, कोड को ठीक रखने के लिए अन्य (इनलाइन) फ़ंक्शन कॉलों के लिए फ़ंक्शन लिखें ।

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

Answer 13

परिवर्तनीय नाम कार्यक्रम की पठनीयता में मदद करने के लिए यथासंभव वर्णनात्मक होने चाहिए। आपने इसे स्वयं अनुभव किया: आपको यह पहचानने में बहुत परेशानी हुई कि खराब नामकरण के कारण कार्यक्रम ने क्या किया।

वर्णनात्मक नाम का उपयोग न करने का कोई अच्छा कारण नहीं है। यह आपकी मदद करेगा, और बाकी सभी जो प्रोजेक्ट पर काम करेंगे / करेंगे। वास्तव में छोटे नामों के लिए एक एकल मान्य उपयोग है: लूप काउंटर।

Comments

ध्यान दें कि int dummy_variable_for_for_loops;संभव के रूप में वर्णनात्मक है।

— काज

-1 क्योंकि यह जवाब भ्रामक है। पहले यह कहता है कि कोई अच्छा कारण नहीं है, फिर यह कहकर खत्म करता है कि वास्तव में, वहाँ हैं। इसका उत्तर बेहतर होगा यदि इसे स्वयं के विरोधाभास न करने के लिए दोहराया गया हो।

— ब्रायन ओकले

मुझे लगता है कि " आवश्यक के रूप में वर्णनात्मक" पढ़ने के लिए बदल जाएगा । यदि एक संक्षिप्त नाम चर के उद्देश्य को बताता है, तो संक्षिप्त नाम का उपयोग करना ठीक है ।

— मैक्सिमस मिनिमस

Answer 14

निश्चित रूप से यह क्या है / टिप्पणी के लिए हैं?

यदि असाइनमेंट में ऐसी टिप्पणियां हैं, जो वर्णनात्मक हैं, तो आपको दोनों दुनिया में सबसे अच्छा मिलता है: चर और किसी भी समीकरण का वर्णन आसानी से उनकी पाठ्य पुस्तक समकक्ष के साथ तुलनीय है।

Answer 15

इंटरफेस के लिए (जैसे, विधि हस्ताक्षर, फ़ंक्शन हस्ताक्षर) मैं पैरामीटर घोषणाओं को एनोटेट करके इसका समाधान करता हूं। C / C ++ के लिए यह .h फ़ाइल के साथ ही कार्यान्वयन के कोड को भी सजाता है।

मैं चर घोषणाओं के लिए ऐसा ही करता हूं, जहां चर का उपयोग संदर्भ में और नामकरण में स्पष्ट नहीं है। (यह उन भाषाओं में लागू होता है, जिनमें मजबूत टाइपिंग भी नहीं है।)

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

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

Answer 16

क्या अत्यधिक कम चर नामों का बहाना है?

पहली: ऊर्जा ई के लिए एक चर नामकरण इस तरह के ई के रूप में सूत्रों की गणना करते समय = mc2 है नहीं जरूरत से ज्यादा कम नामकरण। छोटे नामों के लिए एक तर्क के रूप में प्रतीकों का उपयोग करना मान्य नहीं है

यह सवाल मेरे लिए दिलचस्प था, और मैं केवल एक बहाना सोच सकता हूं और वह है पैसा।

उदाहरण के लिए कहें कि आप एक क्लाइंट के लिए जावास्क्रिप्ट वायरिंग कर रहे हैं, जो जानता है कि फ़ाइल को दूसरी बार कई बार डाउनलोड किया जाना है । यह सस्ता होगा और उपयोगकर्ताओं के अनुभव को बेहतर बना देगा यदि फ़ाइल (बाइट की संख्या में) यथासंभव छोटी है।

(उदाहरण को 'यथार्थवादी' बनाए रखने के लिए, आपको मिनिफ़ायर टूल का उपयोग करने की अनुमति नहीं दी गई थी, क्यों? सुरक्षा के मुद्दे, किसी बाहरी उपकरण को कोड आधार को छूने की अनुमति नहीं है।)

Comments

आपका उदाहरण अभी भी बहुत यथार्थवादी नहीं है।

— रादू

Answer 17

मुझे लगता है कि अन्य उत्तरों में हंगेरियन नोटेशन के उपयोग का उल्लेख नहीं है। यह लंबाई की बहस के लिए रूढ़िवादी है, लेकिन सामान्य रूप से नामकरण योजनाओं के लिए प्रासंगिक है।

double dR, dCV, dK, dDin, dDout, dRin, dRout

इन सभी चर की शुरुआत में "d" यह इंगित करने के लिए है कि वे युगल हैं; लेकिन भाषा वैसे भी इसे लागू कर रही है। इन नामों की थकावट के बावजूद, वे 50% तक बेमानी हैं !

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

ऐसी त्रुटियों को रोकने का एक अच्छा तरीका मजबूत प्रकारों का उपयोग करना है; हालाँकि, यदि हम डबल्स का उपयोग करने जा रहे हैं, तो एक अधिक उपयुक्त नामकरण योजना हो सकती है:

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

भाषा अभी भी हमें लिखने की अनुमति देगी K + lR, लेकिन अब नाम हमें संकेत देते हैं कि यह गलत हो सकता है।

यह सिस्टम हंगेरियन (आमतौर पर खराब) और ऐप्स हंगेरियन (संभवतः अच्छा) के बीच अंतर है

http://en.wikipedia.org/wiki/Hungarian_notation

Comments

वास्तव में, C ++ शिकायत कर सकती है कि K + lR क्या आप अपनी इकाइयों को ठीक से घोषित करते हैं। एसआई इकाइयों के साथ यह आयामी चैक और इकाई रूपांतरण कर सकता है। जोड़ना 3_feet + 2_meterकोई समस्या नहीं होनी चाहिए, जबकि 2_meter+1_secondएक संकलन-समय त्रुटि होनी चाहिए।

— MSALERS

@ दलाल यह बहुत अच्छा है; एक टेम्पलेट / मैक्रो दृष्टिकोण मेरे लिए नहीं हुआ था। फिर भी, "भाषा-अज्ञेयवादी" प्रश्न में, मैं इस समूह को "मजबूत प्रकार" छत्र के तहत सभी संकलन-समय इकाई जाँच करता हूँ, भले ही भाषा उन्हें "प्रकार"

— कहे

खाका, जरूरी है। आप मैक्रो में आवश्यक प्रकार पथरी नहीं कर सकते।

— MSalters

Answer 18

केवल इस मामले में जहां घसीट कम चर नाम आधुनिक सॉफ्टवेयर इंजीनियरिंग में स्वीकार्य हैं, जब वे एक स्क्रिप्ट में मौजूद हैं और है कि स्क्रिप्ट की प्रवाह क्षमता (एक नेटवर्क आम तौर पर अधिक) महत्वपूर्ण है। फिर भी, स्क्रिप्ट को स्रोत नियंत्रण में लंबे नामों के साथ रखें, और उत्पादन में स्क्रिप्ट को छोटा करें।

Comments

गणितीय संचालन करते समय क्या होगा जहां शर्तों को डोमेन में सामान्य ज्ञान माना जाता है? उदाहरण: ई = mc ^ 2 में "द्रव्यमान" के बजाय M का उपयोग करना

— एंडी हंट

@andyBursh - मैं वहाँ सावधान रहूँगा। प्रोग्रामर अक्सर अपने समस्या डोमेन में विशेषज्ञ (या यहां तक ​​कि सक्षम) नहीं होते हैं। उस ने कहा, इस तरह की बात ठीक हो सकती है, खासकर अगर प्रश्न में सूत्र के लिए उपयुक्त टिप्पणी लिंक हो; मैं इस परिदृश्य के बारे में भूल गया था।

— तेलस्टिन

@Telastyn - यदि आप मानते हैं कि प्रोग्रामर एक विशेषज्ञ नहीं है, हालांकि, यह अक्सर संक्षिप्त रूप ले लेता है जिसका अर्थ बहुत अच्छी तरह से परिभाषित अर्थ है और उन्हें लंबे नामों में बदलना है जो कम से कम कुछ अस्पष्ट हैं (अर्थात कोई स्थानीय चर नाम देने का फैसला करता है radiusजब यह आंतरिक त्रिज्या को संग्रहीत करता है तो यह समझ में नहीं आता कि इससे कहीं अधिक अस्पष्ट है Rin)। और फिर गैर-विशेषज्ञ डेवलपर को अपने अनूठे नामकरण और नामकरण के बीच अनुवाद करना होगा कि व्यापार हर बार समझता है कि समीकरणों से संबंधित चर्चा है।

— जस्टिन केव

लूप काउंटर के लिए "मैं" के बारे में क्या? या समन्वय के साथ काम करते समय "x" और "y"? या ऐसा वैरिएबल जिसका स्कोप केवल दो लाइनों का कोड है?

— ब्रायन ओकले

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

— MarkJ