কোনও পদ্ধতির মন্তব্যে যখন প্রায়শই একই রকম হয় তখন কী সংক্ষিপ্তসার এবং বিবরণ উভয়ই অন্তর্ভুক্ত করা উচিত?


10

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

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

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

/// <summary>
///     Determines whether the List<T> contains elements
///     that match the conditions defined by the specified predicate.
/// </summary>
/// <returns>
///     true if the List<T> contains one or more elements that match the
///     conditions defined by the specified predicate; otherwise, false.
/// </returns>
public bool Exists( Predicate<T> match )
{
    ...
}

Summaryএবং returnsমূলত একই জিনিস বলছে। আমি প্রায়শই ডকুমেন্টেশন পুরোপুরি returnsবাদ দিয়ে দৃষ্টিকোণ থেকে সারাংশ লেখার শেষ করি returns

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

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

  1. কেন কখনও আপনার returnsথেকে আলাদা করে নথির প্রয়োজন হবে summary?
  2. মাইক্রোসফ্ট কেন এই স্ট্যান্ডার্ড গ্রহণ করেছে সে সম্পর্কে কোনও তথ্য?

উত্তর:


3

আপনি একে অপরের থেকে অনুমান করতে পারেন, তবে এই দুটি বিভাগ পৃথক থেকে যায়, কারণ এটি কোডটি পর্যালোচনা / ব্যবহার করার সময় ব্যক্তির আগ্রহের দিকে মনোনিবেশ করতে সহায়তা করে

আপনার উদাহরণ গ্রহণ করে, আমি বরং লিখতে চাই:

/// <summary>
/// Determines whether the List<T> contains elements that match the conditions
/// defined by the specified predicate.
/// </summary>
/// <returns>
/// A value indicating whether at least one element matched the predicate.
/// </returns>
public bool Exists(Predicate<T> match)
{
    ...
}
  • যদি আমি এই কোডটি পর্যালোচনা করছি এবং আমি পদ্ধতিটি কী করে তা জানতে চাই, আমি সংক্ষিপ্তসারটি পড়ি এবং এটিই আমার যত্নশীল।

  • এখন, আসুন কল্পনা করুন যে আমি আপনার পদ্ধতিটি ব্যবহার করছি এবং আমি যে রিটার্ন মান পেয়েছি তা আশ্চর্যজনক, ইনপুটটি দিয়ে। এখন, আমি পদ্ধতিটি কী তা সত্যিই জানতে চাই না, তবে আমি ফেরতের মান সম্পর্কে আরও কিছু জানতে চাই। এখানে <returns/>বিভাগটি সহায়তা করে এবং আমার সারাংশটি পড়ার দরকার নেই।

আবার এই উদাহরণে আপনি সংক্ষিপ্তসারটি নির্ধারণ করতে পারেন <returns/>, এবং সংক্ষিপ্তসার থেকে প্রত্যাশিত রিটার্ন মানটি নির্ধারণ করতে পারেন। কিন্তু চরম একই যুক্তি গ্রহণ, সব আপনার পদ্ধতি দস্তাবেজ হিসেবে রাখার জন্য কোন প্রয়োজন নেই পদ্ধতির নাম, ভিতরে রাখা: এই ক্ষেত্রে List<T>সঙ্গে, Predicate<T> matchযেমন একমাত্র যুক্তি বেশ নিজেই স্পষ্ট হয়।

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


1
আপনি কোনও পদ্ধতিতে কল করছেন এবং এটি কী করে তা আপনি জানতে চান না !?
জে কে।

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

2

আমার ব্যবহার: পদ্ধতিটি কী করে তা
<summary> বর্ণনা করে (পাওয়ার জন্য <returns>)।
<returns>বর্ণনারিটার্ন মান

দুটিই MSDN বিষয়সমূহ <summary><returns>


লিঙ্কের জন্য ধন্যবাদ। তবে কোথাও এমএসডিএন ডকুমেন্টেশন summaryরাষ্ট্রটির বর্ণনা দেয় না যে এটি 'পদ্ধতিটি কী করে' describes এমএসডিএন কী বলে এবং আপনি এটি কী হিসাবে তৈরি করেন তার মধ্যে পার্থক্য স্পষ্ট করে আপনার উত্তর আপডেট করার জন্য সময় না দেওয়া পর্যন্ত আমি ভোট দিয়েছি। ; পি
স্টিভেন জিউরিস

2
এমএসডিএন এ সম্পর্কে কিছু বলুক বা না করুক, এটি আসলে একটি ভাল গাইডলাইন। আপনার উদাহরণে, আপনাকে পুরো সারাংশটি পুনরাবৃত্তি করতে হবে না, আপনি কেবল " trueপ্রিডিকেটটি মিললে প্রত্যাবর্তন" বলতে পারেন। যদি কারও যদি জানতে হয় যে কোনও ম্যাচটি কী গঠন করে তবে তারা বাকী ডকুমেন্টেশন পড়তে পারেন।
blrfl

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

@ স্টিভেন জিউরিস: এমএসডিএন ডকুমেন্টেশনের লিঙ্কগুলি কেবলমাত্র পরিপূরক তথ্য ছিল। দুটিই MSDN বলে না, "যখন আপনি একটি আছে <summary>এবং <returns>এই কাজের জন্য"। যেমন ব্লারফ্ল্ল বলেছেন, এটি কেবলমাত্র একটি গাইডলাইন যা ব্যবহার করতে বা না চাইতে পারে।
জেক বার্গার

1
@ স্টিভেন জিউরিস: যদিও এটি লেখা হয়েছিল সেই কারণে, আমি দেখতে পেলাম যে কেউ এমএসডিএন থেকে এসেছিল কীভাবে অনুমান করতে পারে।
জ্যাক বার্গার

1

আপনার কেন কখনও সংক্ষিপ্ততা থেকে পৃথক করে রিটার্ন ডকুমেন্টের প্রয়োজন হবে?

আমি মনে করি সংক্ষিপ্ত অংশটি যদি সত্যিই দীর্ঘ এবং বর্ণনামূলক হয় তবে এটির শেষে একটি পৃথক, সংক্ষিপ্ত রিটার্ন অংশ থাকা কার্যকর হতে পারে।

আমি সাধারণত <summary>নিজের কোডটিতে কেবলমাত্র অংশটি লিখি , আপনি "রিটার্নস _ " বলার মতো করে শব্দটি লিখে ।

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


1

আমি ইদানীং একই দার্শনিক প্রশ্নের দ্বারা ছিঁড়ে গিয়েছি এবং এখনও ভাল সমাধান কী তা আমি নিশ্চিত নই। তবে এখন পর্যন্ত এটি আমার পদ্ধতির ...

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

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

0

সংক্ষিপ্ত বিবরণী হিসাবে দরকারী হিসাবে কার্যকর হতে হবে; প্যারামিটারের বিবরণ এবং রিটার্ন মান সংক্ষিপ্ত এবং মিষ্টি হওয়া উচিত। আপনার যদি একটি শব্দ এবং পাঁচটির মধ্যে পছন্দ হয় তবে একটি ব্যবহার করুন। আসুন আপনার উদাহরণটি আরও দৃighten় করুন:

সত্য যদি তালিকায় একটি বা একাধিক উপাদান থাকে যা নির্দিষ্ট প্রিকিকেট দ্বারা সংজ্ঞায়িত শর্তগুলির সাথে মেলে; অন্যথায়, মিথ্যা।

হয়ে

তালিকার কোনও উপাদান যদি পূর্বনির্দেশের সাথে মেলে তবে সত্য; অন্যথায় মিথ্যা।


প্রকৃতপক্ষে, এ জাতীয় লেখা আমাকে " মাইক্রোসফ্ট কিনা তা নির্ধারণ করে ..." দিয়ে শুরু করার মাইক্রোসফ্টের স্ট্যান্ডার্ড পদ্ধতির সুবিধার বিষয়টি উপলব্ধি করে তোলে । আমি মনে করি এটি আরও পঠনযোগ্য কারণ এটি এর ফলাফল কী তা বলার আগে এটি প্রথমে এটি কী করছে তা ব্যাখ্যা করে। এটি ইন্ডিরিশনের এক ধাপ কম। আমি একমত যে returnsমাইক্রোসফ্ট থেকে আসা দীর্ঘ দীর্ঘ। যদি এটি কিছু করা উচিত হয় তবে কেবল এটির সত্যতা নিশ্চিত করা সত্যটির অর্থ এটি মেলে এবং এটি মিথ্যা নয়।
স্টিভেন জিউরিস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.