এক্সপ্রেসিভ নাম তৈরির জন্য ৯টি নির্দেশিকা

নামকরণ বিষয়গত এবং পরিস্থিতিগত, এটি একটি শিল্প, এবং বেশিরভাগ শিল্পের মতো, আমরা প্যাটার্ন আবিষ্কার করি। আমি অন্যদের কোড পড়ার মাধ্যমে অনেক কিছু শিখেছি। এই নিবন্ধে, আমি ৯টি নির্দেশিকা সংকলন করেছি যা আমি চেয়েছিলাম অন্যরা যখন আমি তাদের কোড পড়েছি তখন অনুসরণ করেছিল।

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

প্রকার অন্তর্ভুক্ত করবেন না যদি না এটি অভিপ্রায় স্পষ্ট করে

একটি প্রকার যেকোনো কিছু হতে পারে একটি প্রোগ্রামিং প্রকার থেকে (স্ট্রিং, ইন্ট, ডেসিমাল) দায়িত্বের একটি গ্রুপিং পর্যন্ত (ইউটিল, হেল্পার, ভ্যালিডেটর, ইভেন্ট, ইত্যাদি)। প্রায়শই এটি একটি শ্রেণীবিভাগ যা অভিপ্রায় প্রকাশ করে না।

একটি উদাহরণ দেখি: StringHelper নাম বেশি কিছু প্রকাশ করে না। একটি string একটি সিস্টেম প্রকার, এবং Helper অস্পষ্ট, StringHelper “কীভাবে” এর চেয়ে বেশি অভিপ্রায় কথা বলে। যদি আমরা পরিবর্তে নাম DisplayNameFormatter এ পরিবর্তন করি তাহলে আমরা অভিপ্রায়ের একটি স্পষ্টতর চিত্র পাই। DisplayName খুবই নির্দিষ্ট, এবং Formatter ফলাফল প্রকাশ করে। Formatter একটি প্রকার হতে পারে বা নাও হতে পারে, কিন্তু এটি গুরুত্বপূর্ণ নয়, কারণ এটি অভিপ্রায় প্রকাশ করে।

সর্বদা ব্যতিক্রম থাকে; উদাহরণস্বরূপ, ASP.Net MVC-তে, নিয়ন্ত্রকদের অবশ্যই “Controller” দিয়ে শেষ হতে হবে অথবা অ্যাপ্লিকেশন কাজ করে না। ডোমেইন ড্রিভেন ডিজাইন (DDD) এর মতো প্যারাডাইম ব্যবহার করে, “Services,” “Repository,” “ValueType” এবং “Model” এর মতো নামগুলির DDD-তে অর্থ রয়েছে এবং দায়িত্ব প্রকাশ করে।

উদাহরণস্বরূপ, UserRespository বোঝায় যে ব্যবহারকারীর ডেটা পুনরুদ্ধার করা হয় এবং একটি ডেটা স্টোরে সংরক্ষণ করা হয়।

রূপক এড়িয়ে চলুন

রূপকগুলি সাংস্কৃতিক, এবং অন্যান্য সংস্কৃতির ইঞ্জিনিয়াররা অভিপ্রায় বুঝতে পারে না।

যুক্তরাষ্ট্রে সাধারণ রূপক:

• Beating a dead horse
• Chicken or the egg
• Elephant in the room

নিউজিল্যান্ডে সাধারণ রূপক:

• Spit the dummy
• Knackered
• Hard yakka

ক্রিয়াপদ ব্যবহার করুন

Steve Yegge বিশেষ্যের উপর ক্রিয়াপদ ব্যবহার সম্পর্কে একটি (অত্যন্ত দীর্ঘ) ব্লগ পোস্ট লিখেছেন।

তার পয়েন্ট হল ক্রিয়াপদ ব্যবহার করা, অ্যাপ্লিকেশনগুলি বিশেষ্য দিয়ে গঠিত, কিন্তু বিশেষ্যগুলি কিছু করে না। সিস্টেমগুলি শুধুমাত্র বিশেষ্য সহ অকেজো, পরিবর্তে পদ্ধতির নামগুলিতে ক্রিয়া প্রকাশ করুন।

উদাহরণস্বরূপ, UserAuthentication*(বিশেষ্য).AuthenticateUser(ক্রিয়া/ক্রিয়াপদ)* একজন ব্যবহারকারীর শংসাপত্র যাচাই করার ক্রিয়া প্রকাশ করে।

বর্ণনামূলক হন

বর্ণনামূলক হন, যত বেশি বিস্তারিত, তত ভাল — নামে দায়িত্ব প্রকাশ করুন।

নিজেকে জিজ্ঞাসা করুন, এই ক্লাস বা ফাংশন কী একটি জিনিস ভালভাবে করে?

যদি আপনার একটি নাম খুঁজে পেতে অসুবিধা হয়, তাহলে ক্লাস বা ফাংশনের একাধিক দায়িত্ব থাকতে পারে এবং এইভাবে একক দায়িত্ব নীতি লঙ্ঘন করছে।

অভিপ্রায়ের জন্য মন্তব্যের উপর নির্ভর করবেন না

মন্তব্যগুলি কোডে অতিরিক্ত প্রসঙ্গ প্রদানের একটি দুর্দান্ত উপায় কিন্তু মন্তব্যের উপর নির্ভর করবেন না। ক্লাস এবং পদ্ধতির নামগুলি নিজেদের জন্য দাঁড়ানো উচিত।

রিফ্যাক্টরিং: বিদ্যমান কোডের ডিজাইন উন্নত করা, মার্টিন ফাউলার, কেন্ট বেক, জন ব্র্যান্ট, উইলিয়াম অপডাইক এবং ডন রবার্টস দ্বারা:

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

“রিফ্যাক্টরিং” লেখকদের থেকে আরেকটি দুর্দান্ত উদ্ধৃতি:

যখন আপনি একটি মন্তব্য লেখার প্রয়োজন অনুভব করেন, প্রথমে কোডটি রিফ্যাক্টর করার চেষ্টা করুন যাতে যেকোনো মন্তব্য অপ্রয়োজনীয় হয়ে যায়। পৃষ্ঠা ৮৮

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

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

এখানে একটি মন্তব্যকে একটি নামে অন্তর্ভুক্ত করার একটি উদাহরণ।

মন্তব্য সহ:

// without tracking
var user = GetUserByUserId(userId);

পদ্ধতির নামে মন্তব্য অন্তর্ভুক্ত করার জন্য রিফ্যাক্টর করা:

var userWithOutTracking = GetUserByUserIdWithoutTracking(userId);

অন্যান্য ইঞ্জিনিয়াররা এখন জানে যে এই পদ্ধতিতে ট্র্যাকিং নেই যা তারা সোর্স কোড পড়তে বা মন্তব্য খুঁজে পেতে প্রয়োজন হওয়ার আগে।

মন্তব্যগুলি আপনার প্রতিরক্ষার শেষ লাইন হওয়া উচিত যখন সম্ভব অভিপ্রায় প্রকাশ করার অন্যান্য উপায়ের দিকে ঝুঁকুন যার মধ্যে রয়েছে শারীরিক এবং যুক্তি কাঠামো এবং অভিপ্রায় প্রকাশ করার জন্য নাম ব্যবহার করা।

অস্পষ্ট অর্থ সহ নাম ব্যবহার করা থেকে বিরত থাকুন

অস্পষ্ট অর্থ সহ নাম এড়িয়ে চলুন। অস্পষ্ট নামের অর্থ প্রকল্প থেকে প্রকল্পে পরিবর্তিত হয় যা একজন নতুন ইঞ্জিনিয়ারের জন্য অভিপ্রায় বোঝা কঠিন করে তোলে।

এখানে সাধারণ অস্পষ্ট নামগুলির একটি তালিকা রয়েছে:

• Helper
• Input
• Item
• Logic
• Manager
• Minder
• Moniker
• Nanny
• Overseer
• Processor
• Shepherd
• Supervisor
• Thingy
• Utility
• Widget

ব্যবসায়িক ডোমেইনের মতো একই ভাষা ব্যবহার করুন

কোডে ব্যবসায়িক ডোমেইনের মতো একই পরিভাষা ব্যবহার করুন। এটি ইঞ্জিনিয়ার এবং বিষয় বিশেষজ্ঞ (SME) কে সহজেই ধারণা যোগাযোগ করতে দেয় কারণ তারা একই শব্দভাণ্ডার ভাগ করে। যখন একটি ভাগ করা শব্দভাণ্ডার নেই তখন অনুবাদ ঘটে যা অনিবার্যভাবে ভুল বোঝাপড়ার দিকে পরিচালিত করে।

একটি প্রকল্পে যা আমি কাজ করেছিলাম, ব্যবসা “Pupil” দিয়ে শুরু করেছিল এবং তারপর “Student” এ স্যুইচ করেছিল। সফটওয়্যার ইঞ্জিনিয়াররা কখনও পরিভাষা পরিবর্তন প্রতিফলিত করার জন্য সফটওয়্যার আপডেট করেনি। যখন নতুন ইঞ্জিনিয়াররা প্রকল্পে যোগদান করেছিল তখন বেশিরভাগ বিশ্বাস করেছিল যে Pupil এবং Student বিভিন্ন ধারণা ছিল।

শিল্প কথা ব্যবহার করুন

যখন সম্ভব, এমন পরিভাষা ব্যবহার করুন যার সফটওয়্যার শিল্প জুড়ে অর্থ রয়েছে।

বেশিরভাগ সফটওয়্যার ইঞ্জিনিয়ার, যখন তারা “factory” নামের কিছু দেখে, তারা অবিলম্বে ফ্যাক্টরি প্যাটার্ন সম্পর্কে চিন্তা করে।

“ক্লিন আর্কিটেকচার” এবং “ডোমেইন ড্রিভেন ডিজাইন” এর মতো বিদ্যমান অ্যাপ্লিকেশন প্যারাডাইম ব্যবহার করা ধারণা ভাগাভাগি সহজতর করে এবং ইঞ্জিনিয়ারদের জন্য একটি সাধারণ ভাষা তৈরি করে যাতে তারা নিজেদের মধ্যে ধারণা যোগাযোগ করতে পারে।

সবচেয়ে খারাপ সম্ভাব্য নামকরণ হল শিল্প-ব্যাপী পরিভাষা সহ-নির্বাচন করা এবং এটিকে একটি ভিন্ন অর্থ দেওয়া।

বুলিয়ান নামকরণ করার সময়…

বুলিয়ান নামগুলি সর্বদা একটি প্রশ্নের উত্তর হওয়া উচিত যার মূল্য সত্য বা মিথ্যা।

উদাহরণস্বরূপ, isUserAutheticated, উত্তর হয় হ্যাঁ (true) বা না (false)

এর মতো শব্দ ব্যবহার করুন:

• Has
• Does
• Is
• Can

নেতিবাচক নাম এড়িয়ে চলুন, উদাহরণস্বরূপ:

একটি নেতিবাচক পরিবর্তনশীল নাম:

var IsNotDeleted = true; // this is confusing

if(!IsNotDeleted) { // it gets even more confusing when the value is negated
  //Do magic
}

নেতিবাচক পরিবর্তনশীল নাম ছাড়াই:

var IsDeleted = true; // this is confusing

if(!IsDeleted) { 
  //Do magic
}

সমাপনীতে

এক্সপ্রেসিভ নাম নির্বাচন করা পরবর্তী ইঞ্জিনিয়ারের কাছে অভিপ্রায়, ডিজাইন এবং ডোমেইন জ্ঞান যোগাযোগ করার ক্ষেত্রে গুরুত্বপূর্ণ। প্রায়শই আমরা ত্রুটি সংশোধন করতে বা নতুন বৈশিষ্ট্য অন্তর্ভুক্ত করতে কোডে কাজ করি, এবং আমরা ক্রমাগত আমাদের মাথায় কোড সংকলন করছি এটি কীভাবে কাজ করে তা বোঝার চেষ্টা করছি। নামকরণ আমাদের ইঙ্গিত দেয় যে পূর্ববর্তী ইঞ্জিনিয়ার কী চিন্তা করছিল, অতীত এবং ভবিষ্যত ইঞ্জিনিয়ারদের মধ্যে এই যোগাযোগ ছাড়া আমরা অ্যাপ্লিকেশনের বৃদ্ধিতে নিজেদের বাধা দিই। সম্ভবত প্রকল্পটিকে ব্যর্থতার দিকে নিয়ে যাই।