পদ্ধতি আর্গুমেন্ট হিসাবে বুলিয়ান কি অগ্রহণযোগ্য? [বন্ধ]

Question

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

বুঝতে সহজ কি?

file.writeData( data, true );

অথবা

enum WriteMode {
  Append,
  Overwrite
};

file.writeData( data, Append );

এখন আমি বুঝতে পেরেছি! ;-)
এটি অবশ্যই একটি উদাহরণ যেখানে দ্বিতীয় প্যারামিটার হিসাবে একটি গণনা কোডটিকে আরও বেশি পঠনযোগ্য করে তোলে।

তো, এই বিষয়ে আপনার মতামত কী?

Comments

এটি একটি খুব আকর্ষণীয় পড়া ছিল, আমি আরও প্রায়ই এই পদ্ধতিটি প্রয়োগ করব।

— সারা চিপস

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

— শনি

এনামগুলি অবশ্যই একটি শব্দার্থক পোভ থেকে আরও অর্থবোধ করে। অন্য একটি নোটে, কিছু প্রোগ্রামার अस्पष्ट যুক্তি পরিচালনা করতে কী সামনে এসেছিল তা দেখতে আকর্ষণীয় হবে।

— জেমস পি।

অ্যাডভেঞ্চার টাইমের লেবু লোকটির কাছে কেবল এটি জিজ্ঞাসা করুন যদি এটি গ্রহণযোগ্য না হয়

— ajax333221

আরও দেখুন: বুলিয়ান প্যারামিটারগুলি - তারা কি গন্ধ পাচ্ছে?

— বার্গি

Answer 1

বুলিয়ান "হ্যাঁ / না" পছন্দগুলি উপস্থাপন করে। আপনি যদি "হ্যাঁ / না" উপস্থাপন করতে চান তবে একটি বুলিয়ান ব্যবহার করুন, এটি স্ব-বর্ণনামূলক হওয়া উচিত।

তবে যদি এটি দুটি বিকল্পের মধ্যে পছন্দ হয়, যার মধ্যে দুটিই পরিষ্কারভাবে হ্যাঁ বা না হয়, তবে একটি এনাম কখনও কখনও বেশি পঠনযোগ্য হতে পারে।

Comments

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

— সাইমন

যদিও এই ক্ষেত্রে আমি সম্ভবত পরিবর্তনের পরিবর্তে টার্নলাইটঅন () এবং টার্নলাইটঅফ () পেয়েছি।

— স্কাফম্যান

"টার্নলাইটঅন (মিথ্যা)" এর অর্থ "আলো চালু করবেন না"? Confusiong।

— জে বাজুজি

কীভাবে setLightOn(bool)।

— ফিনবার

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

— ফিল করুন

Answer 2

এনামগুলি ভবিষ্যতের পরিবর্তনের জন্যও অনুমতি দেয়, যেখানে আপনি এখন তৃতীয় পছন্দ (বা আরও) চান।

Comments

অথবা উইন 32 এর গেটমেসেজ (): সত্য, মিথ্যা, বা -1।

— বিকে

@ ধনী: thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx

— ড্যান ডায়ার

Answer 3

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

lock.setIsLocked(True);

অথবা

enum LockState { Locked, Unlocked };
lock.setLockState(Locked);

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

Comments

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

— রবার্ট পলসন 21

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

— জেরেমি বাউরক

আমি সম্পূর্ণরূপে একমত :), আমি কেবল নির্দিষ্ট সিউডোকোডের প্রস্তাব দিচ্ছিলাম যাতে আরও একটি গ্রহণ করা হয়। আমি আপনার উত্তরের সাথে একমত

— রবার্ট পলসন

Answer 4

আমার কাছে, বুলিয়ান বা গণনা উভয়ই ভাল ব্যবহার নয়। রবার্ট সি মার্টিন তার ক্লিন কোড টিপ # 12 এ এটি খুব স্পষ্টভাবে ক্যাপচার করেছেন : বুলিয়ান যুক্তিগুলি দূর করুন :

বুলিয়ান যুক্তিগুলি জোরে জোরে ঘোষণা করে যে ফাংশনটি একের বেশি কাজ করে। এগুলি বিভ্রান্তিকর এবং তাদের নির্মূল করা উচিত।

যদি কোনও পদ্ধতি একাধিক জিনিস করে তবে আপনার পরিবর্তে দুটি পৃথক পদ্ধতি লেখা উচিত, উদাহরণস্বরূপ আপনার ক্ষেত্রে: file.append(data)এবং file.overwrite(data)।

একটি গণনা ব্যবহার জিনিস পরিষ্কার করে না। এটি কোনও পরিবর্তন করে না, এটি এখনও একটি পতাকা যুক্তি।

Comments

তার মানে কি এই নয় যে কোনও ফাংশন যা ASCII দৈর্ঘ্যের N স্ট্রিং গ্রহণ করে 128 ^ N কাজ করে?

— স্পষ্টভাবে

@ ডেল্টি এটি কি গুরুতর মন্তব্য? যদি হ্যাঁ, আপনি প্রায়শই কোনও স্ট্রিংয়ের সমস্ত সম্ভাব্য মানগুলিতে একটি কোড করেন? বুলিয়ান আর্গুমেন্টের ক্ষেত্রে কি কোনও সম্ভাবনা তুলনা করা যায়?

— পাস্কেল থিভেন্ট

আমি বিশ্বাস করি আপনি যখন কোনও বস্তুর অভ্যন্তরে বুলিয়ান মান নির্ধারণ করেন তখন সেগুলি গ্রহণযোগ্য। একটি নিখুঁত উদাহরণ হবে setVisible(boolean visible) { mVisible = visible; }। আপনার বিকল্পটি কী প্রস্তাব করবে?

— ব্র্যাড

@ ব্র্যাড শো () {এমভিজিবল = সত্য} হাইড () V এমভিজিবল = মিথ্যা}

— ওসওয়াল্ডো অ্যাকান

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

— ব্র্যাড

Answer 5

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

Answer 6

প্রশ্নটি মনে রাখবেন কিউবান ক্ষেপণাস্ত্র সঙ্কটের সময় অ্যাডলাই স্টিভেনসন জাতিসংঘে রাষ্ট্রদূত জোরিনকে জিজ্ঞাসা করেছিলেন ?

"আপনি এই মুহূর্তে বিশ্বের মতামতের আদালতে রয়েছেন, এবং আপনি হ্যাঁ বা না উত্তর দিতে পারেন । আপনি [ক্ষেপণাস্ত্র] বিদ্যমান বলে অস্বীকার করেছেন, এবং আমি আপনাকে সঠিকভাবে বুঝতে পেরেছি কিনা তা জানতে চাই .... আমি অপেক্ষা করার জন্য প্রস্তুত আমার জবাবের জন্য যতক্ষণ না জাহান্নাম জমে যায়, যদি এটি আপনার সিদ্ধান্ত হয়। "

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

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

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

Answer 7

এটি দুষ্কর হওয়ার কারণে দুটি কারণ রয়েছে:

1. কারণ কিছু লোক এ জাতীয় পদ্ধতি লিখবেন:

   ProcessBatch(true, false, false, true, false, false, true);
   

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

2. কারণ সাধারণ হ্যাঁ / কোনও শাখা দ্বারা প্রোগ্রামের প্রবাহ নিয়ন্ত্রণ করার অর্থ আপনার দুটি সম্পূর্ণ ভিন্ন ফাংশন থাকতে পারে যা একটি বিশ্রী উপায়ে একটিতে আবৃত। এই ক্ষেত্রে:

   public void Write(bool toOptical);
   

   সত্যই, এটি দুটি পদ্ধতি হওয়া উচিত

   public void WriteOptical();
   public void WriteMagnetic();
   

   কারণ এগুলির কোড সম্পূর্ণ আলাদা হতে পারে; তাদের বিভিন্ন ধরণের ত্রুটি পরিচালনা ও বৈধকরণ করতে হতে পারে বা বহির্গামী ডেটা অন্যরকম ফর্ম্যাট করতেও পারে। আপনি কেবল এটি ব্যবহার করে Write()বা এমনকি Write(Enum.Optical)এটিও বলতে পারবেন না (যদিও আপনি অবশ্যই এই পদ্ধতিগুলির মধ্যে কেবলমাত্র অভ্যন্তরীণ পদ্ধতিগুলি WritOptical / Mag কল করতে পারেন যদি আপনি চান)।

আমার ধারণা এটি নির্ভর করে। আমি # 1 ব্যতীত এ সম্পর্কে কোনও বড় চুক্তি করব না।

Comments

খুব ভাল পয়েন্ট! একটি পদ্ধতিতে দুটি বুলিয়ান প্যারামিটার ভয়ানক দেখায়, প্রকৃতপক্ষে (যদি আপনি ভাগ্যবান না হন তবে অবশ্যই প্যারামিটারের নামকরণ করা হবে)।

— ইয়ারিক

যদিও এই উত্তরটি কিছু পুনর্নির্মাণ থেকে উপকৃত হতে পারে! ;-)

— ইয়ারিক

Answer 8

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

Comments

কেবল পদ্ধতিটি খুব বর্ণনামূলক করুন যাতে এটি সত্য বা হ্যাঁ এর অর্থ কী তা পরিষ্কার।

— সাইমন

Answer 9

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

file.writeData(data, overwrite=true)

বা:

[file writeData:data overwrite:YES]

Comments

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

— ইয়ারিক

Answer 10

আমি সম্মত হব না যে এটি একটি ভাল নিয়ম । স্পষ্টতই, এনাম কিছু ক্ষেত্রে আরও ভাল সুস্পষ্ট বা ভার্বোজ কোড তৈরি করে, তবে একটি নিয়ম হিসাবে এটি পৌঁছনোর পথে মনে হয়।

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

dim append as boolean = true
file.writeData( data, append );

বা আমি আরও সাধারণ পছন্দ

dim shouldAppend as boolean = true
file.writeData( data, shouldAppend );

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

Comments

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

— ইয়ারিক

Answer 11

এনামগুলির একটি নির্দিষ্ট সুবিধা রয়েছে তবে আপনার সমস্ত বুলিয়ান প্রতিস্থাপনের জন্য কেবল এনামগুলি দিয়ে যাওয়া উচিত নয়। অনেকগুলি জায়গা রয়েছে যেখানে সত্য / মিথ্যা হচ্ছে যা চলছে তা উপস্থাপনের সেরা উপায়।

তবে এগুলি পদ্ধতির আর্গুমেন্ট হিসাবে ব্যবহার করা কিছুটা সন্দেহজনক, কেবল কারণ তারা যা করার কথা সেগুলি খনন করা ছাড়া আপনি দেখতে পাচ্ছেন না, কারণ তারা আপনাকে সত্য / মিথ্যা বলতে আসলে কী বোঝায়

বৈশিষ্ট্যগুলি (বিশেষত সি # 3 অবজেক্ট ইনিশিয়ালাইজার সহ) বা কীওয়ার্ড আর্গুমেন্ট (একটি লা রুবি বা পাইথন) হ'ল আরও ভাল উপায় যেখানে আপনি অন্যথায় বুলিয়ান যুক্তি ব্যবহার করতে চান better

সি # উদাহরণ:

var worker = new BackgroundWorker { WorkerReportsProgress = true };

রুবি উদাহরণ

validates_presence_of :name, :allow_nil => true

পাইথন উদাহরণ

connect_to_database( persistent=true )

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

Answer 12

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

এই নিয়মটি কেবল স্টাইলের প্রশ্ন, বাগ বা রানটাইম পারফরম্যান্সের সম্ভাবনার নয়। আরও ভাল নিয়ম হ'ল "পাঠযোগ্যতার কারণে বুলিয়ানগুলিতে এনামদের পছন্দ করা"।

নেট ফ্রেমওয়ার্কটি দেখুন। বেশ কয়েকটি পদ্ধতিতে বুলিয়ানগুলি প্যারামিটার হিসাবে ব্যবহৃত হয়। । নেট এপিআই নিখুঁত নয়, তবে আমি মনে করি না যে পরামিতি হিসাবে বুলিয়ান ব্যবহার একটি বড় সমস্যা। টুলটিপটি সর্বদা আপনাকে প্যারামিটারের নাম দেয় এবং আপনি এই ধরণের নির্দেশিকাও তৈরি করতে পারেন - পদ্ধতির পরামিতিগুলিতে আপনার এক্সএমএল মন্তব্যগুলি পূরণ করুন, তারা সরঞ্জামটিপটিতে আসবে।

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

উদাহরণস্বরূপ, যদি আপনার শ্রেণীর মতো বৈশিষ্ট্য থাকে

public bool IsFoo
public bool IsBar

এবং উভয়কে একই সাথে সত্য করে ফেলতে ত্রুটি, আপনি যা পেয়েছেন তা তিনটি বৈধ রাষ্ট্র, এর চেয়ে ভাল কিছু হিসাবে প্রকাশ করা হয়েছে:

enum FooBarType { IsFoo, IsBar, IsNeither };

Answer 13

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

• আপনার ডিজাইনের সাথে মতবিরোধী হবেন না।
• আপনার কোড ব্যবহারকারীদের জন্য সবচেয়ে উপযুক্ত কি চয়ন করুন।
• এই মাসে আকৃতিটি পছন্দ করার কারণে কেবল প্রতিটি গর্তে তারকা-আকৃতির ছাঁটাগুলিকে ঘাটানোর চেষ্টা করবেন না!

Answer 14

একটি বুলিয়ান কেবল তখনই গ্রহণযোগ্য হবে যদি আপনি কাঠামোর কার্যকারিতা বাড়ানোর ইচ্ছা না করেন। এনামকে অগ্রাধিকার দেওয়া হয়েছে কারণ আপনি এনাম বাড়িয়ে দিতে পারেন এবং ফাংশন কলের আগের প্রয়োগগুলি ভঙ্গ করতে পারেন না।

এনুমের অন্য সুবিধাটি হ'ল এটি পড়া সহজ।

Answer 15

পদ্ধতিটি যদি এমন প্রশ্ন জিজ্ঞাসা করে তবে:

KeepWritingData (DataAvailable());

কোথায়

bool DataAvailable()
{
    return true; //data is ALWAYS available!
}

void KeepWritingData (bool keepGoing)
{
   if (keepGoing)
   {
       ...
   }
}

বুলিয়ান পদ্ধতির যুক্তিগুলি একেবারে নিখুঁত অর্থে বোধ হয়।

Comments

কোনও দিন আপনাকে "আপনার যদি ফাঁকা জায়গা থাকে তবে লিখতে থাকুন" যুক্ত করতে হবে এবং তারপরে আপনি যেভাবেই বুল থেকে এনামে যেতে পারবেন।

— ইলিয়া রাইঝেঙ্কভ

এবং তারপরে আপনার ব্রেকিং পরিবর্তন হবে, বা অপ্রচলিত ওভারলোড হবে, বা কেপ রাইটিংডেটাএক্স এর মতো কিছু হতে পারে :)

— Ilya Ryzhenkov

ইলিয়া বা সম্ভবত আপনি না! একটি সম্ভাব্য পরিস্থিতি তৈরি করা যেখানে বর্তমানে কোনটিই উপস্থিত নেই এটি সমাধানটিকে অস্বীকার করে না।

— জেসি সি স্লিকার 21

জেসি ঠিক বলেছেন। এর মতো পরিবর্তনের জন্য পরিকল্পনা করা নির্বোধ। যেটা বোধগম্য হয় তা করুন। এই ক্ষেত্রে, বুলিয়ান স্বজ্ঞাত এবং পরিষ্কার উভয়। c2.com/xp/DoTheSlimlestThingThatCouldPoss संभवWork.html

— ডেরেক পার্ক

@ ডেরেক, এক্ষেত্রে, বুলিয়ান এমনকি প্রয়োজন হয় না, কারণ ডেটাএভলভ্যালি সর্বদা সত্য প্রত্যাবর্তিত হয় :)

— ইলিয়া রাইঝেঙ্কভ

Answer 16

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

CommentService.SetApprovalStatus(commentId, false);

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

Answer 17

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

Comments

তৃতীয় সম্ভাব্য বিকল্প হিসাবে প্রিপেন্ডিং সম্পর্কে কী? ;-))

— ইয়ারিক

Answer 18

এনামগুলি অবশ্যই কোডটিকে আরও পঠনযোগ্য করে তুলতে পারে। নজরদারি করার জন্য এখনও কয়েকটি জিনিস রয়েছে (অন্তত নেট মধ্যে)

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

যদি আপনার এনামগুলি আপনার কোডটিতে ব্যক্তিগত থাকে (কখনই প্রকাশ্যে প্রকাশিত হয় না) তবে আপনি এখানে পড়া বন্ধ করতে পারেন।

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

আমি আইনত লিখতে পারি

WriteMode illegalButWorks = (WriteMode)1000000;
file.Write( data, illegalButWorks );

এটির বিরুদ্ধে লড়াই করতে, কোনও এনাম গ্রহন করে এমন কোনও কোড যা আপনি নিশ্চিত হতে পারবেন না (যেমন পাবলিক এপিআই) এনামটি বৈধ কিনা তা পরীক্ষা করা দরকার। আপনি এটি মাধ্যমে

if (!Enum.IsDefined(typeof(WriteMode), userValue))
    throw new ArgumentException("userValue");

এর একমাত্র সতর্কতা Enum.IsDefinedহ'ল এটি প্রতিবিম্ব ব্যবহার করে এবং ধীরে ধীরে। এটি একটি সংস্করণ সমস্যা ভোগ করে। আপনার যদি প্রায়শই এনাম মানটি পরীক্ষা করতে হয় তবে নীচের থেকে ভাল হতে পারেন:

public static bool CheckWriteModeEnumValue(WriteMode writeMode)
{
  switch( writeMode )
  {
    case WriteMode.Append:
    case WriteMode.OverWrite:
      break;
    default:
      Debug.Assert(false, "The WriteMode '" + writeMode + "' is not valid.");
      return false;
  }
  return true;
}

ভার্সন ইস্যুটি হ'ল পুরানো কোডটি কেবলমাত্র আপনার কাছে থাকা 2 এনামগুলিকে কীভাবে পরিচালনা করতে হবে তা জানতে পারে। যদি আপনি একটি তৃতীয় মান যোগ করেন তবে এনাম.আইএসডিফাইন্ডটি সত্য হবে, তবে পুরানো কোডটি প্রয়োজনীয়ভাবে এটি পরিচালনা করতে পারে না। উপস।

[Flags]এনামগুলির সাথে আপনি আরও মজা করতে পারেন এবং এর জন্য বৈধতা কোডটি কিছুটা আলাদা।

আমি এটাও লক্ষ্য করবেন যে বহনযোগ্যতা, আপনি কল ব্যবহার করা উচিত ToString()enum উপর, এবং ব্যবহার Enum.Parse()যখন তাদের মধ্যে ফিরে পড়া চালিয়ে যান। উভয় ToString()এবং Enum.Parse()সব ব্যবস্থা করতে সক্ষম [Flags]enum হিসাবে ভাল, তাই তাদের ব্যবহার করার জন্য নয় কোনো কারণ। মনে মনে, এটি আরও একটি অসুবিধা, কারণ এখন আপনি সম্ভবত কোড ভঙ্গ ছাড়া এনামের নামও পরিবর্তন করতে পারবেন না।

সুতরাং, কখনও কখনও আপনি যখন নিজেকে জিজ্ঞাসা করেন কেবল তখনই আপনাকে উপরের সমস্তটি ওজন করতে হবে যখন আমি কেবল একটি বুল নিয়ে পালিয়ে যেতে পারি?

Answer 19

আইএমএইচএও দেখে মনে হচ্ছে যে কোনও অবস্থাতেই দু'জনের বেশি বিকল্পের সম্ভাবনা রয়েছে এমন কোনও এনামের স্পষ্ট পছন্দ। তবে অবশ্যই এমন পরিস্থিতি রয়েছে যেখানে আপনার প্রয়োজন বুলিয়ান। সেক্ষেত্রে আমি বলব যে একটি এনাম ব্যবহার করা যেখানে একটি বুল কাজ করবে যখন 4 করবে তখন 7 টি শব্দ ব্যবহার করার উদাহরণ হবে।

Answer 20

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

এতে বলা হয়েছে, আপনি মিথ্যা ও সত্য (বুলিয়ান 0 এবং 1 )ও ব্যবহার করতে পারেন এবং তারপরে যদি আপনার আরও মান প্রয়োজন হয় তবে ব্যবহারকারী-সংজ্ঞায়িত মানগুলিকে সমর্থন করার জন্য ফাংশনটি প্রসারিত করুন (বলুন, 2 এবং 3), এবং আপনার পুরানো 0/1 মানগুলি সুন্দরভাবে পোর্ট করবে, সুতরাং আপনার কোডটি ভাঙা উচিত নয়।

Answer 21

কখনও কখনও ওভারলোডগুলির সাথে বিভিন্ন আচরণের মডেল করা সহজ। আপনার উদাহরণ থেকে চালিয়ে যেতে হবে:

file.appendData( data );  
file.overwriteData( data );

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

এনামগুলি কিছু ক্ষেত্রে কোডকে আরও পঠনযোগ্য করে তুলতে পারে, যদিও কিছু ভাষায় সঠিক এনাম মানকে বৈধতা দেওয়া (উদাহরণস্বরূপ সি #) কঠিন হতে পারে।

প্রায়শই একটি বুলিয়ান প্যারামিটারগুলি নতুন ওভারলোড হিসাবে পরামিতিগুলির তালিকায় যুক্ত হয়। .NET এর একটি উদাহরণ হ'ল:

Enum.Parse(str);  
Enum.Parse(str, true); // ignore case

পরবর্তী ওভারলোড প্রথমটির চেয়ে .NET ফ্রেমওয়ার্কের পরবর্তী সংস্করণে উপলব্ধ হয়ে ওঠে।

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

---

সম্পাদনা

সি # এর নতুন সংস্করণগুলিতে নামযুক্ত আর্গুমেন্টগুলি ব্যবহার করা সম্ভব যা আইএমও, কলকারী কোডকে এমার্মগুলি যেভাবে পারে সেভাবেই পরিষ্কার করতে পারে। উপরের মত একই উদাহরণ ব্যবহার করে:

Enum.Parse(str, ignoreCase: true);

Answer 22

যেখানে আমি সম্মত হই যে এনামগুলি যেভাবে যাওয়ার ভাল উপায়, সেই পদ্ধতিগুলিতে যেখানে আপনার কাছে দুটি বিকল্প রয়েছে (এবং এনাম ছাড়াই আপনার পাঠযোগ্যতা থাকতে পারে মাত্র দুটি বিকল্প))

যেমন

public void writeData(Stream data, boolean is_overwrite)

এনামগুলিকে ভালবাসুন, তবে বুলিয়ানও দরকারী।

Answer 23

এটি একটি পুরানো পোস্টে দেরীতে প্রবেশ, এবং এটি পৃষ্ঠার এতদূর নিচে যে কেউ কখনও এটি পড়বে না, তবে যেহেতু কেউ ইতিমধ্যে এটি বলে নি ....

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

void writeData( DataObject data, bool use_append_mode );

তবে, উদাহরণস্বরূপ, আসুন এটি ঘোষণা হিসাবে বলি। তারপরে, অন্যথায় অব্যক্ত বুলেয়ান আর্গুমেন্টের জন্য আমি ভেরিয়েবলটির নামটি একটি ইনলাইন মন্তব্যে রেখেছি। তুলনা করা

file.writeData( data, true );

সঙ্গে

file.writeData( data, true /* use_append_mode */);

Answer 24

এটি সত্যই যুক্তির সঠিক প্রকৃতির উপর নির্ভর করে। যদি এটি হ্যাঁ / না বা সত্য / মিথ্যা না হয় তবে একটি এনাম এটিকে আরও পঠনযোগ্য করে তোলে। অন্তর্নিহিত ধরণের নির্ধারিত মানগুলি পাস করার কারণে একটি এনামের সাথে আপনার যুক্তিটি পরীক্ষা করা বা গ্রহণযোগ্য ডিফল্ট আচরণ থাকতে হবে।

Answer 25

আপনার উদাহরণে বুলিয়ানগুলির পরিবর্তে এনামগুলির ব্যবহার পদ্ধতি কলটিকে আরও পাঠযোগ্য able তবে এটি সি # তে আমার প্রিয় ইচ্ছার আইটেমের বিকল্প, পদ্ধতি কলগুলিতে যুক্তিযুক্ত নামযুক্ত। এই বাক্য গঠন:

var v = CallMethod(pData = data, pFileMode = WriteMode, pIsDirty = true);

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

সি # 3.0 কনস্ট্রাক্টরগুলিতে নামযুক্ত যুক্তিগুলির অনুমতি দেয়। আমি জানি না কেন তারা পদ্ধতিগুলির সাহায্যে এটি করতে পারে না।

Comments

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

— ড্র নোকস

Answer 26

বুলিয়ানগুলির মান true/ falseকেবল। সুতরাং এটি কী প্রতিনিধিত্ব করে তা পরিষ্কার নয়। Enumঅর্থপূর্ণ নাম, থাকতে পারে যেমন OVERWRITE, APPENDইত্যাদি সুতরাং enums ভাল হয়।