নামকরণ: স্বচ্ছতার জন্য আপনার কি সংক্ষিপ্ত বিবরণ দেওয়া উচিত?


11

উদাহরণস্বরূপ, নিম্নলিখিত ফাংশনটি একটি অ্যারের মাধ্যমে লুপ করে যা কোনও ইনপুট ক্ষেত্রের নাম এবং ত্রুটি ধারণ করে। এটি বৈধকরণের ক্ষেত্রের নামটি পরীক্ষা করে এবং তারপরে ত্রুটি সম্পর্কিত তথ্যটি অবৈধ ক্ষেত্রের অ্যারেতে চাপিয়ে এটি করে।

সংক্ষিপ্ত হয়ে এটি লেখার চেয়ে কি আরও ভাল:

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 })
  }
},


উত্তর লেখার মতো মনে হয় না, তবে আমরা সর্বদা নামের দৈর্ঘ্য এবং স্পষ্টতার মধ্যে একটি ভাল সমঝোতার সন্ধান করার চেষ্টা করি। সংক্ষিপ্ত নামগুলি মূল প্রোগ্রামারটির কাছে সুস্পষ্ট হতে পারে তবে অন্য সবার কাছে নয়। দীর্ঘ নামগুলি কোডটি পড়তে ব্যথা করে। এর মধ্যে একটি আপস আছে।
মেটালমাইকস্টার

1
আরও মন্তব্য দরকার
Ewan

পার্শ্ব নোট, এবং এটি আপনার কোডে সম্ভব কিনা তা নিশ্চিত নয় তবে যদি অবৈধ ফিল্ডস ইত্যাদি কোনও মানচিত্রে অ্যারে না রেখে সংরক্ষণ করা হত তবে এই কোডটি আরও সহজতর হবে।
user949300

1
@ অ্যালেক্স আপনার মন্তব্যের উত্তরে, আপনি যদি মারিজন হ্যাভারবেকে রচিত স্পষ্ট ভাষায় জাভাস্ক্রিপ্টের অনুলিপি বা ধার নিতে পারেন, (2014 সংস্করণ) অ্যারের পরিবর্তে মানচিত্র ব্যবহারের দুর্দান্ত উদাহরণ দেখতে 73৩-7575 পৃষ্ঠাতে যান। আশা করি এইটি কাজ করবে.
user949300

উত্তর:


23

যদি স্পষ্টতার জন্য ব্রেভিটি কোরবানি দেওয়া যায় তবে এটি করা উচিত। তবে স্পষ্টতার জন্য যদি ভারবোসিটি বলি দেওয়া যায় তবে আরও ভাল।

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তিনটি লাইনে ব্যবহৃত হয় এবং এটি এই কাজের ফোকাস। এটি একটি ব্যাখ্যামূলক নাম প্রাপ্য।

সর্বদা হিসাবে, প্রসঙ্গ রাজা।


2
+1 এর জন্য "যদি স্পষ্টতার জন্য ব্রেভিটি কোরবানি দেওয়া যায় তবে এটি স্পষ্টতার জন্য যদি বলিষ্ঠতা উত্সর্গ করা যায় তবে আরও ভাল।" এমনকি যখন আমি প্রায় প্রতিটি সার্কনেস্টে স্পষ্টতার জন্য চেষ্টা করি। তবে এটি সংজ্ঞামূলকভাবে উদ্ধৃত উদ্ধৃতি
তুলাইনস কর্ডোভা

12

আমি আসলে আপনার প্রথম কোড উদাহরণের পক্ষে।

কোডটি পড়ার দ্বারা এটি কী করে তা স্পষ্টভাবে স্পষ্ট। ভেরিয়েবলের নামগুলি যতটা সম্ভব ছোট রেখে আপনি কোডটি আরও পড়তে আরও সহজ করে তোলেন। আরও বেশি বর্ণনামূলক ভেরিয়েবলের নামগুলি কেবল তখনই প্রয়োজন হবে যদি আপনার ফাংশনগুলি দীর্ঘ হয়, আপনার ভেরিয়েবলগুলি আরও অনেক বেশি এবং / অথবা ভেরিয়েবলগুলি বৃহত্তর কোড স্কোপে ব্যবহার করা হত।

এর কারণ আপনি নিজের ফাংশনগুলি সংক্ষিপ্ত রেখেছেন যে আপনি নিজের পরিবর্তনশীল নামগুলিও সংক্ষিপ্ত রাখতে পারেন। অন্যান্য সমস্ত জিনিস সমান হচ্ছে, কম কোড সর্বদা ভাল।


2
এটিকে পিগব্যাক করার জন্য, একটি সাধারণ নিয়ম হিসাবে, আমি আমার পদ্ধতি / ফাংশনগুলির জন্য ছোট ভেরিয়েবলের নাম পছন্দ করি। কেবলমাত্র যখন আমি আরও একটি ভার্বোজের নামটি ব্যবহার করতাম তখন যদি কোনও নেমস্পেসের বিরোধ হয়। যদি আপনার ফাংশনের আকার ছোট হয় তবে এটি সম্পাদন করাও সহজ।
27 এ ফুল ফোটে

4
আমি এমন কারো সাথে কাজ করেছি যিনি সত্য ভার্বোজের নামগুলিতে বড় big ভেরিয়েবল এবং পদ্ধতির নামগুলি মূলত পুরো ইংরেজী বাক্যগুলি ছিল যেমন: রেজাল্টঅফমেথডডোফুওয়াইথবার। ধারণাটি ছিল যে এটি বিষয়গুলি পরিষ্কার করার কথা ছিল তবে এটি আমার সমস্ত মাথা ঘামিয়ে বিশ্লেষণ করার চেষ্টা করেছিল (মানসিকভাবে)। এই উদাহরণের জন্য, আমরা ইতিমধ্যে পদ্ধতিটি ক্ষেত্রের বৈধতা সম্পর্কে জানি। অন্য কোনও 'ক্ষেত্র' পরামিতি নেই। 'ভেলডিটিংফিল্ড' এর মতো নাম ব্যবহার করা কোনও স্পষ্টতা যুক্ত করে না এবং স্কিমিংয়ের সময় গুরুত্বপূর্ণ তথ্যকে অস্পষ্ট করে।
জিমি জেমস

@ আনফ্লোরিস আমিও এটি করার চেষ্টা করি। validatingFieldsবৈধতা সহ ফর্ম ক্ষেত্র হয়। আসল নাম ছিল fieldWithValidation। এটির জন্য একটি সংক্ষিপ্ত নাম পাওয়া সত্যিই কঠিন। আমি এটিকে কেবল কল করতে পারি fieldতবে তারপরে fieldপদ্ধতির অভ্যন্তরে এটির সাথে অন্যটির সাথে বিরোধ হয় ।
অ্যালেক্স

4

আমি মনে করি যে অতিরিক্ত মামুলি ব্যয় না করে স্পষ্টতার পক্ষে অগ্রাধিকার দেওয়ার জন্য আমি চাচা ববের সাথে একমত । আপনি যে উদাহরণগুলি দেখান তাতে আমি বলব যে অতিরিক্ত ভার্চুয়ালটি ব্যয় না করে দ্বিতীয়টির অভিপ্রায়টি আরও স্পষ্ট । এছাড়াও কোড বেসের invalidFieldচেয়ে যদিও অনুসন্ধানের সময় সেই নির্দিষ্ট স্নিপেটটি সন্ধান করা সহজ হবে value


আচ্ছা, আমি এখানে ক্লিন কোডটি উদ্ধৃত করছি (আপনি যদি চাচা বব এর প্রচারে বিরক্ত হন (তবে আমি যা নই):

উদ্দেশ্য-প্রকাশের নামগুলি ব্যবহার করুন

এটি বলা সহজ যে নামগুলির উদ্দেশ্যটি প্রকাশ করা উচিত। আমরা আপনাকে যে বিষয়টি প্রভাবিত করতে চাই তা হ'ল আমরা এটি সম্পর্কে গুরুতর। ভাল নাম বাছাই করতে সময় লাগে তবে যা লাগে তার চেয়ে বেশি সাশ্রয় হয়। সুতরাং আপনার নামগুলির সাথে যত্ন নিন এবং যখন আপনি আরও ভাল কিছু পান তখন সেগুলি পরিবর্তন করুন। আপনার কোডটি পড়ে আপনার প্রত্যেককে (আপনাকে অন্তর্ভুক্ত) আপনি যদি তা করেন তবে সুখী হবে।


বিশৃঙ্খলা এড়ান

প্রোগ্রামারদের অবশ্যই কোডের অর্থকে অস্পষ্ট করে এমন মিথ্যা ক্লু ছেড়ে যাওয়া এড়াতে হবে। আমাদের এমন শব্দগুলি এড়ানো উচিত যাগুলির প্রবেশের অর্থ আমাদের থেকে আলাদা


অর্থপূর্ণ পার্থক্য তৈরি করুন

প্রোগ্রামাররা নিজেরাই সমস্যা তৈরি করে যখন তারা কোনও সংকলক বা দোভাষীকে সন্তুষ্ট করার জন্য কোডটি লেখেন।


অনুসন্ধানযোগ্য নাম ব্যবহার করুন

এমন নাম ব্যবহার করুন যা আপনাকে একটি করতে সহায়তা করবে grep -iIR whateveryouaresearching . (ক্লিন কোড নয়, এখানে সিসি কেবলমাত্র একক বর্ণের ভেরিয়েবল সম্পর্কে কথা বলেছিল)।


মানসিক ম্যাপিং এড়িয়ে চলুন

পাঠকদের তাদের নাম ইতিমধ্যে জানা অন্য নামগুলিতে মানসিকভাবে অনুবাদ করতে হবে না। এই সমস্যাটি সাধারণত সমস্যা ডোমেন শর্তাদি বা সমাধান ডোমেন শর্তাদি ব্যবহার না করার পছন্দ থেকে উদ্ভূত হয়।


সমস্যাযুক্ত ডোমেন নাম ব্যবহার করুন

আপনি যা করছেন তার জন্য যখন কোনও "প্রোগ্রামার-আইস" নেই তখন সমস্যা ডোমেন থেকে নামটি ব্যবহার করুন। কমপক্ষে প্রোগ্রামার যিনি আপনার কোড বজায় রাখছেন কোনও ডোমেন বিশেষজ্ঞকে এর অর্থ কী তা জিজ্ঞাসা করতে পারেন।



1

আমি এই দিনগুলিতে সর্বদা আরও বর্ণনামূলক হতে পছন্দ করতাম - আইডিই কোড সমাপ্তির অর্থ আপনাকে বর্ণনামূলক পরিবর্তনশীল নামগুলি লিখতে হবে না যাতে আমি কোনও খারাপ দিক দেখতে পাই না।

প্রাগৈতিহাসের পিছনে আপনার পরিবর্তনশীল নামের সীমাবদ্ধতা ছিল এবং অর্থপূর্ণ ভেরিয়েবলের নাম ব্যবহার করা আসলে একটি পরিমাপযোগ্য ব্যয় করতে পারে (যেমন বিবিসি বেসিকের মধ্যে পূর্ণসংখ্যার স্ট্যাটিক ভেরিয়েবল এ% ইত্যাদি ব্যবহার করা অর্থবোধক পূর্ণসংখ্যার চেয়ে সস্তা ব্যয়বহুল ছিল - এবং 1MHz সহ একটি সিস্টেমে প্রসেসর, একটি লুপে কয়েকটি ঘড়ির চক্র সংরক্ষণ করে যা প্রকৃতপক্ষে গুরুত্বপূর্ণ)


6
খারাপ দিকটি এমন নয় যে আপনাকে অনেকগুলি টাইপ করতে হবে। টাইপিং কেবল একবার হয়। নাম যে অত্যন্ত দীর্ঘ হয় downside হয় যে পড়া কঠিন হয়ে যায়। এবং এটি কৃপণতাপূর্ণ কারণ কোড বেসের জীবন জুড়ে পাঠ অনেকবার ঘটে এবং লোকেরা সচেতনভাবে সমস্যার উত্সটি লক্ষ্য করে না কারণ পাঠ্য এতটা জড়িত।
কিলিয়ান ফট

এবং যদি আপনাকে কোনও পরিবর্তনশীল সম্পর্কে কিছু মনে রাখার চেষ্টা করতে সময় এবং প্রসঙ্গে শিফট ব্যয় করতে হয় কারণ এটি যথেষ্ট বর্ণনামূলক নয় তবে আপনার আরও বেশি সময় ব্যয় করতে হবে :)।
এমকোটল

1

দ্বিতীয় রূপটি আমাকে বিভ্রান্ত করে তোলে। যখন আমি কেবল স্বাক্ষরটি দেখি, আমি অবাক হই যে ক্ষেত্রটি ইতিমধ্যে মৌমাছিটিকে অবৈধ হিসাবে পরিচিত? বা এটি 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)
  }

যদি এটি একক দায়িত্বের নীতিটি দিয়ে এতদূর এগিয়ে যায় তবে বিতর্কযোগ্য। এর আসলে কিছু উপকারিতা ও বিপরীতে রয়েছে। আমার ব্যক্তিগত দৃষ্টিভঙ্গি হ'ল মূল কোডটি বেশিরভাগ প্রোডাকশন কোডের জন্য "যথেষ্ট পরিষ্কার" তবে রিফ্যাক্টরেডটি আরও ভাল।

যখন আমি জানতাম যে আমাকে প্রথম বৈকল্পিকের সাথে কিছু যুক্ত করতে হবে যাতে এটি আরও এবং আরও বাড়বে, আমি এগুলি আগে থেকেই এই ছোট ফাংশনগুলিতে বিভক্ত করে দেব, তাই কোড এমনকি কোনও জগাখিচুড়ি হতে শুরু করবে না।


validatingFieldsএকটি ফর্ম ক্ষেত্র যা বৈধতা আছে। প্রথমদিকে, আমি তাদের নাম দিয়েছি fieldsWithValidationতবে এটি কিছুটা দীর্ঘ ছিল।
অ্যালেক্স

0

নামকরণের ক্ষেত্রে সাধারণভাবে সঠিক উত্তর নেই। অনেক লোককে যখন একই একই টাস্কটি দেওয়া হয় তখন ফলস্বরূপ ফাংশন এবং ভেরিয়েবলগুলির নাম খুব আলাদাভাবে দেওয়া হবে। অবশ্যই আপনি চান অন্যরা যারা আপনার কোডটি পড়ে বোঝেন, তবে এর চেয়ে বেশি সময় সবসময় বোঝানো হয় না যে কিছু পরিষ্কার হয়। যদি আপনার কোডটি ঘৃণ্য হয় তবে এটি হওয়া দরকার তারপর আপনার ফাংশনগুলির প্রতিটি লাইন যতটা স্পষ্ট এবং বর্ণনামূলক তা বুঝতে এটি আরও সময় লাগবে।

ব্যক্তিগতভাবে, আমি প্রথম উদাহরণটি আরও পছন্দ করি। এটি সোজা এবং বিন্দুতে এমনকি ভেরিয়েবলগুলির সাথে দ্বিতীয় উদাহরণের মতো বর্ণনামূলক নাম নাও রয়েছে। সত্য, দ্বিতীয় উদাহরণের পরিবর্তনশীল নামগুলি খুব বেশি পরিষ্কার নয় তবে আমার মতে প্রথমটি এবং ফাংশনটি সংক্ষিপ্ত রাখার ফলে ফাংশনটি নিজেই বুঝতে সহজ হয়।

দিনের শেষে, যা আরও ভাল তা আপনার এবং আপনি যার সাথে কাজ করছেন তার উপর নির্ভর করবে। সর্বোপরি, কে এটি পড়বে এবং এটি বজায় রাখবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.