স্ব ডকুমেন্টিং কোড বনাম মন্তব্য কোড

Question

আমার একটি অনুসন্ধান ছিল কিন্তু আমি যা খুঁজছিলাম তা পাইনি, দয়া করে এই লিঙ্কটি যদি ইতিমধ্যে জিজ্ঞাসা করা হয় তবে আমাকে লিঙ্ক করতে দ্বিধা বোধ করবেন।

এই মাসের শুরুর দিকে এই পোস্টটি করা হয়েছিল:

http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/

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

দেওয়া উদাহরণে

// Get the extension off the image filename  
$pieces = explode('.', $image_name);  
$extension = array_pop($pieces);  

লেখক বলেছেন এই কোডটি একটি মন্তব্য দেওয়া উচিত, আমার ব্যক্তিগত মতামতটি কোডটি একটি ফাংশন কল হওয়া উচিত যা বর্ণনামূলক:

$extension = GetFileExtension($image_filename);

তবে মন্তব্যে কেউ আসলে ঠিক সেই পরামর্শ দিয়েছে:

http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/comment-page-2/#comment-357130

লেখক প্রতিক্রিয়া জানিয়ে মন্তব্য করেছিলেন যে "মন্তব্যকারী" সেই লোকগুলির মধ্যে একজন ", অর্থাত্ একটি খারাপ প্রোগ্রামার।

স্ব-বর্ণনার কোড বনাম মন্তব্য কোডের প্রত্যেকে এলিজের দৃষ্টিভঙ্গি কী?

Comments

@ পিটার - আমি সেটির দিকে একবার নজর রেখেছি তবে আমি মন্তব্যগুলির কোড-গন্ধ বা সংজ্ঞা হিসাবে সংজ্ঞায়নের পরিবর্তে দুজনের মধ্যে জনগণের ব্যক্তিগত মতামত পেতে আগ্রহী ছিলাম।

— Phill

আমি নিবন্ধটি পড়তে .... পড়তে ভয়ঙ্কর। খুব অপমানজনক।

— সেভেনসিয়াট

@Karpie - আমার কি :( করেনি

— Phill

"কেন আপনি খারাপ পিএইচপি প্রোগ্রামার" উত্তর: কারণ আপনি পিএইচপি-তে প্রোগ্রামিং করছেন।

— টমাস এডিং

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

— ডালিন

Answer 1

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

অবশ্যই এটির অর্থ এই নয় যে কেউ কখনও মন্তব্য ব্যবহার করা উচিত নয় - তাদের ভূমিকা রয়েছে তবে আইএমএইচও আপনার এগুলি যত্ন সহকারে ব্যবহার করা উচিত। এসও-তে আমার এই পূর্ববর্তী উত্তরটি এই বিষয়ে আমার চিন্তাভাবনাগুলি আরও বিশদে ব্যাখ্যা করে।

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

Comments

আমি সেই বইটি ভালবাসি :)

— ফিলি

আমি এখনও ব্যবহৃত কৌশলটি প্রকাশ করার জন্য মূল্যবান মন্তব্যগুলি খুঁজে পাই এবং যাদের প্রত্যাখ্যান করা হয়েছিল (কারণ সহ)। আমি সম্মত যে মাইক্রো-মন্তব্যগুলি সাধারণত অকেজো।

— ম্যাথিউ এম।

ক্লিন কোড থেকে আমার প্রিয় একটি উদ্ধৃতি হ'ল প্রতিটি মন্তব্য কোডে নিজেকে প্রকাশ করতে ব্যর্থ।

— ডোভাল

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

— সুপারক্যাট

পুরোপুরি দ্বিমত পোষণ করুন। নামকরণের কোনও পরিমাণই যুক্তির উদ্দেশ্যটিকে পুরোপুরি বর্ণনা করতে যাচ্ছে না।

— কলব ক্যানিয়ন

Answer 2

কোডটি কী করছে তা আপনার ডকুমেন্ট করা উচিত নয়, তবে এটি কেন করছে তা আপনার ডকুমেন্ট করা উচিত।

নামকরণের কৌতুকপূর্ণ পরিমাণ কোনও পরিমাণই হ্যাঁ এবং এর কারণগুলি প্রকাশ করবে না, সুতরাং আপনাকে কোডের বিভিন্ন বিটের উদ্দেশ্য ব্যাখ্যা করতে মন্তব্যগুলি যুক্ত করতে হবে।

অন্যান্য সমস্ত মন্তব্য নিরাপদে পরিত্রাণ পেতে পারেন।

Comments

+1 লিঙ্কযুক্ত নিবন্ধের উদাহরণে বলা হয়েছে যে " আমি যে কোড লিখেছি সেটির উদ্দেশ্যটি তাত্ক্ষণিকভাবে দৃশ্যমান নয় এমন কোনও পরিস্থিতিতে মন্তব্য করুন " " - কোডটি নিজে উদ্দেশ্য দ্বারা যোগাযোগ করতে পারে তা বিশ্বাস করা কেবল নির্বোধতা কারণ মেশিনগুলি নিজের উদ্দেশ্য সম্পর্কে কোনও ধারণা রাখে না। পাল্টা উদাহরণ: আমাদের লিখিত প্রায় সব সফ্টওয়্যারগুলিতে বাগ রয়েছে, এটি সত্যবাদ। যদি কোনও কম্পিউটার উদ্দেশ্য বুঝতে পারে ( কেন ) তবে এটি কী / কখন / কিভাবে / কোথায় ত্রুটির দিকে নিয়ে গেছে তার কর্তব্যপরায়ণতার সাথে পুনরায় তৈরি করার পরিবর্তে আমরা কেবল যা চেয়েছিলাম তার চেয়ে অন্য কিছু করতে অস্বীকার করবে use

— ডেভিড মিস্টার

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

— ট্রিলিক্স

@ ট্রাইল্কস যা কিছু ক্ষেত্রে কাজ করে তবে সবার জন্য নয়। এই দৃশ্যকল্প কল্পনা: for (int i = 0; i < length/2;i++) { //if length is odd, the middle element should stay in place। এখন, এটি এমন কিছু নয় যা ঘের .ুকিয়ে ফাংশনের উদ্দেশ্য থেকে স্পষ্ট, বা এটি নিজস্ব ফাংশনটিতে সন্ধান করা যায় না। যদি আপনি এটিকে নিঃশর্ত ছেড়ে দেন তবে এটি পরিষ্কার। সুতরাং আপনি আপনার অভিপ্রায় স্পষ্ট করতে একটি মন্তব্য যুক্ত করুন।

— বিজিকলপ

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

— বিজিকলপ

Answer 3

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

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

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

Comments

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

— পাওয়ারসলেভ

পিএস, আমি জানি আমি 'জম্বি' করছি :) এর জন্য দুঃখিত

— পাওয়ারস্লাভ

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

— পাওয়ার্সলেভ

Answer 4

ভাগ্যক্রমে, এই আলোচনার উভয় শিবির এখানে প্রতিনিধিত্ব করা হয়েছে, এবং উভয়ের পক্ষে প্রো এবং কন আর্গুমেন্ট উল্লেখ করা হয়েছিল।

আমি বিশ্বাস করি যে উভয় শিবিরেরই ওভারল্যাপিং যুক্তি রয়েছে এবং প্রকৃতপক্ষে তাদের বেশিরভাগের সাথেই একমত, এগুলি কীভাবে অর্জন করা যায় তা কিছুটা আলাদা।

ওভারল্যাপিং যুক্তি

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

এখন, মূল পার্থক্য হ'ল those যুক্তিগুলির মধ্যে কতটি ওজন রাখা হয়।

স্ব-বর্ণনার কোড

• মন্তব্যগুলি অপ্রচলিত হতে পারে, সুতরাং এগুলি ব্যবহারকে হ্রাস করুন, কারণ ভুল মন্তব্যগুলি কোনও মন্তব্যের চেয়ে খারাপ।
• মন্তব্যগুলি কোডের একটি সদৃশ। কোড যা কিছু লেখা যায়, কোডে লেখা উচিত।

আরও মন্তব্য

• মন্তব্যগুলি কোডের চেয়ে বেশি পঠনযোগ্য। সাধারণ বর্ণনামূলক কিছু বর্ণনা করার ক্ষেত্রে ভাল।

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

আমি বিশ্বাস করি যে উভয় শিবিরের খুব কার্যকর বৈধ যুক্তি রয়েছে, তবে আপনি কেবল একটি শিবির অনুসরণ করবেন না, কারণ এটি একটি সমস্যা সমাধান করে।

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

অন্যদিকে, আপনি প্রায়শই এপিআই দেখতে পাবেন যেখানে প্রতিটি ফাংশন মন্তব্য করা হয়, কেবল কারণ 'মন্তব্যগুলি ভাল'। যে বিষয়গুলিতে মন্তব্য করা উচিত ছিল তা নয়।

Comments

@ স্টিভেন - "অন্যদিকে, আপনি প্রায়শই এপিআই দেখতে পাবেন যেখানে প্রতিটি ফাংশন মন্তব্য করা হয়, কেবল কারণ 'মন্তব্যগুলি ভাল'। উঃ, হতাশার সাথে সত্য!

— dss539

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

— পাওয়ার্সলেভ

Answer 5

"আমি দুঃখিত তবে আপনার ছেলেটি।"

আমি ভাবছি কেন তিনি মন্তব্য পছন্দ করেন না: পি

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

শিক্ষিত প্রোগ্রামিংকে চরম শৈলী হিসাবে সন্ধান করুন।

Comments

হ্যাঁ। আমি বলতে চাইছি, ডোনাল্ড নুথ যদি মনে করেন যে আপনার কেবল মন্তব্যগুলির দরকার নেই, তবে মাঝে মাঝে সেগুলির অধ্যায়গুলির প্রয়োজন হয় তবে আমি দ্বিমত পোষণ করার আগে কমপক্ষে দুবার চিন্তা করব।

— পিটারঅ্যালেন ওয়েইব

Answer 6

সংক্ষিপ্ত, আরও ভাল এবং সঠিক উত্তর

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

মন্তব্যের চেয়ে আরও ভাল উত্তর কেবল "কেন" তা বোঝাতে ব্যবহার করা উচিত যে মন্তব্যগুলির উচিত:

• "কেন" (অবশ্যই) ব্যাখ্যা করুন
• কোড জটিল হলে বা উদ্দেশ্যটি অস্পষ্ট এবং স্বতন্ত্র লাইনে কেবল "কী" ব্যাখ্যা করুন এবং এটি আরও সরল করার পক্ষে উপযুক্ত নয় বা হতে পারে না
• কোড ব্লকগুলির জন্য বোঝার গতি বাড়ানোর জন্য এবং আপনার যা প্রয়োজন তা চিহ্নিত করার জন্য "কি" ব্যাখ্যা করুন

এটি ব্যাক আপ আপ ব্যাখ্যার

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

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

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

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

Comments

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

— ডালিন

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

— ম্যাগাস

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

— ডালিন

but isn't it faster and easier to read the comment at the top saying what that section of code does and skip it altogether if it's not what I'm looking forএকে "পদ্ধতি / ফাংশনের নাম" বলা হয়। যদি আপনার এমন কোনও কোডের ব্লক পাওয়া যায় যার নাম নেই তবে এটি এত দীর্ঘ যে আপনি এটিকে এক নজরে দেখে নিতে পারবেন না, সম্ভবত সমস্যাটি রয়েছে।

— বিজিকলপ

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

— ডালিন

Answer 7

ঠিক আছে, আপনাকে এমন কিছু কথাও মনে রাখতে হবে যা আপনার কাছে স্পষ্ট বা "স্ব-ডকুমেন্টিং", অন্য কারও কাছে নাও হতে পারে ... কিছু নির্দিষ্ট ফাংশন সম্পর্কে কম বোধগম্য ব্যক্তি। তাই আমি সব কিছু সম্পর্কে মন্তব্য।

Comments

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

— ফিল করুন

+1 এটি আপনার শ্রোতাদের একটি প্রশ্ন। এই ফাংশনটি ব্যবহার করার সম্ভাবনা কে? আপনি কীভাবে তাদের সহায়তা করতে পারেন? আপনার সাহায্য মূল্যবান কি হবে? কোনও মন্তব্য যুক্ত করার জন্য এখন কিছুটা সময় ব্যয় করা কি বেশি মূল্যবান? ইত্যাদি ইত্যাদি ইত্যাদি

— পিটারআলেন ওয়েলব

@ পিটারএলেন ওয়েব: এই মন্তব্যে মোটেই লাভজনক নয়। এর দূরবর্তী অর্থ এই নয় যে ফাংশনটির মন্তব্য করা উচিত নয়; এটা করা উচিত। "এক্সটেনশন" বিন্দু অন্তর্ভুক্ত না? রিটার্নের মান কী "foo"? ( null?? "") জন্য "foo."? পাস করার nullফলে একটি ব্যতিক্রম ঘটবে, বা ফাংশনটি কিছু প্রত্যাবর্তন করবে (সম্ভবত null)?

— টিজে ক্রোডার 13

Answer 8

ভাল, স্ব নথিভুক্ত কোড সহ জিনিসটি সেই ফাংশনের মধ্যেই আপনি খুঁজে পাবেন:

$pieces = explode('.', $image_name);  
$extension = array_pop($pieces);  

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

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

Comments

হ্যাঁ। আমি মনে করি এটি "বা প্রশিক্ষিত" হতে হবে এটি ভাবার জন্য এটি একটি বা অন্য হওয়া উচিত এবং উভয়ই নয়।

— পিটারঅ্যালেন ওয়েইব

Answer 9

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

Comments

ধরে নিচ্ছি সব কিছুর কারণ আছে, তা কি মন্তব্য করা উচিত?

— জেফো

হ্যাঁ, অবশ্যই এজন্য আমি বিশ্বাস করি যে আপনার কোডটি মন্তব্য করার সর্বোত্তম উপায় হ'ল একটি সাক্ষর প্রোগ্রামিং।

— এসকে-যুক্তি 14

Answer 10

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

$ এক্সটেনশন = গেটফাইএক্সটেনশন ($ চিত্র_নাম);

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

অবশ্যই, আমি এটাকে কিছুটা প্রসারিত করছি। তবে আমি মনে করি এমন একটি প্রোগ্রামার যিনি অডিও_ব্যান্ডউইথ এবং ভিডিও_ব্যান্ডউইথ বিশ্বাস করেছিলেন স্ব-ডকুমেন্টিংয়ের নাম; পরিণত অডিওটি কিলোবাইটে বাইট এবং ভিডিওতে প্রকাশ করতে হয়েছিল। এটি বের করার জন্য অনেক সময় নিয়েছে।

Comments

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

— ম্যাট এলেন

@ ম্যাট: "স্পষ্টভাবে নয়" এমন একটি ইঙ্গিত যা আপনি প্রায়শই রক্ষণাবেক্ষণ করেন না। সুস্পষ্ট হওয়া পরবর্তীকালে প্রচুর মাথা-স্ক্র্যাচিং (এবং আরটিএফএসফোর্স) সংরক্ষণ করে এবং মূল লেখক এটি থেকে কী প্রত্যাশা করেছিল তাও নথিভুক্ত করে । তা কোনও মন্তব্যে হোক বা দীর্ঘ ফাংশনের নামে তা এতটা গুরুত্বপূর্ণ নয়।

— ডোনাল ফেলো

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

— ফিল করুন

@ ডোনাল ফেলো: এটি ফাইল, একবচন বলে। এ নিয়ে দ্বিধা কী? এটি সম্পূর্ণ সুস্পষ্ট।

— ম্যাট এলেন

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

— পিঁপড়া

Answer 11

একজন অন্যকে বাদ দেয় না। যদিও আপনার কোডটি স্ব-মন্তব্য করা হয়েছে, এমন সময় রয়েছে যখন আপনার স্ব-মন্তব্য কোড কেন এটি করে তা ব্যাখ্যা করার জন্য আপনার নিয়মিত মন্তব্যের প্রয়োজন হতে পারে।

Comments

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

— ফিল করুন

কোড কখনই এর উদ্দেশ্য ব্যাখ্যা করতে পারে না । আপনি যখন হাতুড়িটি দেখেন, আপনি বুঝতে পারছেন না এটি কীসের জন্য - এটি কি খুলি ফেটে ফেলার জন্য বা কেবল কোনও কাঁচা লোহা জালানোর জন্য।

— এসকে-যুক্তি

@ এসকে-যুক্তি:public <T> void hit(T item);

— মাইকেল কে

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

— এসকে-যুক্তি

Answer 12

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

কেবল চালাক না হওয়ার চেষ্টা করুন কারণ চতুর কোডটি ভয়ঙ্করভাবে পড়া এবং বজায় রাখা উচিত। কীওয়ার্ড: বজায় রাখুন !

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

যদি আপনি কোনও উত্স নিয়ন্ত্রণ ব্যবস্থা ব্যবহার করেন তবে আপনি প্রতিশ্রুতি বার্তাটি ব্যবহার করে প্রত্যেককে (এবং নিজেকে) একটি নির্দিষ্ট সময়ে আপনি কী করেছিলেন তা আরও গুরুত্বপূর্ণভাবে কেন বলা যেতে পারে why

Answer 13

আপনি যেমন কোনও ডকুমেন্টেশন এড়াতে চান ঠিক তেমন মন্তব্য লেখা এড়াতে চাইবেন। প্রোগ্রামিং ল্যাংগুয়েজ নিজেই যখন আসে, প্রত্যেকে একই শব্দভাণ্ডার এবং বাক্য গঠন (প্রায়) এর সেট থেকে কাজ করে is

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

EBITDA

এবং না

EquityBeforeInterestTaxesDepreciationAndAmortization

আপনি যদি একজনকে না জানেন তবে আপনি সম্ভবত অন্যটিকে বুঝতে পারবেন না। যদি সংস্থার কিছু অস্বাভাবিক বাস্তবায়ন হয় তবে একটি মন্তব্য পরবর্তী প্রোগ্রামারকে সাহায্য করবে যাঁর ডোমেনে অভিজ্ঞতা থাকতে পারে তবে এই নির্দিষ্ট ফার্মটি নয় (যা এই বিষয়গুলিকে আরও জটিল করে তোলে))

Answer 14

আমি মনে করি আমাদের ডকুমেন্টেশন এবং কোডটির বহিঃপ্রকাশের মধ্যে পার্থক্য করতে হবে ।

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

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

Answer 15

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

//
// iterative version
//
Node* ReverseList( Node ** List ) 
{

  Node *temp1 = *List;
  Node * temp2 = NULL;
  Node * temp3 = NULL;

  while ( temp1 )
  {
    *List = temp1; //set the head to last node 
    temp2= temp1->pNext; // save the next ptr in temp2
    temp1->pNext = temp3; // change next to privous
    temp3 = temp1;
    temp1 = temp2;
  }

  return *List;
}

Answer 16

আমি সাধারণত স্ব-ডকুমেন্টিং কোড লেখার পক্ষে, মন্তব্য সহ যেখানে অস্পষ্ট, আমি মনে করি যেহেতু বেশিরভাগ কোড পুরোপুরি নিজেই ডকুমেন্ট করবে না।

Answer 17

বিশ্ববিদ্যালয়ে আমরা একটি মন্তব্যে ইংরেজিতে কোডের প্রতিটি লাইনকে বেশ প্রশংসিত করতে শিখিয়েছিলাম (সম্ভবত কেবল কোনও কোড অনুলিপি / আটকানো এবং সর্বোত্তম আশা করার পরিবর্তে কোডটি আসলে কী করে তা বোঝার অভ্যাসে আমাদের পেতে)।

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

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

Answer 18

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

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

সহজ ভাষায় লিখুন আপনি মন্তব্যগুলি কোড করেন সেগুলি লিখবেন না

Answer 19

কোড সম্পূর্ণ দ্বিতীয় সংস্করণ দেখুন, পৃষ্ঠা 128-129।

বিমূর্ত ডেটা প্রকারগুলি আপনাকে এই কনড্রাম থেকে রক্ষা করবে। সেলফ ডকুমেন্টিং কোড হ'ল উপায়। মন্তব্য দরকারী হতে পারে, কিন্তু হচ্ছে

নিম্ন-স্তরের বাস্তবায়নগুলির চেয়ে বাস্তব-বিশ্ব সত্তা

আপনি মন্তব্য ব্যবহার এড়াতে পারবেন।

মন্তব্যের একটি বিষয় হ'ল আপনি এগুলি একবার লিখেছিলেন, তবে আপনি যখন ফাংশনটি বাস্তবায়ন করেন আপনি সেগুলি দেখতে পাবেন না, আপনি কেবল ফাংশনটি পরিবর্তন করার সময় সেগুলি দেখতে পাবেন।

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

Answer 20

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

Answer 21

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

আপনি যদি কেবল এটি মাথায় রাখেন, কোডিং / প্রোগ্রামিংয়ের সময়?

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

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

কোড অভ্যাসটি নিজেরাই ভাবার অভ্যাসটি কেবল যথাযথ পরিশ্রমের দ্বারা করা হচ্ছে না।

প্রোগ্রামার হিসাবে আমাদের অবশ্যই সেই স্ব-শৃঙ্খলা অনুশীলন করা উচিত যা অনভিজ্ঞ প্রোগ্রামারদের কাছে সম্পূর্ণরূপে উপস্থিত হতে পারে তবে অন্য ব্যক্তির কোড সহ আমাদের যে ভয়াবহ অভিজ্ঞতা হয়েছে তা এড়াতে অবশ্যই অভ্যাস থাকতে হবে। এমনকি কয়েক বছর পরে আমাদের নিজস্ব কোডও দেখছি।

Http://thedailywtf.com দেখুন প্রোগ্রামারটির সম্পর্কে তাদের কাছে প্রচুর হাস্যকর তবে বাস্তব গল্প রয়েছে যারা তাদের যথাসাধ্য চেষ্টা করেন নি ..