সম্পর্কিত কোডের আগে বা পরে মন্তব্য [বন্ধ]


34

ধরে নিলে মন্তব্যটি যে লাইনে প্রযোজ্য তার উপর ফিট করে না (বা যেতে পারে না), কোডের আগে বা পরে মন্তব্যটি লিখতে হবে?

ঠিক আছে, যেখানেই ভবিষ্যতের পাঠকরা মন্তব্যটির সুযোগটি ভালভাবে বুঝতে পারবেন। অন্য কথায়, যেখানেই বেশিরভাগ প্রোগ্রামার / স্ক্রিপ্টাররা এ জাতীয় মন্তব্য করেন।

তাহলে বেশিরভাগ প্রোগ্রামার / স্ক্রিপ্টাররা কোথায় কোনও মন্তব্য দেয়: এর কোডের আগে বা পরে?

যদি আপনার উত্তরটি কেবল নির্দিষ্ট ভাষায় প্রযোজ্য হয় তবে দয়া করে কোনটি নির্দেশ করুন।

এবং যদি আপনি কোনও গৃহীত স্পেস বা গাইডকে উদ্ধৃত করতে পারেন যা আপনার উত্তরটিকে সমর্থন করে, তবে আরও ভাল।


3
আপনি এটি পরে রাখলে কী ঘটে তা বিবেচনা করে। প্রোগ্রামার কোড পড়েন। নিজেকে বলুন ডাব্লুটিএফ এটি করছে কি ??? মন্তব্য দেখুন। আবার কোড পড়ুন। কিছুক্ষন এটি বুঝতে বা ছেড়ে দিন। তাই সুন্দর হোন এবং উপরের অংশটি রেখে অংশ 1 এবং 2 এড়ান।
ডেডালনিক্স

@ ডিডালনিক্স, ধন্যবাদ, এটি দীপন মেহতার উত্তরটিরও সূচনা বলে মনে হচ্ছে । (এতদূর সমস্ত উত্তরদাতাদেরও ধন্যবাদ, এবং প্রত্যেকে +1।)
এমএস 210

উত্তর:


22

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

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


1
চেকমার্ক, যেহেতু এটিই কেবলমাত্র একমাত্র উত্তর (এতদূর) এই প্রশ্নের পরিষ্কারভাবে উত্তর দেয় যা ব্যক্তিগত পছন্দ নয়, মানক অপারেটিং পদ্ধতি চেয়েছিল, এতে এমএসডিএন উদ্ধৃত করা হয়েছে।
msh210

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

2
@ ফ্যালকন, আমি কখনই হাঙ্গেরীয় নোটেশনের কথা শুনিনি এবং আমার সন্দেহ হয় যে এমএসডিএন এর পছন্দ কমপক্ষে এমএস কর্মীদের ইনপুটের ফলস্বরূপ ছিল; বিপরীতে এখানে উত্তরগুলি পৃথকভাবে রচিত হয়।
এমএস 210

43

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


9

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


7

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

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


6

তাহলে বেশিরভাগ প্রোগ্রামার / স্ক্রিপ্টাররা কোথায় একটি মন্তব্য দেয়: এর কোডের আগে বা পরে?

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

আমি কেবল ব্যতিক্রম হিসাবে ভাবতে পারি এটি একটি পূর্ববর্তী মন্তব্য করা বিভাগের সমাপ্তি হিসাবে চিহ্নিত একটি মন্তব্য, এর মতো:

// BEGIN CRITICAL SECTION
lock(&myMutex);

doSomeThreadUnsafeStuff();

unlock(&myMutex);
// END CRITICAL SECTION

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


4

সত্যই যেখানে প্রয়োজন সেখানে মন্তব্য করার চেষ্টা করুন; কোডটি যখনই সম্ভব হবে তখন স্ব-ডকুমেন্টিং হওয়ার চেষ্টা করা উচিত।

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

// this workaround is required to make the compiler happy
int i = 0;

বনাম

int i = 0; // make the compiler happy

কখনো ও নহে:

int i = 0;
// this workaround is required to make the compiler happy


প্রশ্নটি পুনরায় পড়ুন: এটি পৃথক লাইনে একটি মন্তব্য সম্পর্কে জিজ্ঞাসা করছে তা নির্দিষ্ট করে।
msh210

2
@ msh210 এটি একটি নিখুঁত উত্তর। "আগে মন্তব্য লিখুন"। এটি আরও বিশদযুক্ত এবং একটি সম্ভাব্য কারণ দেয় যা আপনার মনে হতে পারে যে তারা "যখন তারা সংক্ষিপ্ত এবং লাইনের শেষে থাকবে তখন" পরে are
আরডিএস

3

আমি আসলে মন্তব্যের বড় ভক্ত নই। একটি সফ্টওয়্যার ইঞ্জিনিয়ারিং কোর্সের সময় আমার স্ব-ডকুমেন্টিং কোডের ধারণার সাথে পরিচয় হয়েছিল। কোডটি কেবলমাত্র নিজের জন্য 100% গ্যারান্টিযুক্ত সঠিক ডকুমেন্টেশন - মন্তব্যগুলি আপডেট করার, যত্ন সহকারে নির্মিত এবং প্রাসঙ্গিক হওয়া দরকার, অন্যথায় এগুলি ফাঁদগুলি যা কোনও মন্তব্য করার চেয়ে খারাপ হতে পারে। আমি দৃ strict় স্টাইল গাইড এবং অর্থপূর্ণ নামকরণের কনভেনশনগুলির সাথে একটি সি ++ শপটিতে কাজ শুরু না করা পর্যন্ত এটি ছিল না যে আমি এই ধারণাকে সত্যই অভ্যন্তরীণ করে তুলেছি।

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

আপনার প্রশ্নের যে উত্তর ছিল তার বিপরীতে এটি সত্যই আপনার প্রশ্নের ভান ও বৈধতার প্রত্যাখ্যান। আমি এখনও মনে করি এটি প্রাসঙ্গিক এবং আপনাকে সহায়তা করতে পারে, এবং আমি কোনও বোকা ছিলাম না। যদি তা না হয় তবে -1 এরাই আমার উপর কর্তৃত্ব করবে।


10
স্ব-ডকুমেন্টিং কোড "কী" এবং "কীভাবে" জবাব দিতে পারে, তবে যতই ভাল লেখা থাকুক না কেন কোড নিজেই খুব কমই "কেন?" প্রশ্নের উত্তর দিতে পারে। যদি একটি বিস্তৃত প্রয়োজনীয় ডকুমেন্ট থাকে তবে আপনি মাঝে মাঝে উত্তরটি খুঁজে পেতে পারেন। অন্যথায়, কোডগুলি কেন এটি করা উচিত কেন তা করা দরকার তা ব্যাখ্যা করার জন্য মন্তব্যগুলি প্রায়শই থাকে।
এড স্টাব

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

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

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

1
@ কোডস্পার্কল - আমি একমত যে রিফ্যাক্টরিং এড়ানোর অজুহাত হিসাবে ব্যবহৃত মন্তব্যগুলি সাধারণত খারাপ are যাইহোক, এর অর্থ এই নয় যে সমস্ত মন্তব্যগুলি খারাপ, কেবল এই ধরণের মন্তব্যগুলিকে আপত্তি জানানো হয়। বাস্তবতা হল, বেশ কয়েকটি পরিস্থিতি রয়েছে যেখানে প্রতিক্রিয়াশীল কোডিংয়ের প্রয়োজনীয়তা স্পষ্ট করার জন্য মন্তব্যগুলি সত্যই সর্বোত্তম বিকল্প।
ভুয়া নাম

2

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


2

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

if(date == CHRISTMAS){
     //Deliver presents
     val (nice, naughty) = partition(boysAndGirls);
     prepSled();
     findRudolph();
     putOnRedSuit();
     ...
}else{
     //Not Christmas, build toys
     monitorElves();
     ...
}

আপনি যদি পরীক্ষার আগে মন্তব্যটি রাখেন তবে পাঠক মন্তব্যটি প্রাথমিক বিষয় হিসাবে পড়তে ঝুঁকছেন এবং কোডটি ঘনিষ্ঠভাবে না পড়তে পারেন, বুঝতে না পেরে তারা ভুল পথে গেছে:

 //Check to see if it's a leap year
 if(year % 4 == 0){ ... }  

5
আপনার কোড ব্লক উভয়েরই মন্তব্য করার কোডের আগে তাদের মন্তব্য রয়েছে।
msh210

আপনার নিজের মন্তব্যগুলি আপনার "কেস" পরে হি :) এড়িয়ে গেছে এবং এটি ক্রিসমাসের থিমযুক্ত উদাহরণ হিসাবে তৈরি করার জন্য +1 করেছে
আহমেদ মাসুদ

1
@ এমএস 210 আমি প্রথম উদাহরণে আমার মন্তব্যগুলি যদি (ক্রিসমাস) পরীক্ষার উপর মন্তব্য হিসাবে দেখি, তবে নিম্নলিখিত ক্রিয়াকলাপগুলি "সম্পর্কে" না হয়ে (যা তারা বলছে "আমরা এখানে আছি এর অর্থ কী?") তারা পূর্ববর্তী একটি কোড ব্লক, তবে আমি এমন কোডটি কখনও দেখিনি যা ... কোড (); কোড (); / * মন্তব্য পূর্ববর্তী ব্লক * /
expla

1

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

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

এই সম্পর্কের অনুসরণ করে, মন্তব্যটিকে কোডের ব্লকের উপরে উল্লেখ করা আরও উপযুক্ত বলে মনে হচ্ছে।


1

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

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

[blank line]
/* comment */
{ code }
[blank line]

আপনি জানেন যে মন্তব্যটি কোডের সাথে সম্পর্কিত এবং কোডটি কী করে তা আপনাকে জানায়। তবে, আপনি যদি নিম্নলিখিতটি দেখেন:

[blank line]
{ code }
/* comment */
[blank line]

আবার আপনি খুব ভাল করেই জানেন যে মন্তব্যটি সেই কোডের সাথে সম্পর্কিত, এবং কোডটি কী করে তা কী করে সে সম্পর্কে এটি একটি স্পষ্টতা।


যেমন আমি সবসময় বলে থাকি: কোনও ব্যাখ্যা ছাড়াই আপনার ডাউনটোট আমাকে আরও ভাল ব্যক্তি হতে সাহায্য করে না। তোমাকেও ভালবাসি!
মাইক নাকিস

1

উপরের মন্তব্যগুলি সেরা।

যদি আপনাকে মন্তব্যগুলি অন্তর্ভুক্ত করতে হয় এবং আপনার কোডটি স্ব-ব্যাখ্যামূলক নয়, তবে আমি কোডের একটি ব্লকে বিভ্রান্ত হব না, তারপরে "আহ্, এটিই যা করার কথা ছিল" দেখুন।

কোডটি "স্ব ডকুমেন্টিং" হতে পারে (এবং হওয়া উচিত) তবে কোনও পদ্ধতি কীভাবে কাজ করে তা বোঝার জন্য আপনাকে কোডের প্রতিটি লাইন পড়তে এবং বুঝতে হবে। If a summary/ comment found in the last of method then it will be lot of coding time is spent searching for the chunk of code that we wish to edit. By using a summary comment on each block, I can quickly zero in on the block that is relevant to my task.

যখন আমি এই বিষয়টি নিয়ে গুগল করেছি, আমি দেখতে পেলাম যে বেশিরভাগ কম্পিউটারে পঠনযোগ্য ডকুমেন্টেশন সিস্টেমগুলি (ডক এক্সএমএল, ডক্সিজেন, জাভা ডক ইত্যাদি) কোডটির সাথে সম্পর্কিত কোডটির আগে মন্তব্যটি প্রত্যাশা করবে - সেই মানের সাথে সামঞ্জস্য থাকা আরও ভাল।

আমি এসও থ্রেডের সাথেও একমত - আমাদের আগের চেয়ে কোড কোডের পরে মন্তব্য যুক্ত করা উচিত? ..

আমি বরং সামনে জানতাম ...


1

আমি প্রায়শই মন্তব্যগুলিকে (আমার পাশাপাশি অন্যদের দ্বারা লিখিত) ট্রেস লেভেলের লগ স্টেটমেন্টগুলিতে রূপান্তর করি। এটি সাধারণত কোথায় রাখবে তা বোঝা অনেক সহজ করে তোলে ।

    // Return an empty list if we failed to retrieve anything
    // I convert above to:
    logger.trace("Return an empty list if we failed to retrieve anything");

একটি অতিরিক্ত সুবিধা হ'ল শক্ত হয়ে যাওয়ার সময় আমি লগ ট্রেসিং চালু করতে পারি এবং আরও কার্যকর প্রয়োগের লগ পেতে পারি।

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