विधि में संयुग्मों का उपयोग एक खराब नामकरण सम्मेलन का नाम क्यों है? [बन्द है]

Question

मेरी टीम में, हम कुछ सॉफ्टवेयर आर्किटेक्ट्स के साथ मिलकर काम करते हैं। वे हमारी परियोजनाओं के सभी डिजाइन निर्णयों को अनुमोदित करते हैं, कुछ कोड समीक्षा आदि करते हैं।

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

हाल ही में, वे कुछ सुझाव दिया है कि मैं बहुत ही अजीब लगता है: सभी तरीकों उनके नाम जैसे में संयोजक होना चाहिए getEntityOrNull, setValueOrExceptionआदि

इस तरह के नामकरण सम्मेलन मेरे लिए बहुत गलत लगता है, लेकिन मैं किसी भी ठोस तर्क या ऑनलाइन लेख / पृष्ठों के साथ नहीं आ सकता हूं जो विशेष रूप से इसे चुनौती देते हैं।

केवल एक चीज जो मैं लेकर आया हूं वह है:

• इस तरह की जानकारी विधि के एनोटेशन में मौजूद होनी चाहिए, जैसे @returnया@throws
• विधि नाम में संयुग्मों ("और", "या" आदि) का उपयोग आमतौर पर सुझाव देता है कि एकल उत्तरदायित्व सिद्धांत का समुचित मूल्यांकन नहीं किया गया है

इस नामकरण सम्मेलन के खिलाफ कुछ अन्य ठोस तर्क क्या हैं?

Comments

आम तौर पर, आप नहीं कर सकते

— gnat

the use of conjunctions ("and", "or" etc.) in method names usually suggest that the Single Responsibility Principle is not properly respectedयह आपके द्वारा सूचीबद्ध उदाहरणों के लिए मामला नहीं है, जहां विफलता को संभालने के लिए उपयोग किए जाने वाले तंत्र को स्पष्ट करने के लिए संयुग्मन का उपयोग किया जाता है, यह इंगित करने के लिए नहीं कि यह एक काम कर सकता है या कोई अन्य। यहां तक ​​कि सबसे संकीर्ण रूप से परिभाषित फ़ंक्शन में वैध विफलता की स्थिति हो सकती है, जैसे कि खाली स्टैक को पॉप करना।

— डोभाल 15

विचार करें: (1) "या अशक्त" के बजाय "वैकल्पिक" का उपयोग करना। "GetOptionalEntity" मेरे कान "GetEntityOrNull" से बेहतर लगता है। । उदाहरण के लिए, Int32.TryParseऔर Int32.Parse- दोनों एक पूर्णांक में एक स्ट्रिंग को पार्स करते हैं, लेकिन पूर्व एक बूलियन को सफलता का संकेत देता है और बाद में विफलता के साथ फेंकता है।

— एरिक लिपर्ट

मैं फेंकने वाले संस्करण के लिए एक प्रत्यय का उपयोग नहीं करूंगा, लेकिन मैं शून्य रिटर्न वाले संस्करण के लिए एक का उपयोग करूंगा। हो सकता है Try..., ...OrNull, ...OrDefault। @EricLippert .net में यह एकमात्र सम्मेलन नहीं है। पर विचार करें Singleबनाम SingleOrDefault, जो बहुत करीब है OrNullओ पी का सुझाव दिया।

— कोडइंचोस

Answer 1

वे संभवतः संघर्षों के नामकरण के कारण ऐसा कर रहे हैं। मैं मानता हूं कि आपके पास नाम की दो विधियां नहीं हो सकती हैं getEntity, एक जो संभवत: एक अपवाद को फेंकती है और एक जो वापस आती है null। इसलिए, आपको उनके अनुसार नाम देना होगा।

मैं, एक के लिए, एक ही विधि को कॉल करने के कई अलग-अलग तरीके होने के अभ्यास को नापसंद करता हूं जब तक कि यह कुछ परिवर्तन नहीं कर रहा है जो केवल उस विशेष वर्ग का प्रदर्शन कर सकता है।

दूसरे शब्दों में, यदि getValueOrNullकेवल कॉल getValueOrExceptionकर रहा है , अपवाद को कैप्चर कर रहा है, और उस स्थिति में null, यह कॉलर द्वारा किया जा सकता है। यह उन तरीकों के साथ वर्ग को बंद कर देता है जो वास्तव में उपयोगी कुछ भी योगदान नहीं करते हैं। बल्कि मैं पसंद करूंगा getValue, और यह जानूंगा कि यह अपवाद फेंकता है। बेहतर अभी भी, मैं यह जानना पसंद करूंगा कि सभी को संभावित रूप से अपवाद फेंकने के तरीके मिलते हैं, और उनमें से कोई भी वापसी नहीं nullकरता है ताकि व्यवहार मेरे प्रोजेक्ट में एक समान हो, या इसके विपरीत, सभी संभावित रूप से वापस आ जाएं null, और यह जान लें कि कॉलर को अपवाद फेंकना होगा यदि वह वांछित थे।

हालाँकि, यह भी सच है कि आप उस के प्रभारी नहीं हैं। मेरी सलाह यह है कि इसे लाया जाए, लेकिन क्षुद्र बातों को न सुनाएं। अंततः, इस तरह के नामकरण सम्मेलनों की ज़िम्मेदारी उनके कंधों पर होती है, भले ही वे आपकी सलाह लें या न लें, और क्योंकि यह लाइन पर उनके गधे हैं, मेरा मानना ​​है कि यह उनके लिए विनम्र राय में नहीं, उनका कहना है।

Comments

यदि आपको केवल एक चुनना था, तो वापस लौटना बेहतर है null(या बेहतर अभी तक, एक वैकल्पिक / शायद प्रकार) क्योंकि फेंकना अपेक्षाकृत महंगा है। यदि कोई मान अमान्य है और थ्रो अधिक ओवरहेड नहीं जोड़ता है, तो एक सहायक लिखना। हालाँकि जब आप नो-थ्रो संस्करण चाहते हैं, तो अपवाद को निगलने से आपको वह प्रदर्शन वापस नहीं मिलेगा, जो आपने फेंक दिया था।

— डोभाल

@Doval अच्छा बिंदु है, और शायद अधिक महत्वपूर्ण अपवाद होना चाहिए असाधारण । यदि आप अक्सर अपवाद फेंक रहे हैं, तो आप उनका सही उपयोग नहीं कर रहे हैं। केवल वापसी के साथ समस्या nullयह है कि nullवास्तव में कुछ उदाहरणों में एक वैध वापसी हो सकती है और इसलिए आपको आदर्श से विचलित करना होगा और ऐसे उदाहरणों में अपवाद फेंकना होगा।

— नील

Answer 2

यद्यपि संयुग्मों का उपयोग अक्सर एसआरपी के उल्लंघन का संकेत देता है, इस मामले में यह सिर्फ एक गरीब आदमी के बीजीय डेटा प्रकार के वापसी मूल्य को इंगित करता है जो दो मानों में से nullएक या "सफलता" मूल्य हो सकता है।

वे प्रकार प्रणाली में कमजोरियों की भरपाई के लिए एक प्रकार के हंगेरियन नोटेशन का उपयोग कर रहे हैं , अर्थात् गैर-अशक्त प्रकारों की कमी। दूसरे शब्दों में, आपके @returnएनोटेशन में यह निर्दिष्ट करने का कोई तरीका नहीं है कि फ़ंक्शन कभी वापस नहीं आएगा null, और इसके विपरीत, आपके @returnएनोटेशन में यह निर्दिष्ट करने का कोई तरीका नहीं है कि फ़ंक्शन संभवतः वापस आ सकता है null।

इसके अलावा, मेरा मानना ​​है कि @throwsphp में एनोटेशन अनिवार्य नहीं है, इसलिए एनोटेशन की अनुपस्थिति एक अपवाद की अनुपस्थिति को इंगित नहीं करती है, हालांकि यह आपके स्टाइल गाइड में एनोटेशन को अनिवार्य बनाकर बेहतर हल है।

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

Answer 3

मेरे कोड में मैं कभी-कभी getEntity () और getEntityOrNull () जैसे नामों के साथ विधि जोड़े बनाता हूं। नाम अपेक्षित व्यवहार को स्पष्ट करता है। यदि getEntity () को कोई इकाई नहीं मिलती है, तो एक अपवाद फेंक दिया जाता है। getEntityOrNull () एक नल लौटाएगा।

ऐसा करने से कॉलिंग कोड थोड़ा साफ हो जाता है। यदि कॉलिंग कोड के लिए एक इकाई है तो getEntity ट्रिक करेगी। यदि इकाई किसी प्रकार की वैकल्पिक चीज है तो getEntityOrNull पसंद का तरीका है।

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

यदि आपके आर्किटेक्ट इस प्रकार की विधि जोड़े का उपयोग नहीं कर रहे हैं, तो हाँ, मैं प्रत्यय की आवश्यकता पर सवाल उठाऊंगा।

वास्तव में एक setValueOrException विधि कभी नहीं देखी। उस के लिए एक अच्छा आम उपयोग के मामले के बारे में सोच भी नहीं सकते।

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

Comments

यह getEntity विफलता पर एक अपवाद फेंक देगा मेरे लिए बिल्कुल भी स्पष्ट नहीं है, मैं एक साधारण NULL की उम्मीद करूंगा।

— एलिस वैन लोईज

Answer 4

आपके दो तर्क ध्वनि हैं। लेकिन अगर वे नामकरण सम्मेलन का निर्णय लेने के प्रभारी हैं, तो इसके बारे में बहुत बुरा न महसूस करने की कोशिश करें कि आप कुछ से सहमत नहीं हैं।

जब आप इस पर होते हैं, तो आपको उन्हें समझा देना चाहिए कि "प्राप्त करें" और "सेट" भागों का उपयोग न करें जब तक कि वे तरीके वास्तव में सीधे सेट न करें या सदस्य चर प्राप्त न करें।