সুইচ স্টেটমেন্টগুলিতে সর্বদা একটি ডিফল্ট ধারা থাকতে হবে?

254

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

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

default switch-statement

— tttppp
সূত্র

9

এটি একটি বৃহত্তর ডিগ্রির জন্য ভাষা নির্ভর হতে

— চলেছে

276

স্যুইচ কেসগুলি প্রায় সবসময় একটি defaultকেস থাকা উচিত ।

ব্যবহারের কারণ a default

1. একটি 'অপ্রত্যাশিত মান' ধরতে

switch(type)
{
    case 1:
        //something
    case 2:
        //something else
    default:
        // unknown type! based on the language,
        // there should probably be some error-handling
        // here, maybe an exception
}

২. 'ডিফল্ট' ক্রিয়াগুলি পরিচালনা করতে, যেখানে কেসগুলি বিশেষ আচরণের জন্য।

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

৩. আপনার কোডটি পড়া এমন কাউকে দেখাতে যে আপনি সেই কেসটি আবৃত করেছেন।

variable = (variable == "value") ? 1 : 2;
switch(variable)
{
    case 1:
        // something
    case 2:
        // something else
    default:
        // will NOT execute because of the line preceding the switch.
}

এটি একটি অতি-সরলকরণের উদাহরণ ছিল, তবে মূল বিষয়টি হল যে কোডটি পড়ছেন এমন কেউ ভাবছেন না যে কেন variable1 বা 2 বাদে অন্য কিছু হতে পারে না।

শুধুমাত্র যদি আমি ব্যবহার মনে করতে পারেন defaultহয় যখন সুইচ কিছু যেখানে তার বরং সুস্পষ্ট প্রত্যেক অন্যান্য বিকল্প সুখে উপেক্ষা করা যাবে চেক করা হয়

switch(keystroke)
{
    case 'w':
        // move up
    case 'a':
        // move left
    case 's':
        // move down
    case 'd':
        // move right
    // no default really required here
}

— Vanwaril
সূত্র

25

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

— অ্যান্ড্রু

1

একই সাথে আপনি যদি জিইটি প্যারামিটারটি যাচাই করে নিচ্ছেন তবে আপনি প্রতিবার ব্যবহারকারী ইউআরএলটি বৈধ নয় এমন কোনও কিছুতে পরিবর্তন করে এমন ব্যতিক্রম চান না: [

— অ্যান্ড্রু

4

কম্পিউটার অ্যান্ড্রু WASD কম্পিউটার গেমের চরিত্রের চলাফেরাগুলির জন্য সাধারণ You আপনার অন্য কোনও ক্রিয়াকলাপের প্রয়োজন হবে না কারণ অন্যান্য কীগুলি অন্যান্য মিথস্ক্রিয়ায় নির্ধারিত হতে পারে। এই ধরণের স্যুইচে, চলাফেরার ফাংশনগুলিকে কল করা ভাল।

— জিমিলোই

13

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

— rdb

3

@ ভাইরাসোকস যদি আপনার শর্তটি এনাম হয় তবে আপনার এখনও অপ্রত্যাশিত মান থাকতে পারে। উদাহরণস্বরূপ, যদি আপনি এনামে একটি নতুন মান যুক্ত করেন, এবং একটি স্যুইচ আপডেট করতে ভুলে যান। এছাড়াও, কিছু ভাষায় আপনি এনামগুলিতে পূর্ণসংখ্যার মান নির্ধারণ করতে পারেন। সি ++ এ enum MyEnum { FOO = 0, BAR = 1 }; MyEnum value = (MyEnum)2;একটি বৈধ MyEnumউদাহরণ তৈরি করে যা এর সমান FOOবা সমান নয় BAR। যদি এই সমস্যাগুলির যে কোনও একটি যদি আপনার প্রকল্পে ত্রুটি সৃষ্টি করে, একটি ডিফল্ট কেস আপনাকে ত্রুটিটি খুব দ্রুত খুঁজে পেতে সহায়তা করে, প্রায়শই কোনও ডিবাগারের প্রয়োজন হয় না!

— সিডগ্রাহাম

54

না।

কোনও ডিফল্ট ক্রিয়া না থাকলে কী হবে, প্রসঙ্গের বিষয়টি গুরুত্বপূর্ণ। আপনি যদি কেবলমাত্র কয়েকটি মূল্যবোধ অনুযায়ী কাজ করতে যত্নবান হন?

একটি গেমের জন্য কীপ্রেসগুলি পড়ার উদাহরণ নিন

switch(a)
{
   case 'w':
     // Move Up
     break;
   case 's':
     // Move Down
     break;
   case 'a':
     // Move Left
     break;
   case 'd':
     // Move Right
     break;
}

যোগ করার পদ্ধতি:

default: // Do nothing

এটি কেবল সময়ের অপচয় এবং বিনা কারণে কোডের জটিলতা বৃদ্ধি করে।

— জারেড কেলস
সূত্র

14

ভালো উদাহরণ. তবে প্রকৃতপক্ষে, একটি সাধারণ // do nothingমন্তব্যের সাথে একটি ডিফল্ট ধারা যুক্ত করা এটি পরিষ্কার করে দেয় যে সমস্ত মামলা areাকা না থাকলে এটি 'ঠিক আছে', যেখানে অন্যান্য সুইচ বিবৃতিগুলির বিপরীতে যেখানে এটি 'ঠিক আছে না'।

— পেরেক

8

না। কোডিং কেবল কয়েকটি কেস পরিচালনা করার জন্য নয়। এছাড়াও এটি একটি নথি হিসাবে কাজ করে। ডিফল্ট লিখে: এবং // মত কিছু মন্তব্য বা অন্য কিছু না করে কোডের পাঠযোগ্যতা আরও ভাল হয়।

— জংআম পার্ক

22

অন্যান্য মন্তব্যের সাথে একমত নন। ডিফল্ট যুক্ত করা // কোন কোড কীভাবে কাজ করে তা আপনি যদি না জানেন তবে কিছুই করবেন না nothing আমি ডিফল্ট ছাড়াই একটি স্যুইচ স্টেটমেন্টটি দেখতে পারি এবং জানতে পারি যে ডিফল্টটি কিছুই করতে পারে না। বিশৃঙ্খলা যুক্ত করা এটিকে আরও সুস্পষ্ট করে না।

— রবার্ট নোক

যথাযথভাবে। এটি একটি পোস্ট প্যারাম হস্তান্তর একই ধারণা। আপনি অন্যদের নয় এমন বিষয়গুলি পরিচালনা করেন।

— জিমি কানে

2

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

— রবার্ট নোক

45

ডিফল্ট কেস না পাওয়া আসলে কিছু পরিস্থিতিতে উপকারী হতে পারে।

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

enum SomeEnum
{
    ENUM_1,
    ENUM_2,
    // More ENUM values may be added in future
};

int foo(SomeEnum value)
{
    switch (value)
    {
    case ENUM_1:
        return 1;
    case ENUM_2:
        return 2;
    }
    // handle invalid values here
    return 0;
 }

— হারলান ক্যাসলার
সূত্র

এটি একটি গুরুত্বপূর্ণ পর্যবেক্ষণ! এটি জাভাতে আরও বেশি প্রযোজ্য কারণ এটি আপনাকে এনামগুলিতে কাস্ট কাস্ট করার অনুমতি দেয় না।

— Lii

2

আপনার উদাহরণে আপনি স্যুইচ-স্টেটমেন্টের পরে ফিরে আসার পরিবর্তে একটি ব্যতিক্রম ছুঁড়ে ফেলতে পারেন। এইভাবে আপনার সংকলক দ্বারা স্থির চেক উভয় থাকতে পারে এবং অপ্রত্যাশিত কিছু ঘটলে একটি পরিষ্কার ত্রুটি পেতে পারেন।

— Lii

1

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

— অ্যান্ডি

1

একটি ত্রুটি ঠিক করা হয়েছে, এটি কোনও পূর্বনির্ধারিত না হলে কমপাইলার থেকে একটি সতর্কবার্তা তৈরি করেছিল: সুতরাং সাধারণত একটি সুইচ ওভার এনাম ভেরিয়েবালের কোনও ডিফল্ট না থাকা উচিত।

— নোটান

42

আপনি যে ভাষায় কাজ করছেন তা বিবেচনা না করেই আমি সর্বদা একটি ডিফল্ট ধারা ব্যবহার করতাম।

জিনিসগুলি ভুল হতে পারে। মানগুলি আপনার প্রত্যাশা মতো হবে না, ইত্যাদি।

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

এ কারণেই আপনার সর্বদা একটি ডিফল্ট ধারা ব্যবহার করা উচিত এবং ত্রুটি নিক্ষেপ করা উচিত, উদাহরণস্বরূপ জাভাতে:

switch (myVar) {
   case 1: ......; break;
   case 2: ......; break;
   default: throw new RuntimeException("unreachable");
}

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

— অ্যাড্রিয়ান স্মিথ
সূত্র

39

আমি পছন্দ করবো throw new RuntimeException("myVar invalid " + myVar);যেহেতু এটি আপনাকে কোনও ডিবাগার ব্যবহার না করে এবং ভেরিয়েবলগুলি পরীক্ষা না করে বাগটি ঠিক করার জন্য যথেষ্ট পরিমাণে তথ্য দিতে পারে, যা যদি খুব কমই ঘটে থাকে তবে এটি পুনরুত্পাদন করা শক্ত।

— ক্রিস ডড

1

যদি মানটির কোনওটির সাথে একটির মান না মিলে এটির ত্রুটি শর্ত না হয় তবে কী হবে?

— গাবে

4

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

— অ্যাড্রিয়ান স্মিথ

2

আমি অ্যাড্রিয়ান এর সাথে একমত হার্ড ব্যর্থ এবং তাড়াতাড়ি ব্যর্থ।

— স্লিপি

আমি AssertionErrorপরিবর্তে একটি নিক্ষেপ করতে পছন্দ করি RuntimeException, কারণ এই পরিস্থিতি myVarহ্যান্ডলড মানগুলির মধ্যে একটি বলে যে দৃ as়তার সাথে অনুরূপ । এছাড়াও যে কেউ ত্রুটিটি ধরেছে এবং গিলেছে তার সম্ভাবনাও কম।

— ফিলিপ উইন্ডার

15

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

এটি আলোচনা করা যেতে পারে যে একটি ডিফল্ট কেস সবসময় প্রয়োজন হয় না, তবে সর্বদা এটির প্রয়োজনের পরে এটি সহজেই আমাদের কোড বিশ্লেষকরা দ্বারা পরীক্ষা করা হয়।

— কার্ট প্যাটিন
সূত্র

1

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

— ওস্টারওয়াল

12

একটি "স্যুইচ" বিবৃতিতে সর্বদা একটি ডিফল্ট ধারা অন্তর্ভুক্ত করা উচিত? এটি সাধারণত একটি ডিফল্ট অন্তর্ভুক্ত করা উচিত ।

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

এখানে এটি একটি তুচ্ছ উদাহরণ যেখানে এটি কোনও অর্থ দেয় না:

void PrintSign(int i)
{
    switch (Math.Sign(i))
    {
    case 1:
        Console.Write("positive ");
        break;
    case -1:
        Console.Write("negative ");
        break;
    default: // useless
    }
    Console.Write("integer");
}

এটি সমান:

void PrintSign(int i)
{
    int sgn = Math.Sign(i);
    if (sgn == 1)
        Console.Write("positive ");
    else if (sgn == -1)
        Console.Write("negative ");
    else // also useless
    {
    }
    Console.Write("integer");
}

— গেব
সূত্র

আমি একমত নই আইএমএইচও, কেবলমাত্র যদি কেবলমাত্র এখনই এবং সর্বকালের জন্য কোনও উপায় না থাকে তবে কোনও ডিফল্ট অস্তিত্ব থাকা উচিত নয়, যা ইনপুটগুলির সেটটি পরিবর্তন করতে পারে এবং আপনি প্রতিটি সম্ভাব্য মান coveredেকে রেখেছেন। সবচেয়ে সহজ কেসটি আমি ভাবতে পারি একটি ডাটাবেস থেকে বুলিয়ান মান, যেখানে একমাত্র উত্তর (এসকিউএল পরিবর্তন না হওয়া পর্যন্ত) সত্য, মিথ্যা এবং নাল হয় UL অন্য যে কোনও ক্ষেত্রে, "উচিত হবে না!" এর দৃ or়তা বা ব্যতিক্রমের সাথে একটি ডিফল্ট থাকা! ভাল জ্ঞান তোলে। যদি আপনার কোড পরিবর্তিত হয় এবং আপনার এক বা একাধিক নতুন মান থাকে তবে আপনি সেগুলির জন্য আপনার কোডটি নিশ্চিত করতে পারেন এবং যদি না করেন তবে আপনার পরীক্ষাগুলি ফুরিয়ে যাবে।

— হার্পার শেল্বি

4

@ হার্পার: আপনার উদাহরণটি "একটি ত্রুটির শর্ত চাপান" বিভাগের অধীনে আসে।

— গাবে

আমি দৃ as়ভাবে বলছি যে আমার উদাহরণটি আদর্শ, এবং যে সংখ্যার ক্ষেত্রে প্রতিটি সম্ভাব্য কেস আচ্ছাদিত এবং একটি ডিফল্ট প্রয়োজন হয় না এমন সংখ্যক ক্ষেত্রেই এটির ব্যতিক্রম হ'ল ব্যতিক্রম। আপনার উত্তরটি এমনভাবে বানানো হয়েছে যা এটিকে শব্দ করে তোলে (কমপক্ষে আমার কাছে) যেন কোনও কিছুই ডিফল্ট না হয়ে থাকে often

— হার্পার শেলবি

@ হার্পার: ঠিক আছে, করণীয় পরিস্থিতি কম সাধারণ নয় তা বোঝাতে আমি শব্দ পরিবর্তন করেছি changed

— গাবে

4

আমি মনে করি একটি default:ক্ষেত্রে সেগুলি আপনার অনুমানের কোডিং করে। উদাহরণস্বরূপ, কখন এটি sgn==0মুদ্রণ করা ঠিক আছে integer(ইতিবাচক বা নেতিবাচক নয়), বা এটি একটি ত্রুটি? আমার কাছে সেই কোডটি পড়ার জন্য, এটি বলা মুশকিল। আমি ধরে নিই যে আপনি সে zeroক্ষেত্রে লিখতে চান না integer, এবং প্রোগ্রামার এমন ধারণা তৈরি করেছিলেন যা sgnকেবল -1 বা +1 হতে পারে। যদি এটি হয় তবে default:প্রোগ্রামটি থাকার ফলে প্রোগ্রামারটি অনুমানের ত্রুটিটি প্রাথমিকভাবে ধরতে এবং কোডটি পরিবর্তন করার অনুমতি দেয়।

— অ্যাড্রিয়ান স্মিথ

7

যতদূর আমি দেখতে পাই উত্তরটি 'ডিফল্ট' হ'ল ,চ্ছিক, একটি স্যুইচটিতে সর্বদা একটি ডিফল্ট থাকা আবশ্যক বলে প্রতিটা 'if-elseif' অবশ্যই একটি 'অন্য' থাকা উচিত। যদি ডিফল্টরূপে কাজ করার কোনও যুক্তি থাকে তবে 'ডিফল্ট' বিবৃতিটি সেখানে থাকা উচিত, তবে অন্যথায় কোডটি কিছু না করেই কার্যকর করা চালিয়ে যেতে পারে।

— গের্শন হারকিজেগ
সূত্র

6

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

সুতরাং আমি বিশ্বাস করি যে যদি ডিফল্ট না পৌঁছানো না হয় - আপনাকে এটি যুক্ত করতে হবে না।

নোট করুন যে "পৌঁছানো উচিত নয়" এর অর্থ হ'ল এটি যদি পৌঁছে যায় তবে এটি সফ্টওয়্যারটিতে একটি ত্রুটিযুক্ত - আপনাকে ব্যবহারকারী ইনপুট ইত্যাদির কারণে অযাচিত মান থাকতে পারে এমন মানগুলি পরীক্ষা করতে হবে etc.

— ওফির ইওকতান
সূত্র

3

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

— হেন্ডরিক ব্রুমারম্যান

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

— কুর্ট প্যাটিয়েন

5

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

— ক্রিস ডড
সূত্র

5

"প্রতিটি সম্ভাব্য মান" এনামগুলির সাথে পরিচালিত হওয়ার সম্ভাবনা কম। নির্দিষ্ট মানটি স্পষ্টভাবে সংজ্ঞায়িত না করা সত্ত্বেও আপনি একটি এনামের সাথে একটি পূর্ণসংখ্যা কাস্ট করতে পারেন। এবং কোন সংকলক নিখোঁজ মামলা সম্পর্কে সতর্ক করে?

— ট্রুউইল

1

@ ট্রুইউইল: হ্যাঁ, আপনি অবর্ণনীয় কোড লিখতে সুস্পষ্ট কাস্ট ব্যবহার করতে পারেন যা বোঝা অসম্ভব; বোধগম্য কোড লিখতে, আপনার এড়ানো উচিত। gcc -Wall(উপযুক্ত সংকলকগুলির সর্বনিম্ন সাধারণ ডিনোমিনেটর বাছাই করা) স্যুইচ স্টেটমেন্টগুলিতে নিখরচায় এনামগুলি সম্পর্কে সতর্কতা দেয়।

— ক্রিস ডড

4

আপনি যদি জানেন যে স্যুইচ স্টেটমেন্টটিতে কেবল কখনও লেবেল বা মানগুলির একটি কঠোর সংজ্ঞায়িত সেট থাকবে, কেবল ঘাঁটিগুলি আবরণ করার জন্য এটি করুন, আপনি সর্বদা কার্যকর ফলাফল পাবেন .. কেবলমাত্র লেবেলের উপরে ডিফল্ট রেখে দিন যা প্রোগ্রামিকভাবে / যৌক্তিকভাবে হবে অন্যান্য মানের জন্য সেরা হ্যান্ডলার হতে।

switch(ResponseValue)
{
    default:
    case No:
        return false;
    case Yes;
        return true;
}

— deegee
সূত্র

কোলন defaultএখনও এখানে প্রয়োজন পরে ? বা এটি করা কি এমন কোনও বিশেষ সিনট্যাক্সের অনুমতি দেয় যা আপনাকে এটিকে বাদ দিতে পারে?

— পোনকডুডল

কোলনটি প্রয়োজনীয়, এটি একটি টাইপো ছিল, এটি আমার নজরে আনার জন্য আপনাকে ধন্যবাদ।

— ডিজেজি

3

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

private static void switch1(String name) {
    switch (name) {
    case "Monday":
        System.out.println("Monday");
        break;
    case "Tuesday":
        System.out.println("Tuesday");
        break;
    }
}

তবে নিম্নলিখিত পদ্ধতিতে যা একটি স্ট্রিং ফেরত প্রত্যাশা করে, সংকলন ত্রুটিগুলি এড়াতে ডিফল্ট কেসটি কার্যকর হয়

    private static String switch2(String name) {
    switch (name) {
    case "Monday":
        System.out.println("Monday");
        return name;

    case "Tuesday":
        System.out.println("Tuesday");
        return name;

    default:
        return name;
    }
}

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

— শিব কুমার
সূত্র

3

কিছু (পুরানো) দিকনির্দেশনা যেমন মাইস্রা সি'র মত বলে :

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

সেই পরামর্শটি পুরানো কারণ এটি বর্তমানে প্রাসঙ্গিক মানদণ্ডের ভিত্তিতে নয়। হার্লান ক্যাসলার যা বলেছিলেন তা স্পষ্টতই বাদ দিয়েছে:

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

হার্লান যেমন দেখিয়েছে, একটি ডিফল্ট মামলার কার্যক্ষম সমতুল্য স্যুইচ পরে পুনরায় তৈরি করা যেতে পারে। যা প্রতিটি মামলার প্রথম দিকে ফিরে আসে তা তুচ্ছ।

ডায়নামিক চেকের সাধারণ প্রয়োজন হ'ল বিস্তৃত অর্থে ইনপুট হ্যান্ডলিং। প্রোগ্রামটির নিয়ন্ত্রণের বাইরে থেকে যদি কোনও মান আসে তবে এটি বিশ্বাস করা যায় না।

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

— user2394284
সূত্র

2

অপ্রত্যাশিত মানগুলি আসার জন্য আপনার ডিফল্ট হওয়া উচিত।

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

ঘটনাচক্রে আপনি কতবার সম্পূর্ণ অর্থহীন বিএসওড পেয়েছেন? বা মারাত্মক ব্যতিক্রম @ 0x352FBB3C32342?

— জন হান্ট
সূত্র

উদাহরণস্বরূপ - মনে রাখবেন এটি কেবল বিকাশকারীই নয় যা সর্বদা ত্রুটির বার্তা দেখে। আমরা বাস্তব বিশ্বে বাস করি, মানুষ ভুল করে।

— জন হান্ট

2

যদি স্যুইচ মান ( স্যুইচ (ভেরিয়েবল )) ডিফল্ট ক্ষেত্রে পৌঁছতে না পারে তবে ডিফল্ট কেসটি মোটেই প্রয়োজন হয় না। এমনকি যদি আমরা ডিফল্ট কেসটি রাখি তবে এটি কার্যকর হয় না। এটি ডেড কোড।

— shiju
সূত্র

2

এটি একটি alচ্ছিক কোডিং 'কনভেনশন'। ব্যবহারের উপর নির্ভর করে এটি প্রয়োজন হয় কিনা। আমি ব্যক্তিগতভাবে বিশ্বাস করি যে আপনার যদি এটির প্রয়োজন না হয় তবে এটি থাকা উচিত নয়। এমন কিছু কেন অন্তর্ভুক্ত করবেন যা ব্যবহারকারীর দ্বারা ব্যবহৃত হবে না বা পৌঁছবে না?

যদি কেস সম্ভাবনাগুলি সীমিত হয় (অর্থাত্ একটি বুলিয়ান) তবে ডিফল্ট ধারাটি অপ্রয়োজনীয় !

— ড্যানি মাহুনি
সূত্র

2

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

switch ( x ){
  case 0 : { - - - -}
  case 1 : { - - - -}
}

/* What happens if case 2 arises and there is a pointer
* initialization to be made in the cases . In such a case ,
* we can end up with a NULL dereference */

এই ধরণের অনুশীলনের ফলস্বরূপ NULL dereferences , মেমরি ফাঁস হওয়ার পাশাপাশি অন্যান্য ধরণের গুরুতর বাগের মতো একটি বাগও হতে পারে ।

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

— ট্রেভর
সূত্র

2

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

— iOkay
সূত্র

1

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

— গ্যাব্রিয়েল Ščerbák
সূত্র

1

উপরের ভানওয়ারিলের সর্বাধিক ভোট দেওয়া উত্তরের সাথে আমি একমত নই।

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

অযৌক্তিক স্যুইচ স্টেটমেন্ট: এগুলির সর্বদা একটি ডিফল্ট মান হওয়া উচিত । নামটি সূচিত করে যেগুলি হ'ল বিবৃতি যা সমস্ত সম্ভাব্য মানকে আবরণ করে না। এটি সম্ভবত সম্ভব নাও হতে পারে, যেমন কোনও পূর্ণসংখ্যার মান বা স্ট্রিংয়ের উপর একটি স্যুইচ স্টেটমেন্ট। এখানে আমি ভানওয়ারিলের উদাহরণটি ব্যবহার করতে চাই (এটি উল্লেখ করা উচিত যে আমি মনে করি যে তিনি এই উদাহরণটি একটি ভুল পরামর্শ দেওয়ার জন্য ব্যবহার করেছিলেন। আমি এটি এখানে বিপরীত বিবরণী হিসাবে ব্যবহার করতে চাই -> একটি ডিফল্ট বিবৃতি ব্যবহার করুন):
```
switch(keystroke)
{
  case 'w':
    // move up
  case 'a':
    // move left
  case 's':
    // move down
  case 'd':
    // move right
  default:          
    // cover all other values of the non-exhaustive switch statement
}
```
প্লেয়ার অন্য কোনও কী টিপতে পারে। তারপরে আমরা কিছু করতে পারি না (এটি কেবলমাত্র ডিফল্ট ক্ষেত্রে একটি মন্তব্য যুক্ত করে কোডে প্রদর্শিত হতে পারে) বা এটি উদাহরণস্বরূপ স্ক্রিনে কিছু মুদ্রণ করা উচিত। এই ঘটনাটি প্রাসঙ্গিক হিসাবে এটি ঘটতে পারে।
এক্সহসিউভেটিভ স্যুইচ স্টেটমেন্টস: এই স্যুইচ স্টেটমেন্টগুলি সমস্ত সম্ভাব্য মানগুলিকে .েকে রাখে, যেমন গ্রেড সিস্টেমের ধরণের একটি গণনার উপর একটি স্যুইচ স্টেটমেন্ট। কোডটি প্রথমবার বিকাশ করার সময় সমস্ত মানকে আচ্ছাদন করা সহজ। যাইহোক, আমরা মানুষ হিসাবে কিছু ভুলে যাওয়ার একটি ছোট সুযোগ আছে। অতিরিক্ত হিসাবে আপনি যদি পরে কোনও এনাম মান যুক্ত করেন যে সমস্ত স্যুইচ বিবৃতিগুলিকে আবার পরিপূর্ণ করে তুলতে অভিযোজিত হতে হবে ত্রুটি জাহান্নামের পথ উন্মুক্ত করে। সহজ সমাধানটি একটি স্ট্যাটিক কোড বিশ্লেষণ সরঞ্জাম tool সরঞ্জামটির সমস্ত স্যুইচ স্টেটমেন্টগুলি চেক করা উচিত এবং সেগুলি সম্পূর্ণরূপে রয়েছে কিনা তা পরীক্ষা করা উচিত বা তাদের কোনও ডিফল্ট মান আছে কিনা। একটি বিস্তৃত সুইচ বিবৃতি জন্য এখানে একটি উদাহরণ। প্রথমে আমাদের একটি এনাম প্রয়োজন:
```
public enum GradeSystemType {System1To6, SystemAToD, System0To100}
```
তারপরে আমাদের এই এনামের মতো একটি ভেরিয়েবলের দরকার GradeSystemType type = ...। একটি বিস্তৃত সুইচ বিবৃতিটি তখন এর মতো দেখতে পাবেন:
```
switch(type)
{
  case GradeSystemType.System1To6:
    // do something
  case GradeSystemType.SystemAToD:
    // do something
  case GradeSystemType.System0To100:
    // do something
}
```
সুতরাং যদি আমরা GradeSystemTypeউদাহরণস্বরূপ প্রসারিত করি System1To3তবে স্ট্যাটিক কোড বিশ্লেষণ সরঞ্জামটি সনাক্ত করতে হবে যে কোনও ডিফল্ট ধারা নেই এবং স্যুইচ বিবৃতিটি সম্পূর্ণ নয় তাই আমরা সংরক্ষণ করছি।

মাত্র একটি অতিরিক্ত জিনিস। আমরা যদি সর্বদা একটি defaultধারা ব্যবহার করি তবে এটি ঘটতে পারে যে স্ট্যাটিক কোড বিশ্লেষণ সরঞ্জাম সর্বদা ক্লজটি সনাক্ত করে বলে সম্পূর্ণ বা অ-বহনযোগ্য স্যুইচ স্টেটমেন্টগুলি সনাক্ত করতে সক্ষম নয় default। এটি অত্যন্ত খারাপ কারণ আমরা যদি অন্য মান দিয়ে এনাম বাড়িয়ে দিই এবং এটি একটি সুইচ স্টেটমেন্টে যুক্ত করতে ভুলে যাই তবে আমাদের জানানো হবে না।

— ছাই
সূত্র

0

সুইচ স্টেটমেন্টগুলিতে সর্বদা একটি ডিফল্ট ধারা থাকতে হবে? ডিফল্ট কেসের সাথে কোনও স্যুইচ কেস বিদ্যমান থাকতে পারে না, স্যুইচ ক্ষেত্রে ডিফল্ট কেস switch(x)এই ক্ষেত্রে x এর স্যুইচ মানকে ট্রিগার করে x যখন অন্য কোনও ক্ষেত্রে মানের সাথে মেলে না।

— নিসাল এদু
সূত্র

0

আমি বিশ্বাস করি এটি বেশ ভাষা নির্দিষ্ট এবং সি ++ ক্ষেত্রে এনাম শ্রেণির ধরণের জন্য একটি ছোটখাটো পয়েন্ট । যা traditionalতিহ্যবাহী সি এনামের চেয়ে বেশি নিরাপদ প্রদর্শিত হয়। কিন্তু

আপনি যদি স্টাডেন্ট :: বাইট এর বাস্তবায়নের দিকে লক্ষ্য করেন তবে এর মতো কিছু:

enum class byte : unsigned char {} ;

সূত্র: https://en.cppreferences.com/w/cpp/language/enum

এবং এটি বিবেচনা করুন:

অন্যথায়, যদি টি একটি অঙ্কের টাইপ হয় যা হয় নির্ধারিত অন্তর্নিহিত প্রকারের সাথে স্কোপড বা আনস্কোপ করা থাকে, এবং যদি ব্রেসড-ডিআইএন-তালিকার কেবলমাত্র একটি ইনিশিয়ালাইজার থাকে, এবং যদি আরম্ভকারী থেকে অন্তর্নিহিত প্রকারে রূপান্তর হয় না, এবং যদি ইনিশিয়ালাইজেশন হ'ল ডাইরেক্ট-লিস্ট-ইনিশিয়ালাইজেশন, তারপরে ইনিশিয়েশনটি ইনিশিয়ালাইজারকে এর অন্তর্নিহিত ধরণের রূপান্তরিত করার ফলাফলের সাথে আরম্ভ করা হয়।

(যেহেতু সি ++ 17)

সূত্র: https://en.cppreferences.com/w/cpp/language/list_initialization

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

তবে, @ হারলান ক্যাসলার তাঁর পোস্টে যা বলেছেন তা আমি সত্যিই পছন্দ করি এবং কিছু পরিস্থিতিতে নিজেই সেই কৌশলটি ব্যবহার শুরু করব।

অনিরাপদ এনাম শ্রেণীর কেবল উদাহরণ:

enum class Numbers : unsigned
{
    One = 1u,
    Two = 2u
};

int main()
{
    Numbers zero{ 0u };
    return 0;
}

— ডেভিড লেজার
সূত্র