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

Question

অনেক দিন আগে আমি এডিএতে প্রচুর প্রোগ্রাম করেছিলাম, এবং কোনও ফাংশনটি চাওয়ার সময় যুক্তিগুলির নামকরণ করা স্বাভাবিক ছিল - সুমোবজেক্ট.ডোসোমিংথিং (সোমারপ্যারামিটারনেম => কিছু ভ্যালু);

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

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

কন্টেন্টফ্যাচার.ডাউনলোড নোট (নোট, ম্যানুয়াল: সত্য);

আমার ধারণা আমি সত্য বা মিথ্যা (ম্যানুয়াল, এক্ষেত্রে স্বয়ংক্রিয়) ব্যবহার করার পরিবর্তে এনাম তৈরি করতে পারি।

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

Comments

পদ্ধতির শীর্ষে পরামিতি মন্তব্যও সহায়তা করে।

— আমির রেজায়ে

@ আমির-রেজায়ে: পদ্ধতির শীর্ষে পরামিতি মন্তব্যগুলি কেবলমাত্র যদি আপনি মন্তব্যগুলিতে বিশ্বাস করতে পারেন তবে সহায়তা করে। আপনার যদি ভাল বিকাশকারী এবং ভাল কোড পর্যালোচনা প্রক্রিয়া না থাকে তবে আমি মন্তব্যগুলিতে বিশ্বাস করব না।

— btilly

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

— স্টিভ 314

আমি অ্যাডায় আপনার ব্যবহারকে পুনরায় জানাতে সম্মত all এটি আমরা সমস্ত সময় কিছু করি নি, তবে এটি যেখানে সহায়তা করেছিল।

— দামিয়ান

Answer 1

এটি সি ++ এর বিকাশে প্রস্তাবিত হয়েছিল, এবং স্ট্রোস্ট্রাপ তার "সি ++ এর ডিজাইন এবং বিবর্তন", পৃষ্ঠা 153 এবং এর পরে আলোচনা করেছেন। প্রস্তাবটি সু-গঠিত হয়েছিল, এবং আদার সাথে পূর্বের অভিজ্ঞতার দিকে আকৃষ্ট হয়েছিল। এটি গৃহীত হয়নি।

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

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

এটি ফাংশন কলের চেয়ে অবজেক্ট ব্যবহার করে পরিচালনাও করা যায়। এক ডজন প্যারামিটারের সাথে গেট উইন্ডো কলের পরিবর্তে, এক ডজন প্রাইভেট ভেরিয়েবল সহ উইন্ডো ক্লাস তৈরি করুন এবং প্রয়োজনীয় হিসাবে সেটটার যুক্ত করুন। সেটারগুলিকে শৃঙ্খলিত করে, এরকম কিছু লেখা সম্ভব my_window.SetColor(green).SetBorder(true).SetBorderSize(3);। বিভিন্ন ডিফল্টের সাথে বিভিন্ন ফাংশন থাকাও সম্ভব যা ফাংশনটিকে প্রকৃতপক্ষে কাজ করে call

আপনি যদি ডকুমেন্টেশনের প্রভাব সম্পর্কে কেবল চিন্তিত হন তবে contentFetcher.DownloadNote(note, manual : true);আপনি সর্বদা এমন কিছু লিখতে পারেন contentFetcher.DownloadNote(note, /* manual */ true);, সুতরাং এটি ডকুমেন্টেশনে খুব বেশি সহায়কও নয়।

Comments

আমি যখন এডা থেকে সি তে চলে এসেছি তখন মজাদারভাবে যথেষ্ট, আমি আপনার বর্ণিত কনভেনশনটি ব্যবহার শুরু করেছি - কোড পর্যালোচকরা এটিকে ঘৃণা করেছিল। এটি প্রচুর পরিমাণে প্যারামিটারের জন্য ব্যবহার না করে সম্মত হন।

— দামিয়ান

Answer 2

আমি মনে করি এটি "সেরা অনুশীলন" না করে খারাপ কোডটিকে আরও পঠনযোগ্য করে তোলার বিষয়।

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

যখন পদ্ধতিগুলির মধ্যে কেবল 1 বা 2 প্যারামিটার থাকে এবং প্যারামিটার কী তা পদ্ধতির নাম থেকেই স্পষ্ট হয়, নামকরণের প্যারামিটারে কিছুই যুক্ত হয় না। এটি হতে হবে আদর্শ ক্ষেত্রে।

আপনি যে সমস্ত কোডে কাজ করেন সেগুলিকে যদি " ক্লিন কোড " বইয়ের সমতুল্য লেখা হয় তবে নামযুক্ত পরামিতিগুলির জন্য আপনার খুব কম ব্যবহার হবে, তবে আমরা আসল বিশ্বে থাকি।

Comments

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

— স্টিভ 314

@ স্টিভ 314 উদাহরণ:void TrackDataChange(Data oldData, Data newData)

— আলেকজান্ডার

Answer 3

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

public Content DownloadNote(Note note)
{
    return downloadNote(note, manual: false);
}

public Content DownloadNoteManually(Note note)
{
    return downloadNote(note, manual: true);
}

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

Comments

আপনার যদি এক্স পছন্দ থাকে তবে আপনি কি 2 ^ x সামনের অংশ তৈরি করবেন?

— apoorv020

@ apoorv020 - যদি আমার কাছে কোনও পদ্ধতি কলের পর্যাপ্ত পরামিতি থাকে যে 2 ^ x তাৎপর্যপূর্ণ হয়ে ওঠে, আমি প্যারামিটারের মানগুলি ধরে রাখতে একটি নতুন শ্রেণি তৈরি করব এবং কেবল একটি পরামিতি পাস করব।

— স্কট হুইটলক

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

— btilly

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

— স্কট হুইটলক

@ স্কট-হুইটলক: আমরা কি আসলেই একমত নই? আমরা সি # এ যা সেরা তা নিয়ে একমত। ক্লিন কোড কী বলে আমরা উভয়েই জানি। আমার বক্তব্যটি হ'ল এটি কেন ভাল তা বোঝা গুরুত্বপূর্ণ, যাতে আপনি জানেন যে কখন পরামর্শটি কোনও ভিন্ন পরিবেশের সাথে খাপ খায় না।

— btilly

Answer 4

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

বলা হচ্ছে, নামযুক্ত প্যারামিটারগুলি বুদ্ধিমান যুক্তি তালিকা তৈরির জন্য সহায়ক সাহায্যকারী বস্তুগুলি (শব্দার্থে সম্পর্কিত যুক্তিগুলির সাথে "টাই" করতে) এবং প্রাসঙ্গিক যেখানে গণনাগুলি ব্যবহার করা উচিত নয়।

Answer 5

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

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