কোডে মন্তব্য করা অপছন্দকারী দলের সদস্যের সাথে আমি কীভাবে আচরণ করব?

182

আমার দলের একজন সদস্য ধারাবাহিকভাবে তার কোডে মন্তব্য করা এড়ানো যায়।

তার কোডটি স্ব-ডকুমেন্টিং নয়, এবং অন্যান্য প্রোগ্রামারদের তার কোড বুঝতে অসুবিধা হয়েছে।

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

আমি তার কোডটি সঠিকভাবে নথিভুক্ত করতে তাকে বোঝাতে কোন যুক্তি উপস্থাপন করতে পারি?

এই নোটটিতে, আমি কি কোড মন্তব্যে ফোকাস করা ভুল করছি বা এটি কোনও বৃহত্তর সমস্যার সূচক যা সমাধান করা উচিত?

teamwork team comments

— মাহবুবুর আর আমান
সূত্র

109

মন্তব্যের জন্য মন্তব্য করা কোডটি আরও ভাল করে না। কোডটি যদি মন্তব্য ছাড়াই বোধগম্য হয় (কেন তা সহ) তবে অন্যথায় মন্তব্য করুন।

— মার্টিন ইয়র্ক

63

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

— কাজ

12

@ কাজ সার্কাসম (আমি আশা করি) পাঠ্যে ভাল অনুবাদ করে না।

— ডিফোর্ড

10

@ ডিওয়ার্ড এবং আর্টজম - হ্যাঁ, এটি ব্যঙ্গাত্মক। না, এটি যতটা পরিষ্কারভাবে পারত ততটা আসে না, তবে এটি স্পষ্টভাবে ব্যঙ্গাত্মক।

17

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

— অনিরুদা

430

মন্তব্যগুলি এককভাবে আরও ভাল কোডের জন্য তৈরি করে না এবং কেবল "আরও মন্তব্য" দেওয়ার জন্য আপনাকে /* increment i by 1 */স্টাইলের মন্তব্যের চেয়ে সামান্য কিছু দেওয়ার সম্ভাবনা রয়েছে ।

সুতরাং নিজেকে জিজ্ঞাসা করুন আপনি কেন এই মন্তব্যগুলি চান। "এটি সর্বোত্তম অনুশীলন" কোনও কারণ হিসাবে বুঝতে না পারলে একটি যুক্তি হিসাবে গণ্য হবে না।

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

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

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

জনগণের দক্ষতাগুলির সম্মুখভাগে, কোনও মূল্যে শঙ্কিত বা দোষারোপ করা শব্দটি এড়ানো; আপনার প্রশ্ন সম্পর্কে গুরুতর এবং সৎ হন।

— টিডামার্স
সূত্র

269

"অনুপস্থিত মন্তব্য সম্পর্কে অভিযোগ করবেন না: অপঠনযোগ্য কোড সম্পর্কে অভিযোগ করুন for"

— মোঃ মাহবুবুর রহমান

4

কোড সম্পর্কে কোনও প্রশ্নের উত্তর যদি "আপনি এটি বুঝতে কী করেছেন?" এর ধারায় থাকে তবে কী হবে?

— শৌল

40

+1: পাঠযোগ্য ফাংশন নামগুলির জন্য ধাক্কা দেওয়ার ফলে আরও সুবিধা যুক্ত হতে পারে ... কোড পর্যালোচনায়: "xg_jkhsfkasq কী করছে তা বুঝতে পারি না"। "ওহ, এটি প্রাথমিক ফিড বাফারটি ফ্লাশ করছে, এখন আমি কি মুক্তি দিতে পারি?" "অবশ্যই, তবে আপনি এই ফাংশনটির নাম পরিবর্তন না করা পর্যন্ত আমি এটি অনুমোদন করতে দ্বিধা বোধ করছি" "আহ, তবে এটি মূল ক্যাশেটিও সাফ করছে, যাতে নামটি বিভ্রান্তিকর হবে" "এটি কী? সাফ করবেন না, এটি 'সিস্টেমটি থামতে দেব? আপনি যখন এই যুক্তিটি পরিবর্তন করছেন, আপনি কি সেই ফাংশনটির নাম পরিবর্তন করতে আপত্তি করবেন? "

— ডিফোর্ড

18

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

— রব পি।

5

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

— ডিফোরে

114

আমি স্বতন্ত্র-ডকুমেন্টিং কোড বা সহায়ক মন্তব্য লেখার ক্ষেত্রে সমস্যায় পড়ে এমন অনেক দেবের সাথে দেখা করেছি। এই ধরণের লোকেরা প্রায়শই এটি সঠিকভাবে করার জন্য পর্যাপ্ত স্ব-শৃঙ্খলা বা অভিজ্ঞতার অভাব হয়।

যা কখনও কাজ করে না তা হ'ল "তাদের আরও মন্তব্য যুক্ত করতে বলা"। এটি তাদের স্ব-শৃঙ্খলা বা অভিজ্ঞতা বাড়াবে না। আইএমএইচও কেবলমাত্র কাজ করতে পারে তা হল ঘন ঘন কোড-রিভিউ এবং রিফ্যাক্টরিং সেশনগুলি তৈরি করা। যখন কোনও দেব কোনও কাজ সম্পন্ন করেন, আপনি যে কোডটি বুঝতে পারছেন না তার কোনও অংশ ব্যাখ্যা করার জন্য তাকে / তাকে অনুমতি দিন। অবিলম্বে রিফ্যাক্টর বা কোডটি এমনভাবে ডকুমেন্ট করুন যাতে আপনি উভয়ই 6 মাস পরে বুঝতে পারবেন।

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

— ডক ব্রাউন
সূত্র

5

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

— জিমি হোফা

1

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

— মার্টিন ব্রাউন

27

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

— Earlz
সূত্র

2

+1 - যদি আপনাকে কোডটির কোনও অংশ সম্পর্কে প্রশ্ন জিজ্ঞাসা করতে হয় তবে সেই অংশটির একটি মন্তব্য বা রিফ্যাক্টরিং প্রয়োজন যাতে ভবিষ্যতে অন্য কারও দ্বারা প্রশ্ন জিজ্ঞাসা করার প্রয়োজন হয় না।

— ডাঙ্ক

+1 এছাড়াও বিস্মিত কোড / পিয়ার পর্যালোচনাগুলির উত্তরগুলি এত নীচে। টিমের স্তরের কোড-পর্যালোচনাগুলি প্রয়োগ করা (যাতে কোনও ব্যক্তিকে বাছাই না করা হয়) সমস্যাটি সমাধান করতে সহায়তা করতে পারে (এবং অন্যরা হয়ত আপনার নিজের কাছে জানেন না যে :))। চূড়ান্তভাবে আপনি একটি নো-সলো-পুশ নীতি বাস্তবায়ন করতে পারেন যার দ্বারা আপনাকে কোনও টিম সদস্যের দ্বারা পরিবর্তনগুলি পর্যালোচনা না করা পর্যন্ত আপনাকে ধাক্কা দেওয়ার অনুমতি দেওয়া হবে না।

— ক্রিস লি

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

— লোকস

18

এটি আপনার দলের কর্মী কোড তৈরি করে তার উপর নির্ভর করে। আপনি যদি আঙ্কেল বব এর ক্লিন কোড বইটি পড়েন তবে আপনি দেখতে পাবেন যে তিনি আসলে কোডে মন্তব্যগুলি যুক্ত না করা পছন্দ করেন । কোডটি যদি নিজের মতো করে পঠনযোগ্য হয় তবে মন্তব্যগুলির পক্ষে খুব কমই দরকার।

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

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

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

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

— অকপট
সূত্র

মন্তব্য থেকে আসল লাভ নিয়ে আলোচনা করার জন্য +1 মন্তব্যগুলি উত্স কোডে মান যুক্ত করতে বোঝানো হয়।

— স্পার্কি

1

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

— ডাঙ্ক

3

এই বইয়ের পদ্ধতির সাথে সর্বদা সমস্যা ছিল। মন্তব্যগুলি কোনও ব্যবসায়িক প্রক্রিয়া / যুক্তি (বা কেন) যে কোনও পরিমাণ পরিচ্ছন্ন কোড পারে না তা ব্যাখ্যা করতে কার্যকর হতে পারে।

— ভারাল

কোডে মন্তব্যগুলি প্রয়োজনীয় না হলেও, জাভাদোকের মতো কমপক্ষে পদ্ধতির বিবরণ থাকতে হবে

— ডানুবিয়ান নাবিক

2

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

— গর্ডনএম

10

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

এটি বলেছিল, আপনি সম্ভবত তাকে সাহায্য করতে পারেন। আমার অভিজ্ঞতায়, যখন কেউ প্রতিবাদ করে যে মন্তব্য করাতে খুব বেশি সময় লাগে সেখানে মনস্তাত্ত্বিক প্রতিবন্ধকতা যেমন ...

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

প্রোগ্রামারটির পক্ষে উপলব্ধি করা গুরুত্বপূর্ণ যে মন্তব্যগুলি পরীক্ষার মতো: সেগুলি কেবল ভবিষ্যতের ব্যবহারের জন্য নয় - তারা নিজেই প্রোগ্রামারটির জন্য। তারা তাকে তার পদ্ধতির বিষয়ে আলাদাভাবে চিন্তা করতে বাধ্য করে।

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

— রেভিস কোজিরো
সূত্র

3

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

— গর্ডনএম

@ গর্ডনএম আপনি কি মনে করেন যে কোনও কর্মচারীর আচরণ অনুপযুক্ত হলে তাকে না বলাই ভাল হবে এবং অব্যাহত অনুচিত আচরণের পরিণতি কী হবে?

— কোজিরো

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

— গর্ডনএম

@ গর্ডনএম আমি প্রকৃতপক্ষে এই ধারণাকে ব্যতিক্রম করেছি যে আমি যা বলেছিলাম তা হুমকীপূর্ণ ছিল, তবে যাইহোক, আমি এটি স্থির করেছিলাম।

— কোজিরো

8

কোড পর্যালোচনা সফ্টওয়্যার পান এবং এটি ভাল ব্যবহার করুন।

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

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

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

কিলনের মতো সফ্টওয়্যার ব্যবহার করে কোনও পরিবর্তনই উপেক্ষা করা যায় না। আমার দেব দলের প্রত্যেকে এটিকে অনেক বেশি পছন্দ করে। কোড পর্যালোচনা সফ্টওয়্যার আমাদের কোডের মান এবং অ্যাপ্লিকেশন মানের উভয়কেই বিশাল প্রভাব ফেলেছে :-)

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

সম্পাদনা করুন: লক্ষণীয়, আমরা ডিভসকে ক্রিপ্টিক কোডটি মৌখিকভাবে বা পর্যালোচনায় মন্তব্যে ব্যাখ্যা না করার চেষ্টা করি। যদি কিছু পরিষ্কার না হয় তবে কোডটি (মন্তব্যে বা রিফ্যাক্টরিং করে) এটি ব্যাখ্যা করার সর্বোত্তম জায়গাটি হ'ল একই পর্যালোচনায় নতুন চেঞ্জসেটগুলি যুক্ত করুন।

— রেভস ড্যানি টুপেনি
সূত্র

4

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

কেন মন্তব্য?

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

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

কোড পঠনযোগ্যতা! = কোড মন্তব্য

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

অন্যদিকে, পঠনযোগ্য প্রোগ্রাম = কোড + ডকুমেন্টেশনে মন্তব্যের একাধিক বৈধ বিভাগ থাকতে পারে, যেমন "মন্তব্যগুলিতে এপিআই" নথিভুক্তকরণের সুবিধার্থে।

কোড শৈলী মান অনুসরণ করুন

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

একটি কোড পঠনযোগ্যতা প্রচারক হন

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

কোডের প্রতিটি লাইনে প্রযোজ্য টিপসের সাহায্যে নামকরণ, মন্তব্য করা এবং ফর্ম্যাট করা সহজ করুন
জটিলতা এবং বিভ্রান্তি হ্রাস করতে আপনার প্রোগ্রামের লুপস, লজিক এবং ভেরিয়েবলগুলিকে পরিমার্জন করুন
ফাংশন স্তরে আক্রমণ সম্পর্কিত সমস্যাগুলি, যেমন একবারে একটি কাজ করার জন্য কোডের ব্লকগুলি পুনর্গঠিত করা
কার্যকর টেস্ট কোড লিখুন যা সম্পূর্ণ এবং সংক্ষিপ্ত is পাশাপাশি পাঠযোগ্য read

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

— রেভস ইয়াওহেন ইয়াকিমোভিচ
সূত্র

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

— নাক্স

1

একজন ভাল ইঞ্জিনিয়ার পুরো সিস্টেমটির বিষয়ে যত্নশীল (সহ নন-কোডজেনেটেড ডকুমেন্টেশন সহ) - তবে এখানে আমরা অবশ্যই অবশ্যই সাধারণভাবে কোডিং করবো .. আমার বক্তব্যটি হ'ল foo , বার , tmpSomething2 এবং IamJustTooSmartAssToCare নামক কোডটিতে সনাক্তকারী না থাকা ইতিমধ্যে উন্নত হয়েছে improves পরিস্থিতি এবং কোডটি কী এবং এটি কী করে তা ব্যাখ্যা করার সামগ্রিক প্রয়োজন হ্রাস করে। কোডগুলি "চিন্তাভাবনা মোড অন" দিয়ে একটি ভাল-ডিজাইন করা API এর মতো লেখা উচিত যা মানুষের দ্বারা পড়া, বোঝা, পুনঃব্যবহার এবং রক্ষণাবেক্ষণ করা হয়। কোডে অনেক বেশি মন্তব্য যা অন্যথায় বুঝতে অসুবিধা হয় এটি খুব খারাপ চিহ্ন!

— ইয়াহেন ইয়াকিমোভিচ

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

— ইয়াহেন ইয়াকিমোভিচ

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

— নাক্স

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

— ইয়াহেন ইয়াকিমোভিচ

3

আমি কি কোডের মন্তব্যে ফোকাস করতে ভুল করছি বা এটি একটি বড় সমস্যার সূচক যা সমাধান করা উচিত?

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

তাহলে কীভাবে করব? পর্যালোচনা / রিফ্যাক্টরিং সেশন সম্পর্কে ডক ব্রাউনের পরামর্শগুলি ভাল ধারণা। আমি জোড় প্রোগ্রামিংটিকে আরও কার্যকর বলে মনে করি তবে এটি বাস্তবায়ন করাও বেশ জটিল হতে পারে।

— পিট
সূত্র

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

— মালাচি

3

প্রথমত, আমি আপনাকে মন্তব্য সম্পর্কে আপনার পদ্ধতির পুনরায় সম্বোধন করার পরামর্শ দেব।

যদি তারা এপিআই পর্যায়ে ডকুমেন্টেশন মন্তব্য হয় (পরে প্রকাশ্যে প্রকাশ করা হয়), তবে এই বিকাশকারী কেবল তার কাজটি করছেন না। তবে অন্যান্য সমস্ত মন্তব্যের জন্য, সাবধান হন।

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

মন্তব্যগুলি আপনার কোডকে বিভিন্নভাবে আঘাত করে:

1) তারা বজায় রাখা কঠিন। রিফ্যাক্টর করার সময় আপনাকে অতিরিক্ত কাজ করতে হবে; আপনি যদি মন্তব্যে বর্ণিত যুক্তিটি পরিবর্তন করেন তবে আপনাকেও মন্তব্যটি সম্পাদনা করতে হবে।

2) তারা প্রায়শই মিথ্যা বলে। আপনি মন্তব্যগুলিতে বিশ্বাস করতে পারবেন না এবং পরিবর্তে কোডটি পড়তে হবে। যা প্রশ্ন উত্থাপন করে: আপনার কেন এ মন্তব্যগুলির প্রয়োজন হবে?

// this method returns the sum of 'a' and 'b'
public int GetHash(int a, int b)
{
    //the calculation of the hash
    int result = a*b;
}

(হ্যাশ যোগফল নয়, তবে পণ্য))

3) মন্তব্যগুলি কোডকে বিশৃঙ্খলা করে এবং খুব কমই কোনও মান যুক্ত করে।

আমার সমাধান: আরও মন্তব্য যুক্ত করার পরিবর্তে এগুলি থেকে মুক্তি পাওয়ার চেষ্টা করুন!

— পল
সূত্র

4

এটা ঠিক নির্বোধ। আমি আশা করি যে কেউ বিশ্বাস করেন না যে এই জাতীয় মন্তব্য করার শৈলী সহায়ক। তবে আপনি কি সত্যই বিশ্বাস করেন যে মন্তব্যগুলি কখনই ব্যবহার করা উচিত নয় ?

— জেএমকে

1

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

— ডি ব্ল্যাকবারো

3

গুরুত্বপূর্ণ বিষয়টি মনে রাখবেন যে এই মুহূর্তে আপনার কাছে সমস্ত কিছু বোধগম্য হয় তবে অন্য কাউকে আপনার কোডটি 3 বছরের মধ্যে বজায় রাখতে হবে। ওভার স্ক্রু করবেন না।

— xaxxon

4

@ এক্সএক্সএক্সন সেই আপেলটি উল্লেখ করবেন না এমনকি এমনকি যদি সে ব্যক্তি আপনিই হন।

— ফ্লফি

3

@mehaase - না কি, না কিভাবে, কিন্তু কেন সবচেয়ে গুরুত্বপূর্ণ কোডে মন্তব্য যোগ করতে কারণ নেই।

— হেন্ক ল্যাঙ্গভেল্ড

1

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

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

নোট করুন যে টিমের সদস্যদের ব্যাখ্যা করার জন্য একে অপরকে জিজ্ঞাসা করতে উত্সাহিত করা অন্যান্য কারণে মূল্যবান। উদাহরণস্বরূপ, সম্ভবত কোনও দলের সদস্য কম অভিজ্ঞ এবং আরও অভিজ্ঞ দলের সদস্যদের কাছ থেকে জিনিস শিখতে পারবেন।

বেশিরভাগ ক্ষেত্রে, দলের সদস্যদের একে অপরকে ব্যাখ্যা করার জন্য উত্সাহ দিয়ে আপনি একটি স্ব-ভারসাম্য ব্যবস্থা তৈরি করেন; যেখানে বিভিন্ন দলের সদস্যরা একে অপরের সাথে "স্বয়ংক্রিয়-সমন্বয়" করে।

— ব্রেন্ডন
সূত্র

1

এটি মূলত টিডামার্স উত্তরের একটি বর্ধন, তবে নিয়মিত বিরতিতে কোড পর্যালোচনা সম্পাদন করে।

তাকে (এবং অন্যান্য বিকাশকারীদের) বসতে, তাদের কোডটি অনুসরণ করে চলুন এবং তাদের উর্ধ্বতনদের এবং সহকর্মীদের সামনে কম বেশি প্রতিরক্ষা করা প্রত্যেককে আরও ভাল কোডার করে তুলবে এবং অপেক্ষাকৃত স্বল্প সময়ের মধ্যে আসল মান যুক্ত করবে। স্বল্পমেয়াদে, এটি বিকাশকারীকে প্রশ্নবিদ্ধ উত্তর দেবে, পর্যালোচনার সময়, তার কোডটি সঠিকভাবে মন্তব্য করবে।

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

কোডটি কি ভাল অনুশীলন পর্যালোচনা করছে?

— 2
সূত্র

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

— এভিক জেমস

1

অন্য সহকর্মীদের সামনে কোডে লোকের হাসি

— ফোটানো

1

কোড পর্যালোচনাটি করা লোকেরা যদি গঠনমূলক হওয়ার পরিবর্তে হাসতে থাকে তবে তাদের এমন বিকাশকারী যতটা পড়ার যোগ্য কোডটি লিখতে পারে না তার মতো প্রতিটি প্রশিক্ষণের প্রয়োজন need অবজ্ঞার চেয়ে বরং গঠনমূলক যে সমালোচনা আমার কাছে বিকাশকারীদের প্রায়শই অভাব হয় এমন সামাজিক দক্ষতা skills

— মার্টিন ব্রাউন

1

মন্তব্য সম্পর্কে প্রায়শই চরম মতামত বিবেচনা করে, আমি ওজন করতে দ্বিধা করি That যা বলা হচ্ছে ...

এমন কিছু যুক্তি যা আমি উপস্থাপন করতে পারি যে আপনি যদি (অপঠনযোগ্য) কোড লিখতে চলেছেন যে এটি সঠিকভাবে নথিভুক্ত করা উচিত?

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

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

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

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

একটি সরু হিসাবে ... কিছু সময় নথির প্রয়োজন হয় কোডের "পাঠযোগ্যতা" কতটুকু ভাল is এপিআই এর ডকুমেন্টেশন থাকতে হবে, অত্যন্ত প্রযুক্তিগত এবং জটিল ক্রিয়াকলাপগুলিতে প্রোগ্রামারকে জড়িত প্রক্রিয়াগুলি বোঝার জন্য সহায়তা করার জন্য ডকুমেন্টেশন থাকতে হবে (প্রায়শই প্রোগ্রামারদের জ্ঞানের ডোমেনের বাইরে), এবং জটিল রেজেস'স এর মতো কিছু বিষয় সত্যই ডকুমেন্ট করা উচিত যা আপনার সাথে মিলছে।

— বিল
সূত্র

0

অনেক প্রকল্পের কোড ডকুমেন্টেশন প্রয়োজন: ইন্টারফেস ডকুমেন্ট, ডিজাইন ডকুমেন্ট, ...

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

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

— mouviciel
সূত্র

6

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

— জানু হুডেক

1

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

— mouviciel

2

ভাল, না, এটা না। আপনি কীভাবে .pdf এ লক্ষ্য করতে যাচ্ছেন যে কোডটি বর্ণনার চেয়ে আলাদাভাবে কিছু বোঝায়?

— জানু হুডেক

1

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

— mouviciel

হ্যাঁ, আপনি দৃ strongly় পক্ষপাতদুষ্ট। এর মতো ডোমেনগুলিতে এটি বোধগম্য হয়, বেশিরভাগ ইউনিটে পরীক্ষাগুলি QA এর জন্য পর্যাপ্ত এবং প্রতিটি শেষ ফাংশনটি নথিভুক্ত করা সময় নষ্ট হবে।

— জানু হুডেক

0

আমি বেশিরভাগ উত্তর এবং মন্তব্যে কী ইঙ্গিত দিচ্ছি তা আমি উল্লেখ করতে যাচ্ছি: আপনার সম্ভবত সমাধানটি সমাধানের চেষ্টা করার চেয়ে আপনার সম্ভবত এখানে আসল সমস্যাটি বের করা দরকার।

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

— reinierpost
সূত্র

0

আপনি যদি ভাল কোডিং মান অনুসরণ করেন তবে ন্যূনতম সংখ্যক মন্তব্য প্রয়োজন হবে। নামকরণের সম্মেলনগুলি গুরুত্বপূর্ণ। পদ্ধতির নাম এবং পরিবর্তনশীল নামগুলি তাদের ভূমিকা বর্ণনা করে ..

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

   var str1:String="" //not uderstandable
   var strSearchPattern:String="" //uderstandable

— রেভস এম.এস.নায়েক
সূত্র

0

কোড পর্যালোচনা উত্তরগুলি পছন্দ করুন, তবে সম্ভবত আমার প্রক্রিয়াটিও কিছুটা সহায়তা করবে।

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

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

এটি তাদের নিজস্ব ফাংশনে বিভ্রান্তিকর ক্রিয়াকলাপগুলিকে মুছে ফেলার মত মন্তব্য যুক্ত করার মতো সহজ হতে পারে বা এটি কোনও নতুন অবজেক্ট বের করার মতো বৃহত্তর চুল্লীটিকে ট্রিগার করতে পারে।

আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি গ্রুপের প্রত্যেককে "নিজস্ব" হতে উত্সাহিত করুন যে তাদের কোড অন্যের কাছে পাঠযোগ্য - এর অর্থ হ'ল প্রতিবারই কেউ আপনাকে আপনার কোড সম্পর্কে কোনও প্রশ্ন জিজ্ঞাসা করবে, আপনি একটি পরিবর্তন আনতে প্রতিশ্রুতিবদ্ধ - বা আরও ভাল তার সাথে যুক্ত করুন ব্যক্তি ঠিক তখনই পরিবর্তন করতে!

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

— বিল কে
সূত্র

0

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

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

কঠোর অভিজ্ঞতার চেয়ে ভাল আর কোন শিক্ষক নেই!

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

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

— GordonM
সূত্র

-1

কোনও মন্তব্য ছাড়াই তাকে অন্য একটি কোড দিন এবং কোডটি বুঝতে তাকে জিজ্ঞাসা করুন। সে তখন সঠিক মন্তব্যের গুরুত্ব বুঝতে পারে।

— অভিষেক গালআউট
সূত্র

12

আমি সবে সবে এই -1 বোতামটি এড়িয়ে চলেছি। আমি যে কোডটি লিখি তার বেশিরভাগেরই খুব কম মন্তব্য থাকে। আমি মনে করি না যে আমি লোকেরা অভিযোগ করেছিলাম যে এটি কমপক্ষে কয়েক বছর ধরে বোধগম্য নয়। খুব অল্প ব্যতিক্রম ব্যতীত, কোডটি বোঝার জন্য যদি মন্তব্যগুলির প্রয়োজন হয় , তবে এটির জন্য মন্তব্যগুলির দরকার নেই, স্বচ্ছতার জন্য এটির উন্নতি প্রয়োজন। (অবশ্যই, আপনাকে ভাষাটির বাক্য গঠনটি সম্পর্কে প্রাথমিক ধারণা গ্রহণ করতে হবে C সি ++ এর মতো বিষয়গুলি ব্যবহার এড়াতে কেবল আপনার পথ থেকে দূরে থাকবেন না কারণ লোকেরা এটি বিভ্রান্তিকর হতে পারে; সি # তে, আপনার যা প্রয়োজন তা যদি ব্যবহার করেন তবে ব্যবহার করুন এটি; ইত্যাদি)reinterpret_cast<>()??

— একটি সিভিএন

2

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

— LarsH

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

— LarsH

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

— একটি সিভিএন

@ মাইকেলKjörling: সাধারণভাবে সম্মত। এই ব্যতিক্রমগুলি বিরল বা না তা নির্ভর করে আপনি যে ডোমেনটির জন্য প্রোগ্রামিং করছেন, এবং আপনার যে API এর ব্যবহার করতে হবে তার উপর নির্ভর করে। লিঙ্কগুলি / রেফারেন্সগুলি কেবলমাত্র বর্তমান পরিস্থিতিতে নয়, সাধারণত প্রয়োগ হয় এমন নোটগুলির জন্য ভাল। কেউই কোডটিতে একটি গবেষণামূলক প্রবন্ধ চায় না।

— LarsH

-1

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

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

— Arkh
সূত্র

1

প্রোগ্রামারকে কাজ করার সঠিক পদ্ধতিতে প্রশিক্ষণের চেয়ে প্রোগ্রামারকে ছেড়ে দেওয়ার জন্য এই পদ্ধতিরটি আরও বেশি পছন্দসই।

— মার্টিন ব্রাউন

-1

আমার অতীতের একটি প্রকল্পে কয়েক ডজন মন্তব্য (অ্যালগরিদম, ফলাফল বা কিছু বেসিক জাভাক ডক) অনুপস্থিত ছিল, তাই আমি কেবল তার জন্য ১৩০ টি ইস্যু করার সিদ্ধান্ত নিয়েছি, প্রতি 4 দিন পরের প্রতিটি ইস্যু সম্পর্কিত ইমেল বিজ্ঞপ্তি। 3 সপ্তাহ পরে তার 280 সংখ্যা ছিল, তারপরে তিনি মন্তব্য লেখার সিদ্ধান্ত নিয়েছেন।

— agilob
সূত্র

-1

মন্তব্যগুলির একটি উদ্দেশ্য এবং কেবল একটি উদ্দেশ্য রয়েছে:

কেন এই কোডটি এই জিনিসটি করে?

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

আমার মন্তব্যগুলি আমার আইডিইয়ের সবচেয়ে সুস্পষ্ট জিনিস করার অভ্যাস আছে। এগুলি সবুজ পটভূমিতে সাদা পাঠ্যের সাথে হাইলাইট করা হয়। সত্যিই আপনার দৃষ্টি আকর্ষণ।

এটি কারণ কোডটি ব্যাখ্যা করে যে কিছু কী করছে এবং মন্তব্যগুলি কেন এটি করছে তার জন্য। আমি এটি যথেষ্ট জোর দিতে পারি না।

একটি মন্তব্যের একটি ভাল উদাহরণ:

/* Must instantiate clsUser before trying to encrypt a password because the code to 
   encrypt passwords only uses strong encryption if that module is loaded. */

একটি খারাপ উদাহরণ:

/* instantiate clsUser */

আপনি যদি কোডের "বিভাগ" হিসাবে মন্তব্যগুলি ব্যবহার করছেন: আপনার বিশাল পদ্ধতিটি ছোট, দরকারী নামযুক্ত ফাংশনগুলিতে কাটা এবং মন্তব্যগুলি সরিয়ে ফেলুন।

আপনি যদি পরবর্তী লাইনে যা করছেন তা যদি বলছেন: কোডটি স্ব-বর্ণনামূলক করুন এবং মন্তব্যটি সরিয়ে দিন।

আপনি যদি সতর্কতা বার্তাগুলি হিসাবে মন্তব্যগুলি ব্যবহার করছেন: আপনি কেন বলছেন তা নিশ্চিত করুন।

— জনাথন
সূত্র

-2

উত্তরগুলির পরিপূরক করতে আমি যুক্ত করতে পারি "আপনি যদি এটি সঠিকভাবে করতে চান তবে আপনাকে এটি নিজেই করতে হবে।"

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

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

— এম ডুডলি
সূত্র

1

আমি যুক্তি দিয়েছি যে ক্লিনার কোডটি দেখানো / তাদের পাঠ্যকে আরও বেশি পঠনযোগ্য করে তুলতে পুনরায় সংশোধন করা কোডে মন্তব্যগুলির ছাঁটা দেওয়ার চেয়ে আরও বড় পরিবর্তন প্রদর্শন করে।

— মাকোটো

আমার ধারণা সম্পর্কে তারা কী পছন্দ করেন না কেউ আমাকে ব্যাখ্যা করতে পারেন ...?

— এম ডুডলি

-6

সহজ: যদি কর্মচারী shift+alt+jমন্তব্য না করে তবে কোডটি প্রবেশের সাথে সাথে প্রতিটি পদ্ধতিতে স্বয়ংক্রিয় মন্তব্যের জন্য তাকে চাপতে বলুন । এই সমস্যাগুলি এড়াতে দয়া করে কোড রিভিশন করুন।

— পিটার
সূত্র

11

"অটো কমেন্ট"? সুতরাং সেই সমস্ত "ইনক্রিমেন্ট আই বাই 1" মন্তব্যগুলি কোথা থেকে আসছে? কোন আইডিই এটি করে (তাই আমি যেখানে কাজগুলি এটি ব্যবহৃত হচ্ছে তা এড়াতে পারি)?

— একটি সিভিএন

আমি এটি পাঠযোগ্য কিছুতে এডিট করার চেষ্টা করেছি, তবে আমি নিশ্চিত নই যে শব্দটির প্রথমে কমা থাকা উচিত কিনা তার আগে বা তার পরে। এই শব্দগুচ্ছটি কি প্রতিটি পদ্ধতিতে প্রথমে মন্তব্য করে বা প্রথমে বলে ?

— ট্রিগ