2011-09-01 13 views
8

मैंने कई स्टाइल दिशानिर्देशों और अन्य संसाधनों को पढ़ा है जो बताते हैं कि विधि/चर/अन्य नामों में अंडरस्कोर का उपयोग करना एक बुरा विचार है।स्कैला नामों में अंडरस्कोर

इसके पीछे तकनीकी कारण क्या हैं?

मैं बहुत आदी हूं उदा। _ के साथ पूर्व सहायक सहायक कार्यों। ऐसे कार्य भी हैं जो निजी हो सकते हैं जिन्हें मैं सार्वजनिक बनाना चाहता हूं ताकि मैं उन्हें आरईपीएल के माध्यम से एक्सेस कर सकूं। अन्य नामकरण सम्मेलन जैसे "सहायक" प्रत्यय का उपयोग करना बोझिल लगता है।

किसी भी विचार की सराहना की जाएगी!

उत्तर

11

वाइल्डकार्ड ऑपरेटर _ स्कैला में भारी रूप से उपयोग किया जाता है। तो:

xs map (_.x) // Call the x method of every element 
xs map (_x) // Pass every element through the _x method 

उलझन में है। अंडरस्कोर प्रीपेड किया गया है या नहीं, यह देखने के लिए आपको बहुत ध्यान से देखना होगा।

हालांकि, आंतरिक अंडरस्कोर भ्रमित करने के लिए कड़ी मेहनत कर रहे:

xs map (my_method) // No similar form where _ stands for the list element 

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

+3

यह एक बहुत ही निर्मित मामला है: आपके पास 'xs: Seq [T: {def x: U}]' है। त्रुटि होने के लिए, आपको बिल्कुल '_x: {def लागू (y: T): U}' की आवश्यकता है। यदि इनमें से कोई भी तीन बाधाएं नहीं हैं, तो यह संकलित नहीं होती है। इसे बिल्कुल '_x' नाम दिया जाना है, जिसे एक' टी' तर्क के साथ कॉल करने योग्य होना है, जिसे 'यू' वापस करना है। मैं भी थोड़ा आश्वस्त नहीं हूँ। –

+3

@flying भेड़ - यह संभावना नहीं है कि आपके पास उस तरह का नाम टकराव होगा; मुद्दा यह है कि जब आप केवल कुछ हद तक परिचित कोड के माध्यम से जल्दी पढ़ रहे हैं, तो आप तुरंत नहीं जानते कि स्थानीय कोड में एक निजी विधि या संग्रह तत्व पर सार्वजनिक विधि खेल में है या नहीं। आप निश्चित रूप से, जल्दी से पता लगा सकते हैं, लेकिन यदि आप दूरी से आकार से बता सकते हैं तो आप इसे तेज कर सकते हैं। –

1

मुझे लगता है कि उन चश्मे नामों में अंडरस्कोर के बारे में बात करते हैं।

क्या आपको इस तरह से नहीं (एसएएन) तरीके से निम्नलिखित लिखना चाहिए?

object getterSetter { 
    var _variable: Option[Double] = None 
    def variable = _variable 
    def variable_=(newVal: Double) { _variable = Some(newVal) } 
} 

मुझे लगता है कि camelCase बजाय embedded_underscores के लिए कारण बस है कि जावा कि का उपयोग करता है और जब जावा पुस्तकालयों के साथ काम, स्थिरता केवल ऐसे ही रखा जा सकता है।

+2

अंडरस्कोर के साथ तैयार करना _convention_ है; आपको अभी भी इसे निजी घोषित करना है। साथ ही, आप 'variableHidden' या' _variable' की बजाय अन्य किसी भी चीज का उपयोग कर सकते हैं। –

+0

ओह, आप सही हैं। उसमें उलझन में होना चाहिए। लेकिन 'variableHidden'? गंभीरता से? –

+0

मैं '_variable' का भी उपयोग करता हूं, लेकिन रेक्स केर के उत्तर में तर्क दिलचस्प है। –

5

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

लेकिन मुझे कबूल करना चाहिए कि मैं कभी-कभी परिवर्तनीय वस्तुओं में निजी चर के लिए अंडरस्कोर उपसर्ग का उपयोग करता हूं, अगर मैं सार्वजनिक तरीकों के लिए गैर-अंडरस्कोर नाम चाहता हूं। यह अच्छा होगा अगर हम हास्केल की तरह primes (foo ') का उपयोग कर सकते हैं, लेकिन मुझे लगता है कि यह काफी मुश्किल होगा।

2

_ के अलावा पूरे भाषा में एक वाइल्डकार्ड के रूप में नहीं बल्कि सार्वजनिक एपीआई के हिस्सों जैसे टुपल्स (someTuple._1 आदि) के रूप में भी कुछ मामलों में संकलक द्वारा इसका अर्थ भी लिया जाता है। उदाहरण के लिए सेटर्स, जिन्हें _= या यूनरी ऑपरेटर्स में प्रत्ययित किया जाना है, जिन्हें unary_ के साथ प्रीफ़िक्स किया जाना है।

यह सब दुर्घटना से "विशेष नाम" का उपयोग करना या "साधारण नाम" की गलत व्याख्या करना आसान बनाता है जब किसी ने कुछ समान उपयोग किया लेकिन बिल्कुल "विशेष नाम" जैसा ही नहीं किया। इससे कोई फर्क नहीं पड़ता कि यह दुर्घटना या ज्ञान की कमी के कारण हुआ, लेकिन जब ऐसा होता है तो आप शायद कुछ घंटों में बग की तलाश करेंगे। तो जब तक आपको वास्तव में नहीं करना है तब तक उनका उपयोग न करें।डीएसएल हमेशा एक अपवाद हैं।

संबंधित मुद्दे