স্যুইচ কেসগুলি ব্যবহার করার সময় কি ডিফল্ট কেস যুক্ত করা দরকার?

Question

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

এই কাজ করার অধিকার জিনিস? এটি কোন উদ্দেশ্যে কাজ করবে?

Comments

এটি আপনার অবধি ... মানে সুপারভাইজারের কোড স্টাইল।

— এসডি

আমি মনে করি এমন অনেকগুলি মামলা রয়েছে যেখানে আপনি ডিফল্ট কেস চান না। একটি এনাম উপর পরিবর্তন বিবেচনা করুন। আপনার স্যুইচ সমস্ত সম্ভাব্য মানের জন্য একটি কেস সংজ্ঞায়িত করে। এখন একটি এনামে একটি মান যুক্ত করার ফলে সেই সুইচে একটি কেস যুক্ত করা উচিত । আপনি যদি এটি না করেন তবে এটি একটি ত্রুটি হতে পারে, যেহেতু আপনি এই নতুন এনাম মানটির জন্য কিছু করতে চান তবে আপনার কোডটি তা করে না। আপনার সংকলক আপনাকে সে সম্পর্কে সতর্ক করতে পারে (আমি মনে করি; জাভা সম্পর্কে নিশ্চিত নই) তবে আপনি যদি কোনও ডিফল্ট কেস না রাখেন তবেই । বিকল্প হিসাবে, আপনি ডিফল্ট ক্ষেত্রে একটি সতর্কতা মুদ্রণ করতে পারে যখন আপনি নিশ্চিত হন যে কোডটি কখনই পৌঁছায় না।

— লীমস

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

— মার্কো

Answer 1

দেখে মনে হচ্ছে তিনটি ক্ষেত্রেই যখন defaultবিবৃতি প্রয়োজন হয় না:

1. মান যে প্রবেশ সীমিত সেট না থাকায়, অন্য কোন ক্ষেত্রে ফেলে রাখা হয় switch case। তবে এটি সময়ের সাথে (ইচ্ছাকৃতভাবে বা দুর্ঘটনাক্রমে) পরিবর্তিত হতে পারে, এবং default caseযদি কিছু পরিবর্তন হয় তবে কিছুটা ভাল হবে _ আপনি লগইন করতে বা কোনও ভুল মান সম্পর্কে ব্যবহারকারীকে সতর্ক করতে পারেন।

2. আপনি কীভাবে এবং কোথায় switch caseব্যবহৃত হবে এবং কোন মানগুলি এতে প্রবেশ করবে তা আপনি জানেন । আবার এটি পরিবর্তিত হতে পারে এবং একটি অতিরিক্ত প্রক্রিয়াজাতকরণের প্রয়োজন হতে পারে।

3. অন্যান্য ক্ষেত্রে কোনও বিশেষ প্রক্রিয়াজাতকরণের প্রয়োজন হয় না। যদি এটি হয় তবে আমি মনে করি আপনাকে একটি যুক্ত করতে বলা হয়েছে default case, কারণ এটি একটি স্বীকৃত কোডিং শৈলী এবং এটি আপনার কোডটিকে আরও পঠনযোগ্য করে তোলে।

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

Comments

1 এবং 2 ক্ষেত্রে, একটি ডিফল্ট ক্ষেত্রে ত্রুটি হওয়া উচিত। যদি আপনার কোডিং স্টাইলটি সর্বদা ডিফল্ট ব্যবহার করে থাকে তবে তা করুন তবে এটি 1 এবং 2 তে ত্রুটি নির্গত করুন Is সম্ভব, এটি সংকলনের সময় নির্গত করা উচিত, তবে জাভাতে থাকলে এটি সর্বদা সম্ভব না not আমি কমপক্ষে মনে করি ব্যবহারকারীর পক্ষে এই বার্তাটি পাওয়া গুরুত্বপূর্ণ যে "আপনি এই মানটি

— পেরিয়ে

একটি ডিফল্ট কেস সর্বদা একটি ভাল ধারণা, কারণ উদাহরণস্বরূপ এনামের ক্ষেত্রে যদি কেউ এনামে একটি নতুন এন্ট্রি যুক্ত করে, আপনার ডিফল্ট কেসটি এমন কিছু করা উচিত throw new IllegalStateException("Unrecognised case "+myEnum)যা আপনাকে কোথায় এবং কী ত্রুটি দেখায়।

— ধনী

এর অর্থ কি আপনি যদি জানেন যে এটি হওয়া উচিত নয়, এমনকি আপনার elseপ্রতিটির পরে সর্বদা একটি ধারা if/else ifথাকা উচিত? আমার কাছে ভাল ধারণা বলে মনে হচ্ছে না ...

— jadkik94

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

— জিভ

Answer 2

এটি কি সঠিক থিওঞ্জ করা উচিত? এটি কোন উদ্দেশ্যে কাজ করবে?

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

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

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

Comments

একটি কি assert?

— ফ্লাই করুন

@ এফএলওয়াই এটি জাভাতে একটি কীওয়ার্ড এবং সাধারণত সি, সি ++ ইত্যাদি ক্ষেত্রে ম্যাক্রো হয় যে কোনও উপায়ে, কিছুটা অনুমান সত্য হয়ে যায় এবং তা ছুঁড়ে ফেলে ব্যতিক্রম বা তা না হলে অন্যথায় কোনও ত্রুটি ঘটায় তা পরীক্ষার জন্য একটি দৃ an়পদ ব্যবহার করা হয়।

— কালেব

আমি উইকিপিডিয়ায় একটি লিঙ্কের সাথে আমার পূর্ববর্তী মন্তব্য সম্পাদনা করেছি

— এফএলওয়াই

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

— rold2007

Answer 3

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

Comments

সমস্যাটি সংকলন-সময়ে এবং ধরার সময় নয় ধরার জন্য +1।

— সিলভাইনড

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

— আর্তুর

আমি এই আচরণ সম্পর্কে জানতাম না। আমার আদর্শ কোড নমুনা আদর্শ one.com / WvytWq অন্যথায় প্রস্তাব দেয়। ধরে নিলে আপনি সত্য বলেছেন, কেউ যদি একটি গণনার প্রকারের সাথে মান যোগ করে তবে আপনি নিজের কোডটি পুনরায় সংকলন না করে কি হয়?

— Emory 5'13

stackoverflow.com/questions/3999942/...

— মধ্যে Artur

স্পষ্টতই, নতুন মানগুলি কেবলমাত্র ডিফল্ট কেস ছাড়াই স্যুইচ বিবৃতি দ্বারা পরিচালিত হয় না। ইন্টারফেস বদলে আপনি যদি প্রয়োগগুলি পুনরায় সংকলন না করেন তবে আপনার বিল্ড সিস্টেমটি সত্যিই নষ্ট হয়ে গেছে।

— আর্তুর

Answer 4

অনেক দিক থেকে, এই প্রশ্নটি প্রায়শই জিজ্ঞাসা করা হয় আমাকে কি / মইয়ের elseশেষে এমন একটি ধারা থাকতে হবে যা প্রতিটি বিকল্পকে কভার করেifelse if ?

উত্তরটি হ'ল সিন্ট্যাক্টিক্যালি বলছি, আপনি করবেন না। তবে একটি আছে ...

একটি defaultধারা সেখানে (কমপক্ষে) দুটি কারণে থাকতে পারে:

1. ত্রুটি হ্যান্ডলার হিসাবে - নিশ্চিত, এখানে কখনও পাওয়া উচিত নয়! এমন একটি দাবি যা করা যায়, তবে তা যদি হয়? ডেটা দুর্নীতি বা আরও খারাপ, কোনও ডেটা বৈধতা সঠিকভাবে আটকে না থাকলে প্রোগ্রাম ব্যর্থতার পথে routes এই ক্ষেত্রে, এটি একটি খালি ধারা হওয়া উচিত নয়!
2. ডিজাইন / কোড কভারেজ - এমনকি একটি ফ্লো-চার্টের সহজতম আকারেও যদি একটি আইফেট-স্টেটমেন্ট থেকে দুটি রুট থাকে এবং সর্বদা otherwiseকেস থেকে থাকে। উত্স কোডে এগুলি অন্তর্ভুক্ত না করার জন্য কোনও কারণ নেই।

আমার দর্শন সর্বদা বেশ সহজ - দুটি বিকল্পের সবচেয়ে খারাপ পরিস্থিতিটি মূল্যায়ন করুন এবং সবচেয়ে নিরাপদ দিকে যান। একটি খালি elseবা defaultধারা হিসাবে, সবচেয়ে খারাপ ক্ষেত্রে বিকল্পগুলি:

• তাদের অন্তর্ভুক্ত করুন: "রিলান্ড্যান্ট" কোডের অতিরিক্ত তিন বা চার লাইন।
• তাদের অন্তর্ভুক্ত করবেন না: অসম্পূর্ণ ডেটা বা অপ্রত্যাশিত পরিস্থিতি আটকা পড়ে না, সম্ভাব্যভাবে প্রোগ্রামের ব্যর্থতার কারণ হয়।

Overdramatic? হতে পারে ... তবে তারপরে আমার সফ্টওয়্যারটি ভুল হয়ে গেলে মানুষ হত্যা করার সম্ভাবনা রয়েছে। আমি বরং এই ঝুঁকি নেব না

---

একদিকে যেমন, মিশ্র-সি নির্দেশিকা - অধিভুক্তির জন্য প্রোফাইল দেখুন defaultevery প্রত্যেকটির জন্য একটি ধারা প্রস্তাবিত করেswitch

Comments

একটি মই শেষে নয়। প্রশ্নটি হল: আমার কি elseপরে একটি দরকার if? কিন্তু আপনি যেমন বলেছিলেন, না, তা নয়।

— অট--

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

— এমরি

ভাল বক্তব্য, @ স্মৃতি - এটি খুব পরিষ্কার ছিল না, এটি ছিল ... সম্পাদিত :)

— অ্যান্ড্রু

Answer 5

জাভা আপনাকে একটি 'ডিফল্ট' বিবৃতি দিতে বাধ্য করে না তবে কোডটি কখনই না পৌঁছানো (এই মুহুর্তে) সর্বাধিক সময় থাকা ভাল অনুশীলন । এখানে কয়েকটি কারণ রয়েছে:

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

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

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

এমনকি যদি আপনি ডিফল্টে কিছু না রাখার সিদ্ধান্ত নেন (কোনও ব্যতিক্রম, লগিং ইত্যাদি নয়) তবে আপনি যে মন্তব্যটি সত্যই ডিফল্ট হিসাবে বিবেচনা করেছেন তা কখনই ঘটবে না তা বলার জন্য একটি মন্তব্য আপনার কোডের পাঠযোগ্যতায় সহায়তা করতে পারে; কিন্তু এটি ব্যক্তিগত পছন্দ নেমে আসে।

Answer 6

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

Answer 7

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

আপনি যদি সত্যই নিশ্চিত হন যে আপনি অন্য কোনও ক্ষেত্রে যত্নবান নন, ডিফল্ট: ব্রেক; // যত্ন নেবেন না তবে ডিফল্ট ডিফল্টটি ডিফল্টের মতো হওয়া উচিত: নতুন ত্রুটি নিক্ষেপ করুন ("অপ্রত্যাশিত মান");

তেমনিভাবে, আপনি যে ড্রপ করতে চান সে সম্পর্কে কোনও মন্তব্য যুক্ত না করে কখনও কখনও কোনও অযৌক্তিক কেসটি "ড্রপ" করা উচিত নয়। জাভা ডিজাইন পর্যায়ে এটি এক ভুল পেয়েছে।

Answer 8

বিবেচনা

enum Gender
{
       MALE ,
       FEMALE ;
}

এবং

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

আমি যুক্তি দিয়ে বলব যে এটি একটি হ্যাঁ মামলা, একটি মহিলা ক্ষেত্রে এবং একটি ব্যতিক্রম ছুঁড়ে একটি ডিফল্ট কেস থাকার চেয়ে শ্রেষ্ঠ।

আপনার পরীক্ষার পর্বের সময়, কম্পিউটারটি চ'টি মহিলা কিনা তা পরীক্ষা করবে। উত্পাদনের সময়, চেকটি বাদ দেওয়া হবে। (হ্যাঁ একটি মাইক্রোপটিমাইজেশন!)

আরও গুরুত্বপূর্ণ, আপনি আপনার 100% কোড কভারেজের লক্ষ্য বজায় রাখবেন। যদি আপনি কোনও ব্যতিক্রম ছুঁড়ে এমন কোনও ডিফল্ট কেস লিখে থাকেন তবে কীভাবে আপনি এটি পরীক্ষা করবেন?

Comments

১. মাইক্রোপটিমালাইজেশনের দরকার নেই - গত ৩০ বছর বা তার বেশি সময় ধরে সংকলকগুলিতে ডেড কোড নির্মূলকরণ ব্যবহৃত হয় এবং এটি জেআইটি দ্বারা নির্মূল করা হবে। ২.০% কোড কভারেজ সাধারণত গুরুত্বপূর্ণ হিসাবে বিবেচিত হয় না (একদিকে ১০০% কভারেজ সমস্ত প্রান্তের কেস ধরতে পারে না, অন্যথায় কোনও পরীক্ষায় সঠিক প্রোগ্রামে assert_not_reched রেখা ধরা পড়বে না)। এই ক্ষেত্রে কোনও ডিফল্ট কেস না রেখে সংকলক ত্রুটির কারণ হতে পারে। অন্যদিকে - আপনি কীভাবে দাবীটি কাজ করে কিনা তা পরীক্ষা করে দেখবেন (আপনি সমস্যাটি সরিয়ে নিয়ে একই লাইনের পরিবর্তে এটি 100% কভারেজের মাধ্যমে আড়াল করবেন 'এটি হবে না, আমি প্রতিশ্রুতি দিই')।

— ম্যাকিয়েজ পাইচোটকা

৩. কখন Gender . FEMALE . equals ( FEMALE ) ;মূল্যায়ন হয় false? আপনি বোঝাতে চেয়েছিলেন Gender.FEMALE.equals (g)তবে যেহেতু আপনি এনামগুলিকে স্থিতিশীল রাখার উপর নির্ভর করতে পারেন আপনি কেবল লিখতে পারেন g == Gender.FEMALE। ৪. (ব্যক্তিগত মতামত) এই জাতীয় কোডটি পড়া খুব কঠিন এবং আরও কিছু বিভ্রান্তিকর ত্রুটি তৈরি করবে।

— ম্যাকিয়েজ পাইচোটকা

@ ম্যাসিজেপিচোটক্কা জি সম্পর্কে ভাল ধারণা। হ্যাঁ, মাইক্রোপটিমাইজেশন হ'ল ননবাইফিট তবে এটি উভয়ই একটি অসুবিধাও নয়। 100% কোড কভারেজ হ'ল একটি সুবিধা যদি এটি আপনার লক্ষ্যগুলির মধ্যে একটি এবং আপনার কোড কভারেজ সরঞ্জাম দৃ as়তা পরীক্ষা করে না (যা এটি করা উচিত নয়)।

— এমরি

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

— ম্যাকিয়েজ পাইচোটকা