অভিব্যক্তিপূর্ণ নাম তৈরির জন্য ৯টি নির্দেশিকা

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

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

উদ্দেশ্য স্পষ্ট না করলে টাইপ অন্তর্ভুক্ত করবেন না

একটি টাইপ প্রোগ্রামিং টাইপ (string, int, decimal) থেকে শুরু করে দায়িত্বের গ্রুপিং (Util, Helper, Validator, Event, ইত্যাদি) পর্যন্ত যেকোনো কিছু হতে পারে। প্রায়শই এটি একটি শ্রেণীবিভাগ যা উদ্দেশ্য প্রকাশ করে না।

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

সবসময় ব্যতিক্রম আছে; উদাহরণস্বরূপ, ASP.Net MVC-তে, কন্ট্রোলারগুলি অবশ্যই “Controller” দিয়ে শেষ হতে হবে অথবা অ্যাপ্লিকেশন কাজ করে না। Domain Driven Design (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(ক্রিয়া/ক্রিয়াপদ)* একজন ব্যবহারকারীর শংসাপত্র যাচাই করার ক্রিয়া প্রকাশ করে।

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

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

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

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

উদ্দেশ্যের জন্য মন্তব্যের উপর নির্ভর করবেন না

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

Martin Fowler, Kent Beck, John Brant, William Opdyke, এবং Don Roberts এর Refactoring: Improving the Design of Existing Code বইয়ে:

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

“In Refactoring” লেখকদের আরেকটি চমৎকার উক্তি:

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

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

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

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

মন্তব্য সহ:

// 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” নামের কিছু দেখেন, তারা অবিলম্বে ফ্যাক্টরি প্যাটার্নের কথা ভাবেন।

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

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

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

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

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

এই ধরনের শব্দ ব্যবহার করুন:

• Has
• Does
• Is
• Can

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

একটি নেগেটেড ভেরিয়েবল নাম:

var IsNotDeleted = true; // এটি বিভ্রান্তিকর

if(!IsNotDeleted) { // যখন মানটি নেগেট করা হয় তখন এটি আরও বিভ্রান্তিকর হয়ে ওঠে
  //Do magic
}

নেগেটেড ভেরিয়েবল নাম ছাড়া:

var IsDeleted = true; // এটি বিভ্রান্তিকর

if(!IsDeleted) { 
  //Do magic
}

উপসংহারে

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