আপনি কি কোড মন্তব্যে শিরোনাম লিখেন? [বন্ধ]


17

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

/*Board initialization*/
...code...

/*Player initialization*/
...code...

/*Game logic starts here*/
/*Displaying current situation*/
...code...

/*Executing move*/
...code...

/*Handle special event*/
...code...

/*Commit changes, switch to next player*/
...code...

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

উত্তর:


24

এটি একটি কোড গন্ধ। এটি কি এবং না কেন বলে

এটি প্রয়োজনীয় হলে কোডটি ছোট ফাংশনে বিভক্ত করুন।


4
ফাংশন রাখার কোনও অর্থ নেই।
পল নাথান

30
সঠিক: কোডটি যদি মতামতের মতো দাবি করে /*Board initialization*/তবে সম্ভবত এটির একটি ফাংশন থাকা উচিত InitializeBoard। যদি আপনার কোড কাঠামো যথেষ্ট পরিস্কার থাকে তবে আপনার মন্তব্যগুলির প্রয়োজন হবে না।
টিম রবিনসন

3
"কি" জানা ভাল এবং কোডটি দেখার থেকে প্রায়শই সুস্পষ্ট হয় না। এই মন্তব্যগুলি সামগ্রিক উদ্দেশ্যকে পরিষ্কার করে।
DarenW

4
@ ড্যারেনডাব্লু - তবে ফাংশন / পদ্ধতি / পদ্ধতিগুলি করুন। এবং পরবর্তীকালে কোডটি আধুনিকীকরণের অতিরিক্ত সুবিধা রয়েছে যা এটি বুঝতে সহজ করে তোলে ।
স্টিফেন সি

3
এর আর একটি সুবিধা হ'ল বেশিরভাগ আইডিইর ফাংশন / মডিউল / শ্রেণি ব্রাউজারের তালিকায় যেমন ফাংশনগুলি উপস্থিত হবে InitializeBoardবা InitializePlayerমন্তব্যগুলি আসবে না। আরও সহজ নেভিগেশন।
স্টিভ Filles

13

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


7
+1 - স্পষ্টতা একটি ভাল জিনিস। আমি অনুমোদিত উত্তরের সাথে একমত নই যে এটি কোডের গন্ধ। যদি এটি স্পষ্টতা যোগ করে - এটি করুন।
দ্রুত_ এখন

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

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

6

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


4

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

আমি বলব যদি কোনও দলের মধ্যে কাজ করার জন্য একটি স্ট্যান্ডার্ড নিয়ে আসে যাতে আপনারা কমপক্ষে কোডিং করছেন এবং একইভাবে মন্তব্য করছেন যাতে কোডটি দেখানো আরও সহজ হয়ে যায়।


3

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

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

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


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

2

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

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