लैम्ब्डा परिवर्तनीय नाम - संक्षिप्त नाम, या संक्षिप्त नाम नहीं?

Question

आमतौर पर, जब मैं लैम्ब्डा का उपयोग करता हूं, तो मैं केवल "ए, बी, सी, डी ..." का उपयोग चर नामों के रूप में करता हूं क्योंकि प्रकार आसानी से अनुमानित होते हैं, और मुझे पढ़ने के लिए आसान नाम मिलते हैं। यहाँ एक उदाहरण है:

var someEnumerable = GetSomeEnumerable(); 
var somethingElseList = someEnumerable.Select(a => a.SomeProperty) 
             .OrderBy(a => a.SomePropertyField); 
var someDictionary = somethingElseList.ToDictionary(a => new SomeClass(a.Prop1), 
                a => a); 

कुछ सवाल इस नामकरण, और लंबे समय नाम टाइप किया, इस तरह देखने के लिए पसंद करेंगे: जब तक

var someEnumerable = GetSomeEnumerable(); 
var somethingElseList = someEnumerable.Select(importantObj => importantObj.SomeProperty) 
             .OrderBy(objsInfo => objsInfo.SomePropertyField); 
var someDictionary = somethingElseList.ToDictionary(theInfoId => new SomeClass(theInfoId.Prop1), 
                theInfoId2 => theInfoId2); 

के बाद गुंजाइश तो संकीर्ण है (कोष्ठक के बीच), आप बेवकूफ हो रहे हैं और उन्हें घोंसले कर रहे हैं, मुझे छोटे नाम पढ़ने में आसान लगता है।

बेवकूफ नामकरण उदाहरणों में पकड़े बिना मैंने से ऊपर उपयोग किया, लैम्ब्डा परिवर्तनीय नामों पर आम सहमति क्या है? संक्षिप्त नाम के लिए, या संक्षिप्त नाम नहीं?

Answer 1

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

आईई:

myCollection.Where(person =>....); //non descriptive collection name 

myPeopleCollection.Where(p=>...); // descriptive collection name 

Answer 2

मैं एकल शब्द लेकिन सार्थक नामों का उपयोग करने का प्रयास करता हूं। तो मैं को "पी" के बजाय "व्यक्ति" का उपयोग करने के लिए करता हूं लेकिन "newAddedPerson" के लिए नहीं जाता।

यह रूप में अच्छी तरह क्वेरी भाव के लिए चला जाता है - मैं अच्छी तरह से त्वरित throwaway उदाहरण में इस का उल्लंघन हो सकता है, लेकिन मैं आम तौर पर नहीं चाहते:

from p in source 
where p.Age > 10 
select p.Name; 

मैं अब तक नहीं बल्कि

from person in source 
where person.Age > 10 
select person.Name; 

Answer 3

देखना चाहते हैं मुझे संक्षिप्त नाम पसंद है। मेरे पास हर व़क्त करने को यही काम है। मैं ज्यादातर lambdas में i, y, x का उपयोग करता हूं, लेकिन मैं एसक्यूएल में ए, बी, सी, डी का उपयोग करता हूं।

Answer 4

यह नामकरण 'चालू' आम सहमति 'के लिए एक सवाल पूछने के लिए बहुत कुछ मांग रहा है। :)

मैं मानता हूं कि 'एक अच्छे नाम का महत्व' नाम के दायरे के समान है।

from person in source ... 

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

from p in persons ... 

Answer 5

मैं कहना चाहता हूँ मैं सहमत BFree। वह, मेरे लिए, यह संदर्भ पर निर्भर करेगा, लेकिन मैं हमेशा इसे यथासंभव 'संक्षिप्त' बनाने की कोशिश करता हूं। नोटिस मैं संक्षेप में कहता हूं, और कम या छोटा नहीं।

यहाँ लिस्प बोली Clojure में दो उदाहरण है:

user=> (def names ["ryan" "bob" "tom" "tim"]) 
#'user/names 

user=> (filter (fn [name] (.startsWith name "t")) names) 
("tom" "tim") 

उन है कि लिस्प/Clojure पता नहीं है के लिए, मेरे लैम्ब्डा समारोह 'फिल्टर' के लिए तर्क है। वह है, "(एफएन [नाम] ....)"। मैंने यहां 'नाम' का उपयोग करना चुना क्योंकि यह छोटा है लेकिन वास्तव में वर्णन करता है कि मैं किसके साथ काम कर रहा हूं। हालांकि, मुझे लगता है कि 'ए', 'मैं', 'एक्स' इत्यादि उतना ही पठनीय होगा।

user=> (def odds (iterate (fn [n] (+ n 2)) 1)) 
#'user/odds 

user=> (take 5 odds) 
(1 3 5 7 9) 

यहां, मैं केवल 'संख्या' के लिए खड़े होने के लिए 'n' का उपयोग करता हूं। मुझे लगता है कि 'संख्या' भी ठीक रहेगी, लेकिन मेरे स्वाद के लिए थोड़ा सा वर्बोज़ है।

मैं निश्चित रूप से नाम 'नामऑफर्सन' या 'पिछलेऑड नम्बर' नामों का उपयोग नहीं करता। यह सिर्फ बहुत अधिक जानकारी है। मैं ज्यादातर समय अपने नामों से प्रकारों को रखने की कोशिश करता हूं, उदा। 'NameString'। मुझे उस तरह की चीजें मिलती हैं, ज्यादातर समय, अनिवार्य जानकारी होने के लिए।

व्यक्तिगत रूप से, मुझे लगता है कि इस तरह के अतिरिक्त वर्बोज़ नाम इस विचार से निकलते हैं कि यह कोड को दस्तावेज़ में मदद करता है। यह जावा/सी # जैसी भाषाओं में विशेष रूप से प्रचलित है। मुझे लगता है कि प्रोग्रामर की शैली के आधार पर, दोनों तरीकों से तर्क दिया जा सकता है। हालांकि, अधिक verbose नाम, कोड अधिक हो सकता है (भंगुर पढ़ें) कोड बन सकता है। यदि मेरा नाम बहुत विशिष्ट है, और यह अक्सर एक फ़ंक्शन बदलता है, तो संभावना है कि नाम को भी बहुत कुछ बदलना होगा। आखिरकार, DEV आलसी हो सकता है और आप एक ऐसे नाम से समाप्त हो जाएंगे जो वास्तव में वर्णन नहीं करता कि चर का उपयोग किस प्रकार किया जाता है। यह कोई समस्या नहीं है, अगर और केवल अगर प्रोग्रामर मान नहीं लेता है तो सही है। अनुमोदित, यह शायद संकलन के दौरान जल्दी से पता लगाया जाएगा (क्योंकि प्रोग्रामर दो तारों या ऐसी कुछ चीज़ों को विभाजित करने का प्रयास करेगा), लेकिन यह बड़ी परियोजनाओं में बर्बाद समय और भ्रम पैदा कर सकता है।

मैं स्क्रीन रीयल-एस्टेट की वजह से एकता के लिए भी बहस करता हूं। मैं अभी भी अपनी पंक्तियों को 80 कॉलम चौड़े पर लपेटने की कोशिश करता हूं, और यह मुश्किल है जब 'myVaraibleNameIsAsLongAsaparagraph'।

आखिरकार, मुझे लगता है कि यह हमेशा समझौता करने के लिए नीचे आ जाएगा। इसलिए उन्हें 'ए' पसंद नहीं है, लेकिन शायद वे इस बात से सहमत हो सकते हैं कि आपको 'व्यक्ति' या 'संख्या' जैसे एक शब्द के लिए प्रयास करना चाहिए, और उस भयानक ऊंट के मामले से बचें।

पुस्तक के लिए खेद है।

Answer 6

मैं एक, दो या तीन अक्षरों के साथ जाता हूं, जो प्रश्न में वस्तु का संक्षेप प्रस्तुत करता है।

Persons.Where(p => ...) 
AnalysisCode.Where(ac => ...) 

Answer 7

एक सामान्य नियम के रूप में, मुझे लगता है कि आप चर/ऑब्जेक्ट/विधि नामों के साथ अधिक स्पष्ट हैं। चूंकि हम अक्सर अपना अधिकांश समय अन्य लोगों के कोड को पढ़ने में बिताते हैं, जितना तेज़ी से हम समझते हैं कि आप सिंटैक्स से और तर्क पर अपना ध्यान केंद्रित कर सकते हैं। इंटेलिसेन्स और इस तरह के साथ इन दिनों, जब भी संभव हो, स्पष्टता के पक्ष में गलती करना वास्तव में बोझ नहीं है।

Answer 8

मैं @ जॉनी वेई से सहमत हूं; अपने चर नाम दें - उसी कारण से आप उन्हें किसी अन्य कोड में नाम दें! कोड की "इन-लाइन" प्रकृति की वजह से स्पष्टता से दूर इस पूर्वाग्रह को समझें। पठनीयता महत्वपूर्ण है - सामान पर "होवर" करने के लिए एक नज़र/डब्ल्यू/आउट पर; अन्यथा, आप यह भी कह सकते हैं कि कोई परिवर्तनीय आवश्यकता उचित रूप से नामित नहीं की जानी चाहिए। अगर कुछ "Enuerable" के साथ प्रयोग किया जाता है, तो शायद थोड़ा सा छूट, लेकिन फिर भी देखना अच्छा लगता है (फिर एक नज़र में) कोड क्या कर रहा है। यदि चर प्रकार का अनुमान कक्षा या कुछ में पारित कुछ सामान्य प्रकार पर निर्भर है, तो इसे नाम दें। सभी कोड को वाक्य की तरह पढ़ाएं; कंप्यूटर हमें ("मानवकरण") के अनुकूल होने के लिए माना जाता है, न कि दूसरी तरफ जहां हम कंप्यूटर की तरह अभिनय करना शुरू करते हैं और क्रिप्टिक प्राप्त करते हैं क्योंकि हम तकनीकी geeks जैसे स्मार्ट/अधिक महसूस करते हैं/महसूस करते हैं (प्रलोभन वहां है, मैं kno!)। एक स्पष्ट नाम टाइप करना आसान है और आपके पास अभी भी नामांकित विधियों में किए गए सभी इंटेलिजेंस/वाक्य समापन विकल्प हैं। इसके अलावा, लैम्बडास के मामले में घूमने से आपको हमेशा var (डीबग के दौरान निराशाजनक) पर जानकारी नहीं मिलती है, इसलिए यह देखने के लिए अच्छा है कि "स्पष्ट/प्रतिनिधि पर्याप्त" नामकरण, नए देवताओं के लिए esp जो सभी मानसिक जिमनास्टिक के माध्यम से हैं कथन संदर्भ (जो भी गुप्त हो सकता है) को पार करके प्रकारों का अनुमान लगाने में सक्षम हो।

Answer 9

परिवर्तनीय का उद्देश्य स्पष्ट है तो छोटा करना बेहतर है।लैम्ब्डास लेखन की एक कार्यात्मक शैली के लिए बुलाते हैं, इसलिए आप एक ही पंक्ति में बहुत सी श्रृंखला देखते हैं। जब आप उन्हें छोटा रखते हैं तो यह देखने के लिए इसका क्लीनर।

एक और मामला तब होता है जब कभी-कभी आपको एक डमी वैरिएबल घोषित करने की आवश्यकता होती है जिसमें उस दायरे में कोई प्रासंगिकता/अर्थ नहीं होता है। ऐसे मामलों में मैं _ का उपयोग करता हूं जो इसे मेरे लिए स्पष्ट करता है। यह विशेष रूप से विधि से अधिक भार के दौरान काम आता है, उदाहरण के लिए,

public Foo Do() 
{ 
    return Do(_ => true); 
} 

public Foo Do(Func<T, bool> pattern) 
{ 
    return SomethingElse(pattern); 
} 

Answer 10

ऊपर जवाब के आधार पर, मुझे लगता है कि आम सहमति है कि वहाँ, आप संदर्भ क्या आप के साथ काम कर रहे हैं से नहीं बता सकता है, तो एक वर्णनात्मक का उपयोग कर नाम बेहतर है। उदाहरण के लिए:

entities.Where(person => person.Age >= 21); 

मामलों में जहां संदर्भ है में स्पष्ट है, तथापि, एक भी अक्षर नाम वास्तव में, पठनीयता मदद मिल सकती है, क्योंकि यह यह आसान महत्वपूर्ण जानकारी पर ध्यान केंद्रित करने में आता है। उदाहरण के लिए:

people.Where(p => p.Age >= 21); या people.Where(x => x.Age >= 21);

सवाल है, जो बेहतर है p या x है?

• p के पक्ष में, यह एसक्यूएल प्रश्नों में एक परिचित पैटर्न है और एक छोटे से अतिरिक्त अनुस्मारक है कि आपने एक Person के बारे में बात कर रहे हैं प्रदान करता है।
• x के पक्ष में, यदि आप Person से Customer का नाम बदलते हैं, तो आपको अपने सभी लैम्ब्डा पैरामीटर को ठीक करने की चिंता करने की आवश्यकता नहीं है। यदि आपने p का उपयोग किया था, तो यह वास्तव में थोड़ा उलझन में होगा यदि आपका कोड customers.Where(p => p.Age >= 21) बन गया, जबकि x मूल रूप से अज्ञेयवादी है।

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

Answer 11

हमारी टीम एकल अक्षर चर की अनुमति नहीं देती है, न कि लम्दास में घटना।

हम जो पाते हैं, वह टीएसक्यूएल की तरह है, जितना लंबा कोड उतना भ्रमित हो जाता है। जहां तक ​​लैम्ब्डा के

हम कुछ इस तरह करना होगा:

people.Where(personFound => personFound.FirstName.Contains("blah!")); 

इस तरह अगले देव पर

people.Where(p => p.FirstName.Contains("blah")); 

यह पठनीय लगता है देखने के लिए नहीं होगा, लेकिन यह हमेशा पहली बार में करता है

क्या के बारे में शामिल होने के

citizenShip.Join(people, c => c.personid, p => p.persoinid, (p, c) => new { p.FirstName, c.IsCitizen}) 
.Where(pc => pc.FirstName.Contains("blah"); 

,210

एक ही चर नाम

citizenShip.Join(people, 
       citizenToJoin => citizenToJoin.personid, 
       personToJoin => personToJoin.persoinid, 
       (joinedPerson, joinedCitiznship) => 
        new { joinedPerson.FirstName, joinedCitiznship.IsCitizen}) 
.Where(personAndCitizenshipFound=> personAndCitizenshipFound.FirstName.Contains("blah"); 

ओह साथ लेकिन यह भ्रामक और बदसूरत है। बस differenct पत्र उपयोग करती हैं इसलिए कम भ्रामक

citizenShip.Join(people, 
       c => c.personid, 
       p => p.persoinid, 
       (jp, pc) => 
        new { jp.FirstName, jc.IsCitizen}) 
.Where(pc => pc.FirstName.Contains("blah"); 

फिर भी भ्रामक है, लेकिन अब इसकी भी बदतर।इसलिए हम लैम्ब्डा को तोड़ने तो हम पठनीयता

var peopleWithCitizenship = citizenShip.Join(people, 
              citizenToJoin => citizenToJoin.personid, 
              personToJoin => personToJoin.persoinid, 
              (joinedPerson, joinedCitiznship) => new { joinedPerson.FirstName, joinedCitiznship.IsCitizen}); 

var peopleWithCitizenshipFilteredByName = peopleWithCitizenship.Where(personAndCitizenshipFound=> personAndCitizenshipFound.FirstName.Contains("blah")); 

यह एक आदर्श उदाहरण नहीं है के लिए refactor लेकिन कोड बहुत कम अंदरूनी सूत्र ज्ञान के साथ पठनीय हैं। हम पाते हैं कि यह जटिल कोड (लैम्ब्डा) का खुलासा करता है जिसे छोटे हिस्सों में तोड़ने की आवश्यकता होती है।