যদি অন্য কোনও ধারা দিয়ে তৈরি করে ... তবে যদি সমাপ্তির সুবিধা কী?

Question

আমাদের সংস্থার একটি প্রয়োজনীয় কোডিং বিধি রয়েছে (কোনও ব্যাখ্যা ছাড়াই) যা:

যদি ... অন্য কোনও ধারা দিয়ে যদি নির্মাণগুলি শেষ করা উচিত

উদাহরণ 1:

if ( x < 0 )
{
   x = 0;
} /* else not needed */

উদাহরণ 2:

if ( x < 0 )
{
    x = 0;
}
else if ( y < 0 )
{
    x = 3;
}
else    /* this else clause is required, even if the */
{       /* programmer expects this will never be reached */
        /* no change in value of x */
}

এটি কোন এজ কেসটি হ্যান্ডেল করার জন্য ডিজাইন করা হয়েছে?

কারণ সম্পর্কে আমাকে যা উদ্বেগ করে তা হ'ল উদাহরণ 1 এর কোনও প্রয়োজন হয় না elseতবে উদাহরণ 2 এর প্রয়োজন হয়। কারণটি যদি পুনরায় ব্যবহারযোগ্যতা এবং এক্সটেনসিবিলিটি হয় তবে আমি মনে করি elseউভয় ক্ষেত্রেই ব্যবহার করা উচিত।

Comments

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

— থিলো

উদাহরণস্বরূপ 2 যেখানে একটি assert(false, "should never go here")ধারণা তৈরি করতে পারে তার জন্য এটি একটি উত্তম উদাহরণ

— থাইলো

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

— LuvnJesus

আপনি যদি সর্বদা সাথে পরাজিত করতে পারে if (x < 0) { x = 0; } else { if (y < 0) { x = 3; }}। অথবা আপনি কেবল এই জাতীয় বিধিগুলি অনুসরণ করতে পারেন, যার মধ্যে অনেকগুলি বোকা, কেবল কারণ আপনার প্রয়োজন।

— জিম বাল্টার

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

— লুডুভিজক

Answer 1

অন্য উত্তরে যেমন উল্লেখ করা হয়েছে, এটি মিস্রা-সি কোডিং গাইডলাইন থেকে। উদ্দেশ্য রক্ষণাত্মক প্রোগ্রামিং, একটি ধারণা যা প্রায়শই মিশন-সমালোচনামূলক প্রোগ্রামিংয়ে ব্যবহৃত হয়।

যে, প্রতিটি if - else ifএকটি সঙ্গে শেষ করা আবশ্যক else, এবং প্রত্যেকের switchঅবশ্যই একটি দিয়ে শেষ হবে default।

এই জন্য দুটি কারণ আছে:

• স্ব-ডকুমেন্টিং কোড। আপনি একটি লেখেন, তাহলে elseকিন্তু এটি খালি রাখুন এটা মানে: "আমি স্পষ্টভাবে দৃশ্যকল্প যখন তন্ন তন্ন বিবেচনা করেছেন ifকিংবা else ifসত্য"।

  একটি লিখছেন না elseসেখানে অর্থ: "হয় আমি দৃশ্যকল্প যেখানে তন্ন তন্ন বিবেচিত ifনা else ifসত্য, অথবা আমি সম্পূর্ণরূপে এটা বিবেচনা করতে ভুলে গেছি এবং সেখানে সম্ভাব্য একটি চর্বি বাগ আমার কোড সঠিক এখানে"।

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

  if (mybool == TRUE) 
  {
  } 
  else if (mybool == FALSE) 
  {
  }
  else
  {
    // handle error
  }

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

  Orতিহাসিকভাবে, আপনি EMI / গোলমালের কারণে র‌্যাম মেমরির দুর্নীতির ভয় পাবেন। এটি আজ একটি ইস্যু খুব বেশি নয়। আরও সম্ভবত, কোডের অন্য কোনও বাগের কারণে মেমোরি দুর্নীতি দেখা দেয়: ভুল অবস্থানের দিকে নির্দেশক, অ্যারে-আউট-অফ-সীমা বাগ, স্ট্যাক ওভারফ্লো, রানওয়ে কোড ইত্যাদি of

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

---

সম্পাদনা

কেন elseপ্রতিটি একক পরে প্রয়োজন হয় না if:

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

এছাড়াও আপনি কোডের সম্পূর্ণরূপে বিশৃঙ্খলা করবে যদি আপনি elseপ্রতিটি এবং পরে একটি খালি লিখে থাকেন if।

MISRA-C: 2012 15.7 কেন elseপ্রয়োজন হয় না তার কোনও যুক্তি দেয় না , এটি কেবলমাত্র বলেছে:

দ্রষ্টব্য: elseসাধারণ if বিবৃতি দেওয়ার জন্য একটি চূড়ান্ত বিবৃতি প্রয়োজন হয় না ।

Comments

যদি মেমরিটি দূষিত হয় তবে আমি চেকিং কোড নিজেই সহ কেবলমাত্র মাইবুলের চেয়ে অনেক বেশি নষ্ট হওয়ার প্রত্যাশা করব। আপনি কেন অন্য ব্লক যুক্ত করবেন না যা যা if/else if/elseযা প্রত্যাশা করে তা আপনার সংকলিত যাচাই করে ? এবং তারপরে আরও একবার যাচাই করার জন্য আরও আছে?

— ওলেগ ভি। ভোলকভ

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

— লন্ডিন

@ ডেডুপ্লিকেটর (প্রকৃতপক্ষে myboolসি-এর নিজস্ব হওয়ার আগে যেমন একটি নন-বুলিয়ান ধরণ boolনা থাকে ; তারপরে সংকলক অতিরিক্ত স্ট্যাটিক বিশ্লেষণ ছাড়া ধারণাটি গ্রহণ করবে না)। এবং "আপনি যদি অন্য কোনও লেখেন তবে ফাঁকা রেখে দেন" এর অর্থটির অর্থ: "আমি অবশ্যই দৃশ্যের বিষয়টি বিবেচনা করেছি যখন না হয় অন্যথায় যদি সত্য হয় না"। ": আমার প্রথম প্রতিক্রিয়াটি প্রোগ্রামার কোডটি রাখতে ভুলে গিয়েছিল অন্যটি ব্লক, অন্যথায় কেন একটি খালি অন্য ব্লক এখানে বসে আছে? একটি // unusedমন্তব্য উপযুক্ত হবে, কেবল একটি খালি ব্লক নয়।

— জাব

@ জ্যাব হ্যাঁ, elseকোনও কোড না থাকলে ব্লকে কিছু ধরণের মন্তব্য থাকতে হবে। খালি জন্য সাধারণ চর্চা elseএকটি একক সেমিকোলন প্লাস একটি মন্তব্য: else { ; // doesn't matter }। যেহেতু কোনও কারণ নেই যে অন্যথায় কেবল তার নিজস্ব লাইনে একটি ইন্টেন্টেড, একক আধা কোলন টাইপ করা হবে। একই অনুশীলন কখনও কখনও খালি লুপ ব্যবহার করা হয়: while(something) { ; // do nothing }। (লাইন ব্রেকগুলির কোড, স্পষ্টতই। এস মন্তব্যগুলি তাদের অনুমতি দেয় না)

— লন্ডিন

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

— Iłya Bursov

Answer 2

আপনার সংস্থা মিস্রা কোডিং গাইডেন্স অনুসরণ করেছে। এই নিয়মটি অন্তর্ভুক্ত করার জন্য এই নির্দেশিকাগুলির কয়েকটি সংস্করণ রয়েছে তবে মিশ্র-সি থেকে: 2004 ^† :

বিধি 14.10 (প্রয়োজনীয়): সমস্ত যদি… অন্যথায় যদি নির্মাণ অন্য কোন ধারা দিয়ে শেষ করা হবে।

এই বিধিটি প্রয়োগ হয় যখনই যদি একটি বিবৃতি অনুসরণ করে এক বা একাধিক অন্য বিবৃতি অনুসরণ করে; চূড়ান্ত অন্য ifএকটি else বিবৃতি অনুসরণ করা হবে । কোনও সাধারণ ifবিবৃতি দেওয়ার ক্ষেত্রে else বিবৃতিটি অন্তর্ভুক্ত করার দরকার নেই। একটি চূড়ান্ত else বিবৃতি জন্য প্রয়োজন রক্ষণাত্মক প্রোগ্রামিং। elseবিবৃতি পারেন যথাযথ ব্যবস্থা গ্রহণ বা কেন কোনো পদক্ষেপ না নেওয়া হিসেবে উপযুক্ত মন্তব্য থাকিতে হইবে। এটি defaultএকটি switchবিবৃতিতে একটি চূড়ান্ত ধারা থাকা প্রয়োজনের সাথে সামঞ্জস্যপূর্ণ । উদাহরণস্বরূপ এই কোডটি যদি সরল হয় তবে বিবৃতি:

if ( x < 0 )
{
 log_error(3);
 x = 0;
} /* else not needed */

যেখানে নিম্নলিখিত কোডটি একটি if, else ifনির্মাণকে দেখায়

if ( x < 0 )
{
 log_error(3);
 x = 0;
}
else if ( y < 0 )
{
 x = 3;
}
else /* this else clause is required, even if the */
{ /* programmer expects this will never be reached */
 /* no change in value of x */
}

ইন মিশ্রের-সি: 2012 , যা 2004 সংস্করণ supersedes এবং নতুন প্রকল্পগুলির জন্য বর্তমান সুপারিশ থাকে না, একই নিয়ম বিদ্যমান কিন্তু 15.7 নম্বর বলে ।

উদাহরণ 1: একক ক্ষেত্রে যদি বিবৃতি প্রোগ্রামারকে n সংখ্যার শর্তাদি পরীক্ষা করতে হবে এবং একক ক্রিয়াকলাপ সম্পাদন করতে পারে।

if(condition_1 || condition_2 || ... condition_n)
{
   //operation_1
}

নিয়মিত ব্যবহারে একটি অপারেশন সম্পাদন করা যখন ifব্যবহার করা হয় তখন সর্বদা প্রয়োজন হয় না ।

উদাহরণ 2: এখানে প্রোগ্রামার এন শর্তগুলির সংখ্যা এবং একাধিক ক্রিয়াকলাপ পরীক্ষা করে। নিয়মিত ব্যবহারের if..else ifক্ষেত্রে switchআপনার ডিফল্টর মতো অপারেশন করার প্রয়োজন হতে পারে। সুতরাং elseমিস্রা স্ট্যান্ডার্ড অনুযায়ী ব্যবহারের প্রয়োজন

if(condition_1 || condition_2 || ... condition_n)
{
   //operation_1
}
else if(condition_1 || condition_2 || ... condition_n)
{
  //operation_2
}
....
else
{
   //default cause
}

---

^These এই প্রকাশনাগুলির বর্তমান এবং অতীত সংস্করণগুলি মিস্রা ওয়েবস্টোরের মাধ্যমে ( মাধ্যমে ) কেনার জন্য উপলব্ধ ।

Comments

ধন্যবাদ, আপনার উত্তরটি মিস্রা নিয়মের সমস্ত বিষয়বস্তু, তবে আমি প্রশ্নের সম্পাদনার অংশে আমার বিভ্রান্তির জন্য একটি উত্তর আশা করি।

— ট্রেভর

ভাল উত্তর. কৌতূহলের বাইরে, আপনি যদি elseঅনুচ্ছেদটি অ্যাক্সেসযোগ্য হওয়ার প্রত্যাশা করেন তবে সেই গাইডগুলি কী করবেন সে সম্পর্কে কিছু বলতে চান ? (পরিবর্তে চূড়ান্ত শর্তটি ছেড়ে দিন, সম্ভবত একটি ত্রুটি নিক্ষেপ করুন)

— jpmc26

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

— লন্ডিন

@ ট্রাইওভেন: প্রশ্নগুলি অবশ্যই লক্ষ্যবস্তুগুলিকে চলবে না । আপনার প্রশ্ন পোস্ট করার আগে নিশ্চিত হয়ে নিন যে আপনার প্রশ্ন সম্পূর্ণ হয়েছে ।

— টিজে ক্রাউডার

@ jpmc26 না, তবে মিস্রার পয়েন্টটি আপনাকে শক্ত কোড দেবে না, এটি আপনাকে নিরাপদ কোড দেবে। এই দিনগুলির যে কোনও সংকলক যেকোন উপায়ে অ্যাক্সেসযোগ্য কোডটিকে অপ্টিমাইজ করবে, সুতরাং কোনও খারাপ দিক নেই।

— গ্রাহাম

Answer 3

এটি প্রতিটি সুইচে একটি ডিফল্ট কেস প্রয়োজনের সমতুল্য।

এই অতিরিক্ত অন্যটি আপনার প্রোগ্রামের কোড কভারেজ হ্রাস করবে ।

---

লিনাক্স কার্নেল, বা অ্যান্ড্রয়েড কোডকে বিভিন্ন প্ল্যাটফর্মে পোর্টিং করার সাথে আমার অভিজ্ঞতায় অনেক সময় আমরা কিছু ভুল করি এবং লগকটে আমরা কিছু ত্রুটি দেখতে পাই

if ( x < 0 )
{
    x = 0;
}
else if ( y < 0 )
{
    x = 3;
}
else    /* this else clause is required, even if the */
{       /* programmer expects this will never be reached */
        /* no change in value of x */
        printk(" \n [function or module name]: this should never happen \n");

        /* It is always good to mention function/module name with the 
           logs. If you end up with "this should never happen" message
           and the same message is used in many places in the software
           it will be hard to track/debug.
        */
}

Comments

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

— পিটার কর্ডেস

Answer 4

আমি একটি সংক্ষিপ্ত ব্যাখ্যা, যেহেতু আমি প্রায় 5 বছর আগে এই সমস্ত করেছি।

"নাল" elseবিবৃতি (এবং অপ্রয়োজনীয় {..}) অন্তর্ভুক্ত করার জন্য (বেশিরভাগ ভাষার সাথে) কোন সিনট্যাকটিক প্রয়োজনীয়তা নেই এবং "সাধারণ ছোট প্রোগ্রামগুলি" তে কোনও প্রয়োজন নেই। তবে প্রকৃত প্রোগ্রামাররা "সাধারণ ছোট্ট প্রোগ্রামগুলি" লেখেন না, এবং ঠিক তেমনি গুরুত্বপূর্ণ, তারা এমন প্রোগ্রামগুলি লেখেন না যা একবার ব্যবহার করা হবে এবং তারপরে ফেলে দেওয়া হবে।

যখন কেউ লিখতে হয় / অন্যথায়:

if(something)
  doSomething;
else
  doSomethingElse;

এটি সমস্ত সহজ বলে মনে হয় এবং একটি যুক্ত করার বিষয়টি খুব কমই দেখে {..}।

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

if(something)
  doSomething;
else
  doSomethingIForgot;
  doSomethingElse;

হঠাৎ doSomethingElseকিন্ডা ভুলে যায় যে এটি elseপায়ে থাকার কথা।

সুতরাং আপনি একটি ভাল ছোট প্রোগ্রামার এবং আপনি সর্বদা ব্যবহার {..}। তবে আপনি লিখুন:

if(something) {
  if(anotherThing) {
    doSomething;
  }
}

নতুন বাচ্চা একটি মধ্যরাতে পরিবর্তন না হওয়া পর্যন্ত সব ঠিক আছে:

if(something) {
  if(!notMyThing) {
  if(anotherThing) {
    doSomething;
  }
  else {
    dontDoAnything;  // Because it's not my thing.
  }}
}

হ্যাঁ, এটি যথাযথভাবে ফর্ম্যাট করা হয়েছে, তবে প্রকল্পের অর্ধেক কোড এটিই এবং সমস্ত #ifdefবিবৃতিতে "অটো ফর্ম্যাটর" বোলিং হয়ে যায় । এবং, অবশ্যই, আসল কোডটি এই খেলনার উদাহরণের চেয়ে অনেক বেশি জটিল।

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

Answer 5

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

এটি একটি ভাল প্রোগ্রামিং অনুশীলন, যা কোড পুনরায় ব্যবহারযোগ্য এবং প্রসারিত-সক্ষম করে ।

Answer 6

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

প্রশ্নটি নিজেই একটি ভাল পাল্টা-উদাহরণ বৈশিষ্ট্যযুক্ত: দ্বিতীয় শর্তটি মোটেও x এর সাথে সম্পর্কিত নয় (যে কারণে আমি প্রায়শই স্যুইচ-ভিত্তিক বৈকল্পিকের চেয়ে বেশি নমনীয় হলে পছন্দ করি)। উদাহরণ থেকে এটি সুস্পষ্ট যে শর্তটি যদি পূরণ হয় তবে এক্সকে একটি নির্দিষ্ট মান হিসাবে সেট করা উচিত। A কে পূরণ করা উচিত নয়, তবে শর্ত বি পরীক্ষা করা হয়। যদি এটি পূরণ হয়, তবে এক্সের আরও একটি মান পাওয়া উচিত। যদি A বা B উভয়ই পূরণ না হয় তবে এক্স অপরিবর্তিত থাকবে।

এখানে আমরা দেখতে পাচ্ছি যে একটি ফাঁকা অন্য শাখা পাঠকের জন্য প্রোগ্রামারের উদ্দেশ্য সম্পর্কে মন্তব্য করতে ব্যবহার করা উচিত।

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

if (A) {
    // do something
}
else {
    if (B) {
        // do something else (no pun intended)
    }
    else {
        // don't do anything here
    }
}

যখন মিশ্রা প্রতিটি শাখার চারদিকে কোঁকড়ানো ধনুর্বন্ধনী লাগানোর অনুরোধ জানায়, তখন এটি "যদি ... অন্যটি যদি গঠন করে" উল্লেখ করে নিজেকে বিপরীত করে তোলে।

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

if (A) {
    if (B) {
        // do something
    }
    // you could to something here
}
else {
    // or here
    if (B) { // or C?
        // do something else (no pun intended)
    }
    else {
        // don't do anything here, if you don't want to
    }
    // what if I wanted to do something here? I need brackets for that.
}

সুতরাং আমি নিশ্চিত যে মিশ্র গাইডলাইনগুলি বিকাশকারী লোকেরা যদি উদ্দেশ্যটি বিবেচনা করে থাকে তবে যদি স্যুইচ-এর মতো ছিল।

শেষ পর্যন্ত, এটি "যদি ... অন্যথায় যদি নির্মাণ করা হয়" এর অর্থ কী তা সুনির্দিষ্টভাবে সংজ্ঞায়িত করা তাদের পক্ষে নেমে আসে

Answer 7

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

তবে কিছু শর্ত সঠিকভাবে উদাহরণ 1 এর মতো, ট্যাক্স রিটার্নের মতো হতে পারে: "ফলাফল যদি 0 এর চেয়ে কম হয় তবে 0 লিখুন" " শর্তটি মিথ্যা যেখানে আপনার এখনও পরীক্ষা করা দরকার।

Answer 8

যৌক্তিকভাবে যে কোনও পরীক্ষা দুটি শাখা বোঝায়। এটি সত্য হলে আপনি কী করবেন এবং এটি মিথ্যা হলে আপনি কী করবেন।

যেসব ক্ষেত্রে উভয় শাখার কার্যকারিতা নেই, কেন এটির কার্যকারিতা থাকার প্রয়োজন হয় না সে সম্পর্কে একটি মন্তব্য যুক্তিযুক্ত যুক্তিসঙ্গত।

এটি পরবর্তী রক্ষণাবেক্ষণ প্রোগ্রামারের সাথে আসার জন্য উপকারী হতে পারে। কোডটি সঠিক কিনা তা নির্ধারণ করার জন্য তাদের খুব বেশি দূরে অনুসন্ধান করতে হবে না। আপনি হাতি প্রেহান্ট ধরনের পারেন ।

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

আপনার মাইলেজ পরিবর্তিত হতে পারে.

Answer 9

বেশিরভাগ সময় যখন আপনার কেবলমাত্র একটি ifবিবৃতি থাকে, সম্ভবত এটির অন্যতম কারণ যেমন:

• ফাংশন গার্ড চেক
• প্রারম্ভিককরণ বিকল্প
• .চ্ছিক প্রক্রিয়াকরণ শাখা

উদাহরণ

void print (char * text)
{
    if (text == null) return; // guard check

    printf(text);
}

তবে আপনি যখন করেন if .. else if, সম্ভবত এটির অন্যতম কারণ যেমন:

• গতিশীল সুইচ-কেস
• প্রসেসিং কাঁটাচামচ
• একটি প্রক্রিয়াজাতকরণ পরামিতি হ্যান্ডেল করা

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

উদাহরণ

int absolute_value (int n)
{
    if (n == 0)
    {
        return 0;
    }
    else if (n > 0)
    {
        return n;
    }
    else /* if (n < 0) */ // redundant check
    {
        return (n * (-1));
    }
}

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

উদাহরণ

#DEFINE SQRT_TWO   1.41421356237309504880
#DEFINE SQRT_THREE 1.73205080756887729352
#DEFINE SQRT_FIVE  2.23606797749978969641

double square_root (int n)
{
         if (n  > 5)   return sqrt((double)n);
    else if (n == 5)   return SQRT_FIVE;
    else if (n == 4)   return 2.0;
    else if (n == 3)   return SQRT_THREE;
    else if (n == 2)   return SQRT_TWO;
    else if (n == 1)   return 1.0;
    else if (n == 0)   return 0.0;
    else               return sqrt(-1); // error handling
}

এই চূড়ান্ত elseদফা বেশ যেমন ভাষায় কয়েক অন্যান্য বিষয় অনুরূপ Javaএবং C++যেমন:

• default একটি সুইচ বিবৃতিতে কেস
• catch(...)এটি সমস্ত নির্দিষ্ট catchব্লকের পরে আসে
• finally একটি চেষ্টা ধরুন ধারা

Answer 10

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

Answer 11

ঠিক আছে, আমার উদাহরণে অপরিবর্তিত আচরণ জড়িত, তবে কখনও কখনও কিছু লোক অভিনব হওয়ার চেষ্টা করে এবং কঠোরভাবে ব্যর্থ হয়, একবার দেখুন:

int a = 0;
bool b = true;
uint8_t* bPtr = (uint8_t*)&b;
*bPtr = 0xCC;
if(b == true)
{
    a += 3;
}
else if(b == false)
{
    a += 5;
}
else
{
    exit(3);
}

আপনি সম্ভবত কখনও boolযা প্রত্যাশা করবেন না যা trueনা হয় false, তবে এটি হতে পারে। ব্যক্তিগতভাবে আমি বিশ্বাস করি যে এটি অভিনব কিছু করার সিদ্ধান্ত নিয়েছে এমন ব্যক্তির দ্বারা সমস্যা, তবে অতিরিক্ত elseবিবৃতি পরবর্তী কোনও সমস্যা রোধ করতে পারে।

Answer 12

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

যদি ব্যবহারকারী বোতাম জমা দেয় -> এটি পরবর্তী বিবৃতিতে চলে যায় ... যদি ব্যবহারকারীর নাম 'এক্স' এর চেয়ে কম অক্ষরের হয় তবে সতর্কতা অবলম্বন করুন। যদি সফল হয় তবে পাসওয়ার্ডের দৈর্ঘ্য ইত্যাদি পরীক্ষা করুন।

সার্ভার লোড সময়ের জন্য সমস্ত অতিরিক্ত কোড চেক করার জন্য নির্ভরযোগ্যতা খারিজ করতে পারলে অতিরিক্ত কোডের প্রয়োজন নেই।