नामकरण: क्या आपको स्पष्टता के लिए संक्षिप्तता का त्याग करना चाहिए?

Question

उदाहरण के लिए, निम्न फ़ंक्शन एक सरणी के माध्यम से लूप करता है जिसमें एक इनपुट फ़ील्ड का नाम और त्रुटियां होती हैं। यह सत्यापन क्षेत्र के नाम की जाँच करके और फिर त्रुटि जानकारी को अमान्य फ़ील्ड सरणी पर धकेलता है।

क्या यह संक्षिप्त होना बेहतर है और इसे लिखें:

addInvalidField (field, message) {
  const foundField = this.invalidFields.find(value => {
    return value.name === field.name
  })
  const errors = foundField.errors
  if (!errors.some(error => error.name === message)) {
    errors.push({ name: message, message })
  }
},

या इस तरह अधिक विशिष्ट हो?

addInvalidField (validatingField, message) {
  const foundField = this.invalidFields.find(invalidField => {
    return validatingField.name === invalidField.name
  })
  if (!foundField.errors.some(foundFieldError => foundFieldError.name === message)) {
    fouldField.errors.push({ name: message, message })
  }
},

Comments

संबंधित (संभवतः एक डुप्लिकेट): क्या लघु चर नामों का बहाना है?

— gnat

एक उत्तर लिखने का मन नहीं है, लेकिन हम हमेशा नाम की लंबाई और स्पष्टता के बीच एक अच्छा समझौता खोजने की कोशिश करते हैं। संक्षिप्त नाम मूल प्रोग्रामर के लिए स्पष्ट हो सकते हैं लेकिन बाकी सभी के लिए नहीं। लंबे नाम कोड को पढ़ने के लिए दर्द बना सकते हैं। बीच में एक समझौता है।

— 13 मई को मेटलमेकेस्टर

अधिक टिप्पणियों की जरूरत है

— इवान

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

— 179

@alex आपकी टिप्पणी के जवाब में, यदि आप Marijn Haverbeke द्वारा एलोकेंट जावास्क्रिप्ट की एक प्रति प्राप्त कर सकते हैं या उधार ले सकते हैं, (2014 संस्करण) एक सरणी के बजाय मानचित्र का उपयोग करने का एक बड़ा उदाहरण देखने के लिए 73-75 पृष्ठों पर जाएं। उम्मीद है की वो मदद करदे।

— user949300

Answer 1

अगर स्पष्टता के लिए संक्षिप्तता का त्याग किया जा सकता है, तो यह होना चाहिए। लेकिन अगर स्पष्टता के लिए वर्बोसिटी का त्याग किया जा सकता है, तो और भी बेहतर।

addInvalidField (field, message) {
  const foundInvalidField = this.invalidFields.find(x => x.name === field.name)
  if (!foundInvalidField.errors.some(x => x.name === message)) {
    foundInvalidField.errors.push({ name: message, message })
  }
},

जब एक चर केवल एक पंक्ति के रूप में रहता है तो यह वास्तव में बहुत कम हो सकता है। FoundInvalidFieldतीन लाइनों में उपयोग किया जाता है और इस काम का फोकस है। यह एक व्याख्यात्मक नाम का हकदार है।

हमेशा की तरह, संदर्भ राजा है।

Comments

+1 के लिए "यदि स्पष्टता के लिए संक्षिप्तता का त्याग किया जा सकता है, लेकिन यदि स्पष्टता के लिए क्रियात्मकता का त्याग किया जा सकता है, तो और भी बेहतर।" यहां तक ​​कि जब मैं लगभग हर परिस्थिति में स्पष्टता के लिए प्रयास करता हूं। लेकिन यह निश्चित रूप से एक उद्धरण योग्य उद्धरण है।

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

Answer 2

मैं वास्तव में आपके पहले कोड उदाहरण का पक्ष लेता हूं।

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

ऐसा इसलिए है क्योंकि आपने अपने कार्यों को संक्षिप्त रखा है कि आप अपने चर नामों को भी संक्षिप्त रख सकते हैं। अन्य सभी चीजें समान हैं, कम कोड हमेशा बेहतर होता है।

Comments

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

— अनफ़ॉलो करें

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

— जिमीजैम्स 14

@unflores मैं भी ऐसा करने की कोशिश करता हूं। validatingFieldsसत्यापन के साथ फार्म फ़ील्ड हैं। मूल नाम था fieldWithValidation। इस एक के लिए एक संक्षिप्त नाम खोजना वास्तव में कठिन है। मैं इसे बस कह सकता हूं, fieldलेकिन फिर इसका fieldविधि के अंदर एक और के साथ संघर्ष होगा ।

— एलेक्स

Answer 3

मुझे लगता है कि अत्यधिक अंकुश के बिना स्पष्टता पसंद करने पर मैं अंकल बॉब से सहमत हूं । आपके द्वारा दिखाए गए उदाहरणों में, मैं कहूंगा कि अत्यधिक क्रियात्मकता में आए बिना दूसरे का इरादा अधिक स्पष्ट है । इसके अलावा यह जब हालांकि के लिए कोड बेस खोज उस विशेष स्निपेट प्राप्त करने आसान होगा invalidFieldके लिए की तुलना में value।

---

वैसे मैं यहाँ क्लीन कोड उद्धृत कर रहा हूँ (इसे छोड़ें यदि आप अंकल बॉब के उपदेश से प्रभावित हैं (जो मैं नहीं हूँ):

इरादा-खुलासा नामों का उपयोग करें

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

---

विघटन से बचें

प्रोग्रामर को झूठे सुराग छोड़ने से बचना चाहिए जो कोड का अर्थ अस्पष्ट करते हैं। हमें उन शब्दों से बचना चाहिए जिनके गूढ़ अर्थ हमारे अलग-अलग हैं

---

सार्थक भेद करो

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

---

खोजा नाम का उपयोग करें

उन नामों का उपयोग करें जो आपको एक करने में मदद करेंगे grep -iIR whateveryouaresearching . (एक स्वच्छ कोड नहीं, यहां CC केवल एकल अक्षर चर के बारे में बात करता है)।

---

मानसिक मानचित्रण से बचें

पाठकों को मानसिक रूप से आपके नामों का उन अन्य नामों में अनुवाद नहीं करना चाहिए, जिन्हें वे पहले से जानते हैं। यह समस्या आम तौर पर न तो समस्या डोमेन शब्दों और न ही समाधान डोमेन शर्तों का उपयोग करने के लिए एक विकल्प से उत्पन्न होती है।

---

समस्या डोमेन नाम का उपयोग करें

जब आप क्या कर रहे हैं, इसके लिए कोई "प्रोग्रामर-एसे" नहीं है, तो समस्या डोमेन से नाम का उपयोग करें। कम से कम प्रोग्रामर जो आपके कोड को बनाए रखता है वह एक डोमेन विशेषज्ञ से पूछ सकता है कि इसका क्या मतलब है।

---

Answer 4

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

प्रागितिहास में वापस आपके पास चर नाम प्रतिबंध था और सार्थक चर नाम का उपयोग वास्तव में एक औसत दर्जे का खर्च कर सकता था (जैसे कि बीबीसी बेसिक में पूर्णांक स्टैटिक चर का उपयोग कर एक% आदि एक सार्थक पूर्णांक का उपयोग करने की तुलना में सस्ता था - और 1MHz के साथ सिस्टम में) प्रोसेसर, एक लूप में कुछ घड़ी चक्रों को सहेजना वास्तव में मायने रखता है)

Comments

नकारात्मक पक्ष यह नहीं है कि आपको बहुत कुछ लिखना होगा। टाइपिंग केवल एक बार होती है। नामों का नकारात्मक पक्ष यह है कि पढ़ना कठिन हो जाता है। और यह कपटपूर्ण है क्योंकि रीडिंग कई बार कोड बेस के जीवन पर होती है, और क्योंकि लोग सचेत रूप से समस्या के स्रोत को नोटिस नहीं करते हैं क्योंकि रीडिंग बहुत ही अंतर्विष्ट है।

— बजे किलन फ़ॉथ

और अगर आपको एक चर के बारे में कुछ याद रखने की कोशिश करने में समय और संदर्भ की शिफ्ट करनी पड़ती है क्योंकि यह वर्णनात्मक नहीं था तो आपको अधिक समय खर्च करना पड़ेगा :)।

— mcottle

Answer 5

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

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

addInvalidField (fieldname, message) {
  const foundField = this.invalidFields.find(value => {
    return value.name === fieldname
  })
  const errors = foundField.errors
  if (!errors.some(error => error.name === message)) {
    errors.push({ name: message, message })
  }
}

हालांकि, मुझे लगता है कि बॉब मार्टिन शायद एक कदम आगे जाएगा और कोड को अधिक स्पष्टता के लिए - अधिक स्पष्टता के लिए - कोड को और अधिक शब्द बना देगा। "क्लीन कोड" पुस्तक की तर्ज पर एक विशिष्ट रीफैक्टरिंग शायद इस तरह दिखाई देगी:

addInvalidField (fieldname, message) {
  const foundField = findInvalidField(fieldName)
  addMessageForInvalidField(foundField,message)
}

तीन अतिरिक्त कार्यों के साथ

  findInvalidField(fieldname){
    return this.invalidFields.find(value => { return value.name === fieldname })
  }

  addMessageForInvalidField(field,message){
    const errors = field.errors
    if (!doesErrorsContain(message)) {
      errors.push({ name: message, message })
    }
  }

  doesErrorsContain(message){
     return errors.some(error => error.name === message)
  }

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

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

Comments

validatingFieldsएक फॉर्म में फ़ील्ड्स हैं जिनके पास सत्यापन है। शुरू में, मैंने उन्हें नाम दिया था fieldsWithValidationलेकिन यह थोड़ा लंबा था।

— एलेक्स

Answer 6

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

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

दिन के अंत में, जो बेहतर है वह आपके ऊपर होगा और आप जिस किसी के साथ काम कर रहे हैं। आखिरकार, वह है जो इसे पढ़ रहा है और इसे बनाए रखेगा।