কোডিং নিয়ম: সঠিক নাম, ভাল এবং খারাপ মন্তব্যের ক্ষমতা

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

সঠিক নাম

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

টিভি সিরিজ "শার্লক" থেকে (2010-2017)

নামকরণ ইন্টারফেস

ইন্টারফেসে সাধারণত এমন নাম থাকে যেগুলো বড় অক্ষর দিয়ে শুরু হয় এবং ক্যামেলকেসে লেখা হয়। একটি ইন্টারফেস লেখার সময়, এটি একটি ইন্টারফেস হিসাবে মনোনীত করার জন্য "I" উপসর্গ যোগ করার জন্য এটি ভাল অনুশীলন হিসাবে বিবেচিত হত (উদাহরণস্বরূপ, IUserService), কিন্তু এটি দেখতে বেশ কুৎসিত এবং বিভ্রান্তিকর দেখায়। এই ধরনের ক্ষেত্রে, উপসর্গ (UserService) বাদ দেওয়া এবং এর বাস্তবায়নের নামের সাথে প্রত্যয় হিসাবে "Impl" যোগ করা ভাল (যেমন UserServiceImpl)। অথবা সম্ভবত, শেষ অবলম্বন হিসাবে, বাস্তবায়নের নামের সাথে একটি "C" উপসর্গ যোগ করুন (যেমন CUserService)।

ক্লাসের নাম

ঠিক ইন্টারফেসের মতো, ক্লাসের নামগুলি বড় করা হয় এবং CamelCase ব্যবহার করে। আমরা একটি জম্বি অ্যাপোক্যালিপসের মুখোমুখি হচ্ছি কিনা তা বিবেচ্য নয়, শেষটি হাতে আছে কিনা তা বিবেচ্য নয় — কখনই, কখনই না, কখনই কোনও শ্রেণীর নামটি ক্রিয়া হওয়া উচিত নয়! শ্রেণী এবং বস্তুর নাম অবশ্যই বিশেষ্য বা যৌগিক বিশেষ্য হতে হবে (UserController, User Details, UserAccount, এবং তাই)। আপনি প্রতিটি শ্রেণীর নামের শেষে অ্যাপ্লিকেশনের সংক্ষিপ্ত রূপটি ব্যবহার করবেন না, কারণ এটি শুধুমাত্র অপ্রয়োজনীয় জটিলতা যোগ করবে। উদাহরণস্বরূপ, যদি আমাদের একটি ব্যবহারকারী ডেটা মাইগ্রেশন অ্যাপ্লিকেশন থাকে, তাহলে অনুগ্রহ করে প্রতিটি ক্লাসে "UDM" যোগ করবেন না, যেমন UDMUserDetails, UDMUserAccount, UDMUserController।

পদ্ধতির নাম

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

পরিবর্তনশীল নাম

বেশিরভাগ ক্ষেত্রে, ভেরিয়েবলের নাম একটি ছোট হাতের অক্ষর দিয়ে শুরু হয় এবং ক্যামেলকেসও ব্যবহার করে, যখন পরিবর্তনশীলটি একটি বিশ্বব্যাপী ধ্রুবক হয়। এই ধরনের ক্ষেত্রে, নামের সমস্ত অক্ষর বড় হাতের অক্ষরে লেখা হয় এবং শব্দগুলি একটি আন্ডারস্কোর ("_") দ্বারা পৃথক করা হয়। সুবিধার জন্য, আপনি ভেরিয়েবলের নামকরণের সময় অর্থপূর্ণ প্রসঙ্গ ব্যবহার করতে পারেন। অন্য কথায়, যখন একটি ভেরিয়েবল বড় কিছুর অংশ হিসাবে বিদ্যমান থাকে, উদাহরণস্বরূপ, firstName, lastName, বা স্থিতি। এই ধরনের ক্ষেত্রে, আপনি একটি উপসর্গ যোগ করতে পারেন যা এই ভেরিয়েবলটির অন্তর্গত বস্তুটিকে নির্দেশ করে। যেমন: userFirstName, userLastName, userStatus। আপনি ভেরিয়েবলের জন্য অনুরূপ নাম এড়াতে হবে যখন তাদের সম্পূর্ণ ভিন্ন অর্থ থাকে। এখানে পরিবর্তনশীল নামে ব্যবহৃত কিছু প্রায়শই সম্মুখীন বিপরীত শব্দ রয়েছে:

• শুরু/শেষ
• শুরু শেষ
• লক/আনলক
• সর্বনিম্ন/সর্বোচ্চ
• পরবর্তী/পূর্ববর্তী
• পুরাণ নতুন
• খোলা/বন্ধ
• দৃশ্যমান/অদৃশ্য
• উৎস লক্ষ্য
• উৎস গন্তব্য
• উপর নিচ

সংক্ষিপ্ত পরিবর্তনশীল নাম

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

public User findLastUser() {
   return findAllUsers().stream()
           .sorted((x, y) -> -x.getCreatedDate().compareTo(y.getCreatedDate()))
           .findFirst()
           .orElseThrow(() -> new ResourceNotFoundException("No user exists"));
}

এখানে আমরা স্ট্রীম সাজানোর জন্য ছোট-নামযুক্ত ভেরিয়েবল x এবং y ব্যবহার করি এবং তারপরে আমরা সেগুলি ভুলে যাই।

সর্বোত্তম দৈর্ঘ্য

নামের দৈর্ঘ্যের বিষয়টি নিয়ে চলুন। সর্বোত্তম নামের দৈর্ঘ্য n এবংmaxNumberOfUsersInTheCurrentGroup-এর মধ্যে কোথাও। অন্য কথায়, সংক্ষিপ্ত নামগুলি অর্থের অভাবে ভুগছে, যখন যে নামগুলি খুব বেশি লম্বা সেগুলি পাঠযোগ্যতা যোগ না করেই প্রোগ্রামটিকে দীর্ঘায়িত করে এবং আমরা প্রতিবার সেগুলি লিখতে খুব অলস। n-এর মতো সংক্ষিপ্ত নামের ভেরিয়েবলের জন্য উপরে বর্ণিত কেস ছাড়াও, আপনাকে প্রায় 8-16 অক্ষরের দৈর্ঘ্যে আটকে রাখতে হবে। এটি একটি কঠোর নিয়ম নয়, শুধুমাত্র একটি নির্দেশিকা।

ছোট পার্থক্য

আমি নামের সূক্ষ্ম পার্থক্য উল্লেখ করতে ব্যর্থ হতে পারে না. এটি একটি খারাপ অভ্যাস, যেহেতু এই পার্থক্যগুলি কেবল বিভ্রান্তিকর হতে পারে বা সেগুলি লক্ষ্য করার জন্য অনেক অতিরিক্ত সময় ব্যয় করতে হবে। উদাহরণস্বরূপ, InvalidDataAccessApiUsageException এবং InvalidDataAccessResourceUsageException এর মধ্যে পার্থক্য এক নজরে ধরা কঠিন। ছোট হাতের L এবং O ব্যবহার করার সময়ও প্রায়শই বিভ্রান্তি দেখা দিতে পারে, কারণ তাদের সহজেই 1 এবং 0 এর জন্য ভুল করা যেতে পারে। কিছু ফন্টে পার্থক্যটি আরও স্পষ্ট, কিছুতে কম।

অর্থ

আমাদের নামগুলিকে অর্থপূর্ণ করতে হবে, কিন্তু প্রতিশব্দের মাধ্যমে অস্পষ্টতা তৈরি করতে হবে না, যেহেতু, উদাহরণস্বরূপ, UserData এবং UserInfo আসলে একই অর্থ রয়েছে। এই ক্ষেত্রে, আমাদের কোন নির্দিষ্ট বস্তুর প্রয়োজন তা বোঝার জন্য আমাদের কোডের গভীরে খনন করতে হবে। এমন শব্দগুলি এড়িয়ে চলুন যা সহায়ক তথ্য প্রকাশ করে না। উদাহরণস্বরূপ, firstNameString-এ, কেন আমাদের স্ট্রিং শব্দটি দরকার? এই সত্যিই একটি তারিখ বস্তু হতে পারে? অবশ্যই না. সুতরাং, আমরা কেবল firstName ব্যবহার করি। আমি বুলিয়ান ভেরিয়েবল উল্লেখ করতে চাই। একটি উদাহরণ হিসাবে, flagDeleted নামের একটি বুলিয়ান নিন। পতাকা শব্দের কোনো অর্থ নেই। এটিকে মুছে ফেলা বলা আরও যুক্তিসঙ্গত।

গুজব

আমি ভুল নামকরণ প্রথা সম্পর্কে কিছু শব্দ বলতে চাই। ধরা যাক আমাদের userActivityList নামে একটি ভেরিয়েবল আছে, কিন্তু একটি তালিকা হওয়ার পরিবর্তে, এই অবজেক্টটি অন্য কোনো কন্টেইনার টাইপ বা কাস্টম স্টোরেজ অবজেক্ট। এটি গড় প্রোগ্রামারকে বিভ্রান্ত করতে পারে: এটিকে userActivityGroup বা userActivities এর মতো কিছু বলা ভাল।

অনুসন্ধান করুন

সংক্ষিপ্ত এবং সাধারণ নামের একটি ত্রুটি হল যে কোডের একটি বড় অংশে এগুলি খুঁজে পাওয়া কঠিন — কোনটি খুঁজে পাওয়া সহজ হবে: "নাম" বা "NAME_FOR_DEFAULT_USER"? দ্বিতীয় বিকল্প, অবশ্যই। আমাদের নামগুলিতে প্রায়শই সম্মুখীন হওয়া শব্দগুলি (অক্ষরগুলি) এড়ানো উচিত, কারণ তারা অনুসন্ধানের সময় কেবল মিলে যাওয়া ফাইলের সংখ্যা বাড়িয়ে তুলবে, যা ভাল নয়৷ আমি আপনাকে মনে করিয়ে দিতে চাই যে প্রোগ্রামাররা কোড লেখার চেয়ে বেশি সময় ব্যয় করে, তাই আপনার অ্যাপ্লিকেশনের উপাদানগুলির নামকরণের বিষয়ে স্মার্ট হন। কিন্তু যদি একটি ভাল নাম খুঁজে পাওয়া যায় না? যদি একটি পদ্ধতির নাম তার কার্যকারিতা ভালভাবে বর্ণনা না করে তবে কী হবে? এখানেই মন্তব্য মঞ্চে প্রবেশ করে।

মন্তব্য

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

মন্তব্যের প্রকারভেদ

• আইনি মন্তব্য — আইনি কারণে প্রতিটি উৎস ফাইলের শুরুতে মন্তব্য, উদাহরণস্বরূপ:

  
  * Copyright (c) 2007, 2013, Oracle and/or its affiliates. All rights reserved.
  * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
  

• তথ্যমূলক মন্তব্য — কোডের একটি ব্যাখ্যা প্রতিনিধিত্বকারী মন্তব্য (অতিরিক্ত তথ্য প্রদান করা বা কোডের একটি প্রদত্ত বিভাগের উদ্দেশ্য ব্যাখ্যা করা)।

  উদাহরণ স্বরূপ:

  
  /*
  * Combines the user from the database with the one passed for updating
  * When a field in requestUser is empty, it is filled with old data from foundUser
  */
  private User mergeUser(User requestUser, User foundUser) {
         return new User(
         foundUser.getId(),
         requestUser.getFirstName() == null ? requestUser.getFirstName() : foundUser.getFirstName(),
         requestUser.getMiddleName() == null ? requestUser.getMiddleName() : foundUser.getMiddleName(),
         requestUser.getLastName() == null ? requestUser.getLastName() : foundUser.getLastName(),
         requestUser.getAge() == null ? requestUser.getAge() : foundUser.getAge()
         );
         }
  

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

• সতর্কতামূলক মন্তব্য — মন্তব্যটি অন্য ডেভেলপারদের একটি কর্মের অনাকাঙ্খিত পরিণতি সম্পর্কে সতর্ক করার উদ্দেশ্যে করা হয়েছে (উদাহরণস্বরূপ, কেন একটি পরীক্ষাকে @Ignore হিসাবে চিহ্নিত করা হয়েছে সে সম্পর্কে তাদের সতর্ক করা):

  
  // Takes too long to run
  // Don't run if you don't have a lot of time
  @Ignore
  @Test
  public void someIntegrationTest() {
         ……
         }
  

• TODO — মন্তব্যগুলি এমন কিছু সম্পর্কে একটি নোট যা ভবিষ্যতে করা দরকার যা এখন করা যাবে না। এটি একটি ভাল অভ্যাস, তবে অপ্রাসঙ্গিক বিষয়গুলি সরাতে এবং বিশৃঙ্খলা এড়াতে এই জাতীয় মন্তব্যগুলি নিয়মিত পর্যালোচনা করা উচিত।

  একটি উদাহরণ হবে:

  
  // TODO: Add a check for the current user ID (when the security context is created)
  
  @Override
  public Resource downloadFile(File file) {
         return fileManager.download(file);
         }
  

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

• মন্তব্যগুলিকে শক্তিশালী করা — এমন একটি পরিস্থিতির গুরুত্বের উপর জোর দেওয়া মন্তব্য যা প্রথম নজরে তুচ্ছ মনে হতে পারে।

  একটি উদাহরণ হিসাবে, একটি পদ্ধতির একটি অংশ বিবেচনা করুন যা কিছু স্ক্রিপ্ট সহ একটি পরীক্ষা ডাটাবেস পূরণ করে:

  
  Stream.of(IOUtils.resourceToString("/fill-scripts/" + x, StandardCharsets.UTF_8)
         .trim()
         .split(";"))
         .forEach(jdbcTemplate::update);
  // The trim() call is very important. It removes possible spaces at the end of the script
  // so that when we read and split into separate requests, we don't end up with empty ones
  

• Javadoc মন্তব্য - মন্তব্য যা নির্দিষ্ট কার্যকারিতার জন্য API বর্ণনা করে। সম্ভবত সবচেয়ে দরকারী মন্তব্য আছে, যেহেতু নথিভুক্ত API এর সাথে কাজ করা অনেক সহজ। যে বলেছে, সেগুলিও অন্য যেকোনো ধরনের মন্তব্যের মতো সেকেলে হতে পারে। সুতরাং, কখনই ভুলে যাবেন না যে ডকুমেন্টেশনের প্রধান অবদান মন্তব্য দ্বারা নয়, ভাল কোড দ্বারা তৈরি করা হয়।

  এখানে একটি ব্যবহারকারী আপডেট করার জন্য একটি মোটামুটি সাধারণ পদ্ধতির একটি উদাহরণ:

  
  /**
  * Updates the passed fields for a user based on its id.
       *
  * @param id id of the user to be updated
  * @param user user with populated fields for updating
  * @return updated user
  */
         User update(Long id, User user);
  

বাজে মন্তব্য

• বিড়বিড়কারী মন্তব্য — যে মন্তব্যগুলি সাধারণত তাড়াহুড়ো করে লেখা হয় এবং যার অর্থ শুধুমাত্র সেই বিকাশকারীর কাছেই বোধগম্য যে সেগুলি লিখেছেন, কারণ মন্তব্যটি যে সংক্ষিপ্ত পরিস্থিতিকে নির্দেশ করে শুধুমাত্র তিনিই বুঝতে পারেন৷

  এই উদাহরণ বিবেচনা করুন:

  
  public void configureSomeSystem() {
         try{
         String configPath = filesLocation.concat("/").concat(CONFIGURATION_FILE);
         FileInputStream stream = new FileInputStream(configPath);
         } catch (FileNotFoundException e) {
         // If there is no configuration file, the default configuration is loaded 
        }
  }
  

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

• অপ্রয়োজনীয় মন্তব্য — এমন মন্তব্য যা কোনো শব্দার্থিক ভার বহন করে না, যেহেতু কোডের একটি প্রদত্ত বিভাগে যা ঘটছে তা প্রচুর পরিমাণে পরিষ্কার। অন্য কথায়, কোডের চেয়ে মন্তব্যটি পড়া সহজ নয়।

  আসুন একটি উদাহরণ দেখি:

  
  public class JdbcConnection{
  public class JdbcConnection{
     /**
      * The logger associated with the current class
      */
     private Logger log = Logger.getLogger(JdbcConnection.class.getName());
  
     /**
      * Creates and returns a connection using the input parameters
      */
     public static Connection buildConnection(String url, String login, String password, String driver) throws Exception {
         Class.forName(driver);
         connection = DriverManager.getConnection(url, login, password);
         log.info("Created connection with db");
         return connection;
     }
  

  এমন মন্তব্য করে লাভ কি? তারা যা ব্যাখ্যা করেছে তা ইতিমধ্যেই পুরোপুরি পরিষ্কার।

• অবিশ্বস্ত মন্তব্য - যে মন্তব্যগুলি অসত্য এবং শুধুমাত্র বিভ্রান্তিকর (বিভ্রান্তি)। উদাহরণস্বরূপ, এখানে একটি.

  
  /**
  * Helper method. Closes the connection with the scanner if isNotUsing is true
  */
  private void scanClose(Scanner scan, boolean isNotUsing) throws Exception {
     if (!isNotUsing) {
         throw new Exception("The scanner is still in use");
     } scan.close();
  }
  

  এই মন্তব্যে ভুল কি? সত্য যে এটি আমাদের কাছে কিছুটা মিথ্যা বলে, এতে সংযোগটি বন্ধ হয়ে যায় যদি isNotUsing মিথ্যা হয়, উল্টো নয়, মন্তব্যটি আমাদের জানায়।

• বাধ্যতামূলক মন্তব্য — যে মন্তব্যগুলি বাধ্যতামূলক বলে বিবেচিত হয় (যেমন জাভাডক মন্তব্য), কিন্তু যেগুলি কখনও কখনও অত্যধিকভাবে জমা হয় এবং অবিশ্বাস্য এবং অপ্রয়োজনীয় (আপনাকে এই মন্তব্যগুলি আসলে প্রয়োজন কিনা তা নিয়ে ভাবতে হবে)।

উদাহরণ:

/**
* Create a user based on the parameters
* @param firstName first name of the created user
* @param middleName middle name of the created user
* @param lastName last name of the created user
* @param age age of the created user
* @param address address of the created user
* @return user that was created
*/
User createNewUser(String firstName, String middleName, String lastName, String age, String address);

আপনি এই মন্তব্য ছাড়া পদ্ধতি কি বুঝতে সক্ষম হবে? সম্ভবত, হ্যাঁ, তাই মন্তব্য এখানে অর্থহীন হয়ে ওঠে।

• লগ মন্তব্য — মন্তব্য যেগুলি কখনও কখনও একটি মডিউলের শুরুতে প্রতিবার সম্পাদনা করার সময় যোগ করা হয় (একটি পরিবর্তন লগের মতো কিছু)।

  
  /**
  * Records kept since January 9, 2020;
  **********************************************************************
  * 9 Jan 2020: Providing a database connection using JDBC Connection;
  * 15 Jan 2020: Adding DAO-level interfaces for working with the database;
  * 23 Jan 2020: Adding integration tests for the database;
  * 28 Jan 2020: Implementation of DAO-level interfaces;
  * 1 Feb 2020: Development of interfaces for services,
  * in accordance with the requirements specified in user stories;
  * 16 Feb 2020: Implementation of service interfaces
  * (implementation of business logic related to the work of the database);
  * 25 Feb 2020: Adding tests for services;
  * 8 Mar 2020: Celebration of International Women's Day (Terry is drunk again);
  * 21 Mar 2020: Refactoring the service layer;
  */
  

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

• লেখক মন্তব্য — মন্তব্য যার উদ্দেশ্য হল সেই ব্যক্তিকে নির্দেশ করা যিনি কোড লিখেছেন, যাতে আপনি তার সাথে যোগাযোগ করতে পারেন এবং কীভাবে, কী এবং কেন আলোচনা করতে পারেন, যেমন:

  
  * @author Bender Bending
  

  আবারও, সংস্করণ নিয়ন্ত্রণ ব্যবস্থা ঠিক মনে রাখে কে কোন বিট কোড এবং কখন যোগ করেছে, তাই এই পদ্ধতিটি অপ্রয়োজনীয়।

• মন্তব্য করা-আউট কোড — কোড যা এক বা অন্য কারণে মন্তব্য করা হয়েছে। এটি সবচেয়ে খারাপ অভ্যাসগুলির মধ্যে একটি, কারণ যা ঘটে তা হল আপনি কিছু মন্তব্য করেন এবং এটি ভুলে যান এবং তারপরে অন্যান্য বিকাশকারীরা এটি মুছে ফেলার সাহস পান না (সবার পরে, যদি এটি মূল্যবান কিছু হয়?)

  
  //    public void someMethod(SomeObject obj) {
  //    .....
  //    }
  

  ফলস্বরূপ, মন্তব্য করা কোড ট্র্যাশের মতো জমা হয়। কোন ক্ষেত্রেই আপনি এই ধরনের কোড ছেড়ে যাবেন না। আপনি যদি সত্যিই এটি প্রয়োজন, সংস্করণ নিয়ন্ত্রণ সিস্টেম সম্পর্কে ভুলবেন না.

• অ-স্পষ্ট মন্তব্য - মন্তব্য যেগুলি অত্যধিক জটিল উপায়ে কিছু বর্ণনা করে।

  
  /*
      * Start with an array large enough to store
      * all the data bytes (plus filter bytes) with a cushion, plus 300 bytes
      * for header data
      */
  this.dataBytes = new byte[(this.size * (this.deep + 1) * 2)+300];
  

  একটি মন্তব্য কোড ব্যাখ্যা করা উচিত. এটি নিজেই একটি ব্যাখ্যা প্রয়োজন হবে না. তাই এখানে ভুল কি? "ফিল্টার বাইট" কি? যে "+1" সব সম্পর্কে কি? কেন ঠিক 300?

আপনি যদি ইতিমধ্যে মন্তব্য লেখার সিদ্ধান্ত নিয়ে থাকেন তবে এখানে কয়েকটি টিপস রয়েছে:

1. রক্ষণাবেক্ষণ করা সহজ শৈলী ব্যবহার করুন: খুব অভিনব এবং বহিরাগত শৈলী বজায় রাখা বিরক্তিকর এবং সময়সাপেক্ষ।
2. লাইনের শেষের মন্তব্যগুলি ব্যবহার করবেন না যা একক লাইনকে নির্দেশ করে: ফলাফলটি মন্তব্যের একটি বড় স্তূপ। আরও কি, প্রতিটি লাইনের জন্য একটি অর্থপূর্ণ মন্তব্য চিন্তা করা কঠিন।
3. আপনি যখন একটি মন্তব্য রচনা করেন, "কেন" প্রশ্নের উত্তর দেওয়ার চেষ্টা করুন, "কিভাবে" নয়।
4. সংক্ষিপ্ত তথ্য এড়িয়ে চলুন। আমি উপরে বলেছি, আমাদের একটি মন্তব্যের জন্য একটি ব্যাখ্যা প্রয়োজন নেই: মন্তব্য নিজেই ব্যাখ্যা.
5. আপনি একক এবং মান পরিসীমা নোট করতে মন্তব্য ব্যবহার করতে পারেন.
6. তাদের বর্ণনা করা কোডের কাছাকাছি মন্তব্য রাখুন।

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