প্রয়োজন না হলেও alচ্ছিক প্যারামিটারের নামগুলি নির্দিষ্ট করুন?

Question

নিম্নলিখিত পদ্ধতিটি বিবেচনা করুন:

public List<Guid> ReturnEmployeeIds(bool includeManagement = false)
{

}

এবং নিম্নলিখিত কল:

var ids = ReturnEmployeeIds(true);

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

var ids = ReturnEmployeeIds(includeManagement: true);

সংকলকটি আপনার প্রয়োজন না হলে আনুষ্ঠানিকভাবে anywhereচ্ছিক প্যারামিটারগুলি স্পষ্টভাবে নির্দিষ্ট করতে হবে কি না সে সম্পর্কে আনুষ্ঠানিকভাবে কোথাও আছে কি?

নিম্নলিখিত নিবন্ধে কিছু কোডিং কনভেনশন আলোচনা করা হয়েছে: https://msdn.microsoft.com/en-gb/library/ff926074.aspx

উপরের নিবন্ধটির অনুরূপ কিছু দুর্দান্ত হবে।

Comments

এগুলি দুটি বরং অপ্রাসঙ্গিক প্রশ্ন: (1) স্বচ্ছতার জন্য আপনার optionচ্ছিক যুক্তিগুলি লিখতে হবে? (২) কারও কি booleanপদ্ধতি যুক্তি ব্যবহার করা উচিত এবং কীভাবে?

— কিলিয়ান ফট

এই সমস্ত ব্যক্তিগত পছন্দ / শৈলী / মতামত ফোটে। ব্যক্তিগতভাবে, আমি প্যারামিটারের নামগুলি পছন্দ করি যখন পাস করা মানটি আক্ষরিক হয় (একটি ভেরিয়েবল ইতিমধ্যে এর নামের মাধ্যমে পর্যাপ্ত তথ্য পৌঁছে দিতে পারে)। তবে, এটি আমার ব্যক্তিগত মতামত।

— মেটাফাইট

আপনার প্রশ্নে উদাহরণস্বরূপ সেই লিঙ্কটি অন্তর্ভুক্ত করবেন?

— মেটাফাইট

যদি এটি কিছু যোগ করে তবে আমি এটিকে স্টাইলকপ এবং রিশার্পার দিয়ে চালিয়েছি - এটির সম্পর্কেও স্পষ্ট দৃষ্টিভঙ্গি ছিল না। রিশার্পার কেবল বলেছে নামকরণ করা প্যারামিটারটি সরানো যেতে পারে এবং তারপরে একটি নামক প্যারামিটার যুক্ত করা যেতে পারে। আমার ধারণা অনুমান করার জন্য পরামর্শটি নিখরচায় ...: - /

— রবি ডি

পঠনযোগ্যতা সহায়তা হিসাবে নামযুক্ত তর্কগুলি (পরামিতি)

— ডক ব্রাউন

Answer 1

আমি বলব যে সি # বিশ্বে একটি এনাম এখানে সেরা বিকল্পগুলির মধ্যে একটি হবে।

এটির সাহায্যে আপনি কী করছেন তা বানান করতে বাধ্য হবেন এবং যে কোনও ব্যবহারকারী কী ঘটবে তা দেখতে পাবেন। এটি ভবিষ্যতের এক্সটেনশনের জন্যও নিরাপদ;

public enum WhatToInclude
{
    IncludeAll,
    ExcludeManagement
}

var ids = ReturnEmployeeIds(WhatToInclude.ExcludeManagement);

সুতরাং, এখানে আমার মতে:

এনাম> alচ্ছিক এনাম> alচ্ছিক বুল

সম্পাদনা করুন: নীচে লিওপার্ডস্কিনপিলবক্সহ্যাটের সাথে এনামের বিষয়ে আলোচনার কারণে [Flags]যা এই নির্দিষ্ট ক্ষেত্রে ভাল উপযুক্ত হতে পারে (যেহেতু আমরা বিশেষত জিনিসগুলি অন্তর্ভুক্ত / বাদ দেওয়ার বিষয়ে কথা বলছি), আমি পরিবর্তে ISet<WhatToInclude>প্যারামিটার হিসাবে ব্যবহার করার প্রস্তাব দিই ।

এটি বেশ কয়েকটি সুবিধার সাথে আরও একটি "আধুনিক" ধারণা, এটি বেশিরভাগ ক্ষেত্রেই সংগ্রহের লিনকিউ পরিবারে ফিট করে তবে [Flags]এটি সর্বাধিক ৩২ টি গোষ্ঠী থেকে উদ্ভূত হয় । ব্যবহারের মূল ক্ষতি ISet<WhatToInclude>হচ্ছে সি # সিনট্যাক্সে কীভাবে খারাপ সেটগুলি সমর্থন করা হয়:

var ids = ReturnEmployeeIds(
    new HashSet<WhatToInclude>(new []{ 
        WhatToInclude.Cleaners, 
        WhatToInclude.Managers});

সেটটি তৈরি করতে এবং "শর্টকাট সেট" তৈরি করার জন্য উভয় সহায়ক ফাংশন দ্বারা এর কিছুটা হ্রাস করা যেতে পারে

var ids = ReturnEmployeeIds(WhatToIncludeHelper.IncludeAll)

Comments

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

— ড্যান নীলি

আমি enumঅ্যাপ্রোচটি পছন্দ করি তবে আমি মিশ্রনের বিশাল ফ্যান নই Includeএবং Excludeএকই enumসাথে এটি কী চলছে তা বোঝা আরও কঠিন difficult আপনি যদি এটি সত্যই এক্সটেনসিবল হতে চান তবে আপনি এটিকে একটি তৈরি করতে পারেন [Flags] enum, সেগুলি তৈরি করতে পারেন IncludeXxxএবং IncludeAllসেট করা একটি সরবরাহ করতে পারেন Int32.MaxValue। তারপরে আপনি ২ টি ReturnEmployeeIdsওভারলোড সরবরাহ করতে পারবেন - একটি যা সমস্ত কর্মচারীদের ফিরিয়ে দেয় এবং একটি যা WhatToIncludeফিল্টার পরামিতি নেয় যা এনাম পতাকাগুলির সংমিশ্রণ হতে পারে।

— চিতাবাঘ স্কিনপিলবক্সহ্যাট 20'16

@ লিওপার্ডস্কিনপিলবক্সহ্যাট ঠিক আছে, আমি বাদ / অন্তর্ভুক্তিতে সম্মত। সুতরাং এটি একটি বিবাদযুক্ত উদাহরণের একটি বিট, কিন্তু আমি এটি IncludAllButManagement বলা যেতে পারে। আপনার অন্য বক্তব্যটিতে, আমি সম্মত নই - আমি মনে করি [Flags]একটি প্রতীক এবং কেবল উত্তরাধিকার বা পারফরম্যান্স কারণে ব্যবহার করা উচিত। আমি মনে করি একটি ISet<WhatToInclude>একটি আরও উন্নত ধারণা (দুর্ভাগ্যক্রমে সি # এটি ব্যবহার করতে সুন্দর করার জন্য কিছু সিনট্যাকটিক চিনির অভাব রয়েছে)।

— নিক্লাসজে

@ নিক্লাসজে - আমি এই Flagsপদ্ধতির পছন্দ করি কারণ এটি কলারকে যেতে দেয় WhatToInclude.Managers | WhatToInclude.Cleanersএবং বিটওয়াইস করে বা কলার কীভাবে প্রক্রিয়া করবে (যেমন পরিচালক বা ক্লিনার) ঠিক তা প্রকাশ করে। স্বজ্ঞাত সিনট্যাকটিক চিনি :-)

— চিতাবাঘ স্কিনপিলবক্সহ্যাট

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

— নিক্লাসজে

Answer 2

এটি কি লেখার অর্থ দেয়:

 var ids=ReturnEmployeeIds(includeManagement: true);

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

 bool includeManagement=true;
 var ids=ReturnEmployeeIds(includeManagement);

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

সুতরাং আমার সুপারিশ: আপনি যদি মনে করেন যে এনাম বা দুটি ফাংশন বিভিন্ন নামের সাথে ব্যবহার করা "ওভারকিল" হয়, বা আপনি ভিন্ন কারণে স্বাক্ষরটি পরিবর্তন করতে বা করতে চান না, তবে এগিয়ে যান এবং নামক প্যারামিটারটি ব্যবহার করুন।

Comments

আপনি যে দ্বিতীয় উদাহরণটিতে অতিরিক্ত মেমরি ব্যবহার করছেন তা নোট করতে চান

— আলভোরো

@ আলভারো এই ধরনের তুচ্ছ মামলায় (যেখানে ভেরিয়েবলের ধ্রুবক মান থাকে) ক্ষেত্রে এটি সত্য হওয়ার সম্ভাবনা খুব বেশি। এটি থাকলেও, এটি উল্লেখ করার মতো খুব কমই। আমাদের বেশিরভাগ লোক আজকাল 4KB র‌্যামে চলছে না।

— ক্রিস হেইস

এটি সি # includeManagementহওয়ায় আপনি স্থানীয় হিসাবে চিহ্নিত করতে পারেন constএবং কোনও অতিরিক্ত মেমরি ব্যবহার করা এড়াতে পারেন।

— জ্যাকব কুলরে

বন্ধুরা, আমি আমার উত্তরে এমন কোনও জিনিস যুক্ত করতে যাচ্ছি না যা কেবল এখানে গুরুত্বপূর্ণ বলে আমার দৃষ্টিভঙ্গি থেকে বিরত থাকতে পারে।

— ডক ব্রাউন 21

Answer 3

আপনি যদি কোডটির মুখোমুখি হন:

public List<Guid> ReturnEmployeeIds(bool includeManagement = false)
{

}

আপনি বেশ গ্যারান্টি দিতে পারেন যা অভ্যন্তরের অভ্যন্তরে রয়েছে {}এমন কিছু হবে:

public List<Guid> ReturnEmployeeIds(bool includeManagement = false)
{
    if (includeManagement)
        return something
    else
        return something else
}

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

public List<Guid> GetNonManagementEmployeeIds()
{

}

public List<Guid> GetAllEmployeeIds()
{

}

এটি উভয়ই কোডের পঠনযোগ্যতার উন্নতি করে এবং নিশ্চিত করে যে আপনি সলিডের নীতিগুলি অনুসরণ করছেন।

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

এই ক্ষেত্রে, কম্পাইলারের প্রয়োজন না থাকলেও পরামিতিটির নাম সরবরাহ করা উচিত? আমি প্রস্তাব দিচ্ছি যে এর সহজ কোনও উত্তর নেই এবং কেস ভিত্তিতে কোনও মামলার বিচারের প্রয়োজন:

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

public List<Guid> GetNonManagementEmployeeIds()
{
    return ReturnEmployeeIds(true);
}

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

Comments

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

— JᴀʏMᴇᴇ

সব সত্য, তবে প্রশ্নটি ছিল এই জাতীয় পদ্ধতির কল সম্পর্কে । এছাড়াও একটি পতাকা প্যারামিটার পদ্ধতিতে কোনও শাখার গ্যারান্টি দেয় না। এটি কেবল অন্য স্তরে চলে যেতে পারে।

— রবি ডি

এটি ভুল নয়, তবে অবিচ্ছিন্ন। বাস্তব কোডে, আপনি খুঁজে পাবেন public List<Guid> ReturnEmployeeIds(bool includeManagement) { calculateSomethingHereForBothBranches; if (includeManagement) return something else return something else }, সুতরাং বিভক্ত হওয়া যে কেবল দুটি পদ্ধতির মধ্যে সম্ভবত সম্ভবত এই দুটি পদ্ধতির প্যারামিটার হিসাবে প্রথম গণনার ফলাফলের প্রয়োজন হবে।

— ডক ব্রাউন

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

— মেটাফাইট

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

— jpmc26

Answer 4

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

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

উদাহরণস্বরূপ, এটি একটি কল পরিষ্কার করতে সহায়তা করবে তবে অগত্যা অন্য কল।

একটি নামযুক্ত যুক্তি এখানে সহায়ক হতে পারে:

var ids = ReturnEmployeeIds(includeManagement: true);

অতিরিক্ত অতিরিক্ত স্পষ্টতা যুক্ত করবেন না (আমি অনুমান করতে যাচ্ছি যে এটি একটি এনামকে পার্স করছে):

Enum.Parse(typeof(StringComparison), "Ordinal", ignoreCase: true);

এটি প্রকৃতপক্ষে স্বচ্ছতা হ্রাস করতে পারে (যদি কোনও ব্যক্তি যদি বুঝতে পারে না যে তালিকার কী ক্ষমতা আছে):

var employeeIds = new List<int>(capacity: 24);

বা যেখানে আপনার ভাল ভেরিয়েবল নাম ব্যবহার করা হচ্ছে সে কারণে এটির কোনও গুরুত্ব নেই:

bool includeManagement = true;
var ids = ReturnEmployeeIds(includeManagement);

সংকলকটি আপনার প্রয়োজন না হলে আনুষ্ঠানিকভাবে anywhereচ্ছিক প্যারামিটারগুলি স্পষ্টভাবে নির্দিষ্ট করতে হবে কি না সে সম্পর্কে আনুষ্ঠানিকভাবে কোথাও আছে কি?

আফাইক নয়। যদিও উভয় অংশকে সম্বোধন করা যাক: কেবলমাত্র নামমাত্র পরামিতিগুলি আপনাকে স্পষ্টভাবে ব্যবহার করার প্রয়োজন কারণ সংকলকটির এটি করা প্রয়োজন (সাধারণত এটি বিবৃতি অস্পষ্টতা অপসারণ করে)। সুতরাং এগুলি ব্যতীত আপনি যখনই চান সেগুলি ব্যবহার করতে পারেন। মাইক্রোসফট থেকে এই নিবন্ধটি যখন আপনি তাদের ব্যবহার করতে চান পারে কিছু প্রস্তাবনা রয়েছে কিন্তু এটা বিশেষ করে নির্ধারক নয় https://msdn.microsoft.com/en-us/library/dd264739.aspx ।

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

টি এল; ডিআর

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

Answer 5

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

সাথে ReturnEmployeeIds(true), যেমনটি আপনি বলেছেন, আপনি যদি ফাংশনটির ঘোষণাপত্র / ডকুমেন্টেশনগুলি না দেখেন তবে এর trueঅর্থ কী তা বোঝা অসম্ভব - সুতরাং আপনার নামযুক্ত প্যারামিটার সিনট্যাক্সটি ব্যবহার করা উচিত ।

এখন, এই তৃতীয় কেসটি বিবেচনা করুন:

void PrintEmployeeNames(bool includeManagement) {
    foreach (id; ReturnEmployeeIds(includeManagement)) {
        Console.WriteLine(ReturnEmployeeName(id));
    }
}

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

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

Comments

আমি অসম্মতি জানাই যে ReturnEmployeeName(57)এটি তাত্ক্ষণিকভাবে স্পষ্ট করে দেয় 57এটিই আইডি। GetEmployeeById(57)অন্যদিকে ...

— হুগো জিঙ্ক

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

— ইদান আরে

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

— জে

Answer 6

হ্যাঁ, আমি মনে করি এটি ভাল স্টাইল।

এটি বুলিয়ান এবং পূর্ণসংখ্যার ধ্রুবকগুলির জন্য সর্বাধিক উপলব্ধি করে।

আপনি যদি কোনও ভেরিয়েবলের মধ্যে দিয়ে যাচ্ছেন তবে চলক নামের অর্থটি পরিষ্কার করা উচিত। যদি এটি না হয় তবে আপনার চলকটির আরও ভাল নাম দেওয়া উচিত।

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

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

এবং আমি মনে করি একটি স্ট্রিং বিভ্রান্তিকর হতে পারে। আমার উপরের উদাহরণে "ওরেগন" রাষ্ট্রকে নয়, কোনও পণ্য বা ক্লায়েন্ট বা যা কিছুকে বোঝায়।

তবে গেটফুডাটা (সত্য) বা গেটফুডাটা (৪২) ... এর অর্থ কোনও অর্থ হতে পারে। নামযুক্ত প্যারামিটারগুলি এটিকে স্ব-ডকুমেন্টিং করার একটি দুর্দান্ত উপায়। আমি এগুলি বেশ কয়েকটি উপলক্ষে ঠিক সেই উদ্দেশ্যে ব্যবহার করেছি।

Answer 7

এই ধরণের সিনট্যাক্সটিকে প্রথমে কেন ব্যবহার করবেন সে সম্পর্কে কোনও সুস্পষ্ট কারণ নেই reasons

সাধারণত, বুলিয়ান যুক্তিগুলি এড়াতে চেষ্টা করুন যা দূরত্বে নির্বিচারে দেখা যায়। includeManagement(সম্ভবত সম্ভবত) ফলাফল প্রভাবিত করবে। তবে যুক্তি দেখে মনে হচ্ছে এটি "সামান্য ওজন" বহন করে।

এনামের ব্যবহার নিয়ে আলোচনা করা হয়েছে, এটি কেবল "আরও ওজন বহন করে" যুক্তিটির মতো দেখাবে না, তবে এটি পদ্ধতিতে স্কেলিবিলিটিও সরবরাহ করবে। এটি তবে সব ক্ষেত্রেই সেরা সমাধান নাও হতে পারে, যেহেতু আপনার ReturnEmployeeIds-াদমাদিকে -enum পাশাপাশি স্কেল করতে হবে WhatToInclude( নিক্লাসজে জবাব দেখুন)। এটি পরে আপনাকে মাথাব্যথা দেয়।

এটি বিবেচনা করুন: আপনি যদি-স্কেলটি স্কেল করেন WhatToIncludeতবে তবে-আদর্শ নয় ReturnEmployeeIds। এটি তখন একটি ArgumentOutOfRangeException(সেরা কেস) নিক্ষেপ করতে পারে বা পুরোপুরি অযাচিত কিছু ( nullবা একটি খালি List<Guid>) ফিরিয়ে দিতে পারে । যা কিছু ক্ষেত্রে প্রোগ্রামারকে বিভ্রান্ত করতে পারে, বিশেষত যদি ReturnEmployeeIdsআপনি কোনও শ্রেণি-গ্রন্থাগারে থাকেন, যেখানে উত্স-কোডটি সহজেই পাওয়া যায় না।

প্রশিক্ষণার্থীরা সবার "সাবসেট" হয়ে দেখে যে কেউ WhatToInclude.Traineesযদি WhatToInclude.Allতা করে তবে তা কাজ করবে বলে ধরে নেওয়া হবে।

এটি (অবশ্যই) কার্যকর করে কীভাবে তার উপর নির্ভর করে ReturnEmployeeIds।

---

যে ক্ষেত্রে বুলিয়ান আর্গুমেন্টটি প্রবেশ করা যেতে পারে, আমি আপনার পরিবর্তে এটি দুটি পদ্ধতির (বা আরও বেশি প্রয়োজন হলে) বিভক্ত করার চেষ্টা করি; এক নিষ্কাশন হতে পারে ReturnAllEmployeeIds, ReturnManagementIdsএবং ReturnRegularEmployeeIds। এটি সমস্ত ঘাঁটিগুলিকে আচ্ছাদন করে এবং যে কেউ এটি প্রয়োগ করে তার পক্ষে একেবারে স্ব-বর্ণনামূলক। এটিতে উপরে উল্লিখিত "স্কেলিং" -বিধিও থাকবে না।

যেহেতু বুলিয়ান যুক্তিযুক্ত কোনও কিছুর জন্য কেবল দুটি ফলাফল রয়েছে। দুটি পদ্ধতি প্রয়োগ করা, খুব সামান্য পরিমাণে প্রচেষ্টা গ্রহণ করে।

কম কোড, খুব কমই ভাল।

---

সঙ্গে এই কথা, সেখানে আছে কিছু কিছু ক্ষেত্রে যেখানে স্পষ্টভাবে যুক্তি প্রকাশক পাঠযোগ্যতা উন্নত। উদাহরণস্বরূপ বিবেচনা করুন। GetLatestNews(max: 10)। GetLatestNews(10)হয় এখনও স্বশাসিত প্রশংসনীয়, এর স্পষ্ট ঘোষণা maxইচ্ছা সাহায্যের পরিষ্কার কোনো বিহ্বলতায়।

এবং যদি আপনার অবশ্যই একটি বুলিয়ান যুক্তি থাকতে পারে যা কেবলমাত্র পড়ার মাধ্যমে trueবা ব্যবহারটি অনুমান করা যায় না false। তারপরে আমি বলব:

var ids = ReturnEmployeeIds(includeManagement: true);

.. একেবারে ভাল এবং এর চেয়ে বেশি পাঠযোগ্য:

var ids = ReturnEmployeeIds(true);

যেহেতু দ্বিতীয় উদাহরণে, এর trueঅর্থ হ'ল একেবারে কিছু । তবে আমি এই যুক্তি এড়াতে চেষ্টা করব।