কোড রক্ষণাবেক্ষণ: কোডে মন্তব্য যুক্ত করতে বা এটি কেবল সংস্করণ নিয়ন্ত্রণে রেখে যেতে চান?

Question

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

আমার উদ্বেগ হ'ল, এটি কি কোনও অতিরিক্ত মূল্য সরবরাহ করে? যেমনটি রয়েছে, আমাদের কাছে সংস্করণ নিয়ন্ত্রণের ইতিহাসে সমস্ত বিবরণ রয়েছে, যা আমাদের প্রতিটি পরিবর্তন ট্র্যাক করতে সহায়তা করবে?

তবে আমার সীসাগুলি মন্তব্যগুলিকে একটি "ভাল" প্রোগ্রামিং অনুশীলন হিসাবে রাখার জন্য জোর দিচ্ছে। তাদের যুক্তিগুলির মধ্যে একটি হ'ল যখন কোনও সিআর-কে ডি-স্কোপ / পরিবর্তন করতে হয়, মন্তব্যগুলি না থাকলে এটি জটিল umbers

পরিবর্তনগুলি মূলত কোডের মধ্যে থাকবে বলে বিবেচনা করে, আমরা কি প্রতিটি পরিবর্তনের জন্য মন্তব্য যুক্ত করতে সত্যই সহায়তা করবে? আমাদের কি এটি সংস্করণ নিয়ন্ত্রণে রেখে দেওয়া উচিত নয়?

Answer 1

তুমি একদম সঠিক. পরিবর্তনগুলি ট্র্যাক করা আপনার সংস্করণ নিয়ন্ত্রণ সিস্টেমের কাজ। প্রতিবার আপনি যখন কোন কমিট করেন তখন আপনাকে কী করা হয়েছিল তা বোঝাতে একটি কমিট বার্তা লিখতে হবে এবং এটি যদি কোনও বাগ ফিক্স হয় তবে আপনার বাগ-ট্র্যাকিং সিস্টেমটি উল্লেখ করতে হবে। কোডে মন্তব্য করে বলছি

// begin fix for bug XXXXX on 10/9/2012
...
// end fix for bug XXXXX

প্রতিবার আপনি যখন কোনও বাগ ফিক্স করেন তাড়াতাড়ি আপনার কোডটি অপঠনযোগ্য এবং অবিশ্বাস্য রেন্ডার করে দেবে। এটি একই স্থানে দুটি জায়গায় একই তথ্য নকল করার ফলস্বরূপ, গণ্ডগোলকে আরও খারাপ করে দেবে।

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

পরিবর্তে তাই

// fixed bug XXXXX on 10/9/2012

আপনার মতামত থাকতে পারে

// doing X, because otherwise Y will break.

অথবা

// doing X, because doing Y is 10 times slower.

Comments

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

— এরিক ডায়েটারিচ

Answer 2

কাজের জন্য সেরা সরঞ্জামটি ব্যবহার করুন। আপনার সংস্করণ নিয়ন্ত্রণ সিস্টেমটি যখন বাগ বাগ এবং সিআর তৈরি করা হয় তখন রেকর্ডিংয়ের সেরা সরঞ্জাম হওয়া উচিত : এটি স্বয়ংক্রিয়ভাবে তারিখটি রেকর্ড করে এবং কে পরিবর্তন করেছে; এটি কোনও বার্তা যুক্ত করতে কখনই ভুলে যায় না (যদি আপনি এটির জন্য প্রতিশ্রুতি বার্তাগুলি প্রয়োজন কনফিগার করেছেন); এটি কোডের ভুল লাইনটি কখনই মন্তব্য করে না বা ঘটনাক্রমে কোনও মন্তব্য মুছে দেয়। এবং যদি আপনার সংস্করণ নিয়ন্ত্রণ সিস্টেমটি ইতিমধ্যে আপনার মন্তব্যের চেয়ে ভাল কাজ করছে, মন্তব্য যুক্ত করে ডুপ্লিকেট করা কাজটি বোকা।

উত্স কোডের পঠনযোগ্যতা সর্বজনীন। এমন একটি কোডবেস যা মন্তব্যে বিশৃঙ্খলাযুক্ত প্রতিটি বাগফিক্স এবং সিআর তৈরির পুরো ইতিহাস দেবে তা মোটেও পঠনযোগ্য হবে না।

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

Comments

আমি এক জিনিস বাদে সম্মত: fix ISSUE#413কোড ভাল মন্তব্য নয়। আপনার বাহ্যিক ডকুমেন্টেশন উল্লেখ না করে কোড বুঝতে সক্ষম হওয়া উচিত। এলোমেলো নম্বর দেওয়ার পরিবর্তে, কোডটির এই কৌতুকপূর্ণ অংশটি কী করা প্রয়োজন তা আসলে ব্যাখ্যা করুন। মন্তব্যগুলির জন্য এটিই: কোডের সেই অংশগুলিকে ব্যাখ্যা করার জন্য যা সুস্পষ্ট নয়।

— অকর্মা

@ পোক - এটি নির্দেশ করার জন্য আপনাকে ধন্যবাদ। আমার ধারণা আমার যুক্ত করা উচিত যে আমি ফর্মটির মন্তব্যগুলি ব্যবহার করার একমাত্র জায়গা fix ISSUE#413যেখানে সমস্যাটি এত জটিল (একটি অত্যন্ত ওএস- এবং কনফিগারেশন-নির্ভর কোণার কেস, বা কেবল কোনও নির্দিষ্ট খারাপ গ্রাহকের ডেটা দ্বারা ট্রিগার করা) যথেষ্ট পরিমাণে বর্ণনা করলে এটি গ্রহণ করতে পারে অনুচ্ছেদ দুটি; এই ধরণের জিনিসটি ইস্যু ট্র্যাকার, আইএমও দ্বারা আরও ভালভাবে পরিচালনা করা হয়। তারপরেও, একরকম সংক্ষিপ্ত বিবরণটি ভাল।

— জোশ কেলি

@ পোকে: আমি বলব যে একটি মন্তব্য যেটির সাথে শুরু হবে fix ISSUE#413 তা পুরোপুরি সূক্ষ্ম এবং এমনকি আরও বেশি ভাল, যতক্ষণ না এটি # 413 ইস্যু কী তা সম্পর্কে যুক্তিসঙ্গত তথ্য সরবরাহ করে। ইস্যু রিপোর্টকে কেবলমাত্র কোনও পয়েন্টার না দিয়ে সংক্ষিপ্ত করে তা ভবিষ্যতের পাঠকের পক্ষে জীবনকে আরও জটিল করে তোলে যার সমস্ত বিবরণ প্রয়োজন।

— কিথ থম্পসন

আমি পোকার সাথে একমত - আপনার কোডটি বোঝার জন্য কোনও বাহ্যিক উত্সকে কখনও উল্লেখ করা উচিত নয়। যদি আমি কোনও পরিবর্তন পর্যালোচনা করি তবে এটি প্রবাহকে ভঙ্গ করে। আমাকে ইস্যু ট্র্যাকারে যেতে হবে, ইস্যুটি টানতে হবে, এবং এটি সম্পর্কে সমস্ত পড়তে হবে। এবং যদি আপনি ইস্যু ট্র্যাকারগুলি পরিবর্তন করেন তবে কী হবে? fix ISSUE#413সম্পূর্ণতার জন্য মন্তব্যে রাখা ভাল হতে পারে , তবে এটি ক্রাচ হিসাবে ব্যবহার করবেন না।

— মাইকেল ডিন

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

— অ্যান্ডি

Answer 3

কোডে মন্তব্য কি কোড চলেছেন হয় সেই মুহুর্তে। যে কোনও সময় স্ন্যাপশট নেওয়া কোডটির পুরানো (বা আরও খারাপ, ভবিষ্যতের) সংস্করণগুলিকে উল্লেখ করা উচিত নয়।

কোডটি কীভাবে পরিবর্তন হয়েছে সে সম্পর্কে ভিসিএসের মন্তব্যসমূহ। তাদের উন্নয়নের গল্প হিসাবে পড়া উচিত।

এখন, প্রতিটি পরিবর্তনে মন্তব্য অন্তর্ভুক্ত করা উচিত? বেশিরভাগ ক্ষেত্রে, হ্যাঁ কেবলমাত্র ব্যতিক্রমটি আমি কল্পনা করি যখন প্রত্যাশিত আচরণটি ইতিমধ্যে নথিভুক্ত হয়েছিল তবে বাগের কারণে আপনি যা পেয়েছিলেন তা নয়। এটিকে ঠিক করা বিদ্যমান মন্তব্যগুলিকে আরও সুনির্দিষ্ট করে তোলে তাই তাদের পরিবর্তন করার দরকার নেই। বাগটি নিজেই টিকিটের ইতিহাসে এবং কমিট কমেন্টে নথিভুক্ত করা উচিত, তবে কোডটি অদ্ভুত লাগলে কেবল কোডে। সেক্ষেত্রে একটি // make sure <bad thing> doesn't happenপর্যাপ্ত হওয়া উচিত।

Comments

আমি এটিকে উজ্জীবিত করব, তবে আমি "প্রতিটি পরিবর্তনে মন্তব্য অন্তর্ভুক্ত করা উচিত? বেশিরভাগ ক্ষেত্রে হ্যাঁ" এর সাথে আমি একমত হতে পারি না। একটি চেক ইন / কমিট মন্তব্য, হ্যাঁ, একেবারে। কোড মন্তব্য, অবশ্যই প্রয়োজন হয় না।

— একটি সিভিএন

Answer 4

আমি সত্যিই প্রশংসা করি এমন এক ধরণের মন্তব্য হ'ল:

// এটি প্রস্তাব 2 এর বিধি বিধি 5 এর জন্য কার্যকর করা হয়েছে

বা আপনার প্রয়োজনীয়তা সংগ্রহ করতে আপনি যা কিছু হেক ব্যবহার করেন না কেন।

এর দুটি সুবিধা রয়েছে, একটি হ'ল এটি আপনাকে অনুসন্ধান না করে একটি প্রদত্ত অ্যালগরিদম কার্যকর করার কারণটি সন্ধান করতে দেয় এবং অন্যটি হ'ল এটি আপনাকে নন-সফটওয়্যার ইঞ্জিনিয়ারদের সাথে যোগাযোগ করতে সহায়তা করবে যা প্রয়োজনীয় ডক্সগুলিতে কাজ করে / তৈরি করে।

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

Comments

এটি ভিন্ন তবে কারণ এটি সংস্করণ নিয়ন্ত্রণের জন্য একটি অলঙ্কৃতকরণ সরবরাহ করে: কোডটি এবং এটি প্রয়োগ করে প্রয়োজনীয় স্পেসিফিকেশনের মধ্যে সংযোগ।

— কাজ

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

— আইভেল

Answer 5

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

Answer 6

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

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

খুব অল্প ব্যতিক্রম ব্যতীত পরিবর্তন ট্র্যাকিং এবং ইস্যু রেফারেন্সিং হ'ল ভিসিএস, আইএমএনএসএইচও এর কাজ।

Answer 7

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

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

Answer 8

সংস্করণ-নিয়ন্ত্রণ সম্পর্কিত মন্তব্যগুলি উত্স ফাইলে অন্তর্ভুক্ত নয়। তারা কেবল বিশৃঙ্খলা যুক্ত করে। যেহেতু তাদের একই জায়গায় স্থাপন করা প্রয়োজন (ফাইলটির শীর্ষে একটি মন্তব্য ব্লকের মতো) যখন সমান্তরাল শাখাগুলি মার্জ করা হয় তখন তারা কেবল মন্তব্য-উপদ্রব বিবাদ সৃষ্টি করবে।

সংস্করণ নিয়ন্ত্রণের বাইরে টানা যেতে পারে এমন কোনও ট্র্যাকিংয়ের তথ্য কোডের মূল অংশে নকল করা উচিত নয়। এটি আরসিএস চেকআউট কীওয়ার্ডগুলির মতো মূর্খ ধারণাগুলির জন্য $Log$এবং এর জাতীয় বিষয়গুলির জন্য যায়।

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

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

Answer 9

কোডে মন্তব্যগুলি ন্যূনতম এবং নির্ভুল হওয়া উচিত। ত্রুটি যুক্ত / পরিবর্তন তথ্য মূল্যবান নয়। আপনার এটির জন্য সংস্করণ নিয়ন্ত্রণ ব্যবহার করা উচিত। কিছু সময় সংস্করণ নিয়ন্ত্রণ পরিবর্তনের কিছুটা ভালতর উপায় সরবরাহ করে- আমরা ক্লিয়ারকেস ইউসিএম ব্যবহার করি; ইউসিএম ক্রিয়াকলাপগুলি ত্রুটি সংখ্যা, পরিবর্তন অঞ্চল ইত্যাদির উপর ভিত্তি করে তৈরি করা হয় (উদাহরণস্বরূপ ত্রুটি 29844_চেঞ্জ_সক্লোল_ থেকে_হ্যান্ডল_নুল)।

বিস্তারিত মন্তব্যগুলি চেক-ইন মন্তব্যে পছন্দ করা হয়।

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

প্রাম্যাগিক প্রোগ্রামার এবং ক্লিনকোড নিম্নলিখিত নির্দেশিকাগুলির দিকে নিয়ে যায়

কোডটি নিম্ন-স্তরের জ্ঞানকে যেখানে রাখে তা রাখুন এবং অন্যান্য, উচ্চ-স্তরের ব্যাখ্যার জন্য মন্তব্যগুলি সংরক্ষণ করুন।