অন্য কি ব্লক কোড জটিলতা বৃদ্ধি করে? [বন্ধ]

Question

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

string CanLeaveWithoutUmbrella()
{
    if(sky.Color.Equals(Color.Blue))
    {
        return "Yes you can";
    }
    else
    {
        return "No you can't";
    }
}

আমি প্রচুর লোকের সাথে দেখা করেছি, রিশ্যার্পার এবং এই লোকটি (যার মন্তব্য আমাকে মনে করিয়ে দিয়েছিল আমি কিছুক্ষণের জন্য এটি জিজ্ঞাসা করতে চেয়েছি ) elseব্লকটি সরিয়ে ফেলতে কোডটি রিফ্যাক্ট করার পরামর্শ দিবে :

(সংখ্যাগরিষ্ঠরা যা বলেছেন তা আমি স্মরণ করতে পারি না, আমি অন্যথায় এটি জিজ্ঞাসা নাও করতে পারি)

string CanLeaveWithoutUmbrella()
{
    if(sky.Color.Equals(Color.Blue))
    {
        return "Yes you can";
    }
    return "No you can't";
}

প্রশ্ন:else ব্লকটি অন্তর্ভুক্ত না করে জটিলতা বাড়ানো কি ?

elseউভয় ব্লকের কোডই সরাসরি সম্পর্কিত কিনা তা উল্লেখ করে আমি আরও প্রত্যক্ষভাবে রাষ্ট্রের অভিপ্রায়ের আওতায় আছি ।

অতিরিক্তভাবে আমি দেখতে পেয়েছি যে আমি যুক্তিতে সূক্ষ্ম ভুলগুলি আটকাতে পারি, বিশেষ করে পরবর্তী তারিখে কোড পরিবর্তন করার পরে।

আমার সরলীকৃত উদাহরণের এই প্রকরণটি ধরুন ( orঅপারেটরটি যেহেতু এটি উদ্দেশ্যমূলকভাবে সরলীকৃত উদাহরণ , তা উপেক্ষা করছেন ):

bool CanLeaveWithoutUmbrella()
{
    if(sky.Color != Color.Blue)
    {
        return false;
    }
    return true;
}

ifপ্রথম শর্তটি তাত্ক্ষণিকভাবে যথাযথভাবে স্বীকৃতি না দিয়ে নিজের অবস্থার প্রতিবন্ধকতা স্থাপনের পরে কেউ এখন প্রথম উদাহরণের পরে একটি শর্তের ভিত্তিতে একটি নতুন ব্লক যুক্ত করতে পারে।

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

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

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

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

Comments

বাস্তবে, যখন "রিটার্ন" সহ "যদি" বিবৃতি থাকে, তখন এটি 50% ক্ষেত্রে "গার্ড ব্লক" হিসাবে দেখা যায়। সুতরাং আমি মনে করি আপনার ভুল ধারণাটি এখানে রয়েছে যে "গার্ড ব্লক" ব্যতিক্রমী কেস এবং আপনার উদাহরণটি নিয়মিত ক্ষেত্রে।

— ডক ব্রাউন

@ অ্যাসোসটারট্রেইলমিক্স: আমি সম্মত হলাম যে elseধারাটি লেখার সময় উপরের মতো একটি মামলা আরও পাঠযোগ্য হতে পারে (আমার স্বাদ অনুসারে, অযৌক্তিক বন্ধনী ছেড়ে দেওয়ার সময় এটি আরও বেশি পঠনযোগ্য হবে। তবে আমি মনে করি উদাহরণটি ভালভাবে বেছে নেওয়া হয়নি, কারণ উপরের কেসটি আমি লিখব return sky.Color == Color.Blue(অন্যথায় / না হলে) b বুলের চেয়ে আলাদা রিটার্ন টাইপের একটি উদাহরণ সম্ভবত এই পরিষ্কার করে দেবে

— ডক ব্রাউন

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

— gnat

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

— শশাঙ্ক গুপ্ত

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

— মাইকেল শ

Answer 1

আমার দৃষ্টিতে, স্পষ্টত অন্য ব্লকটি পছন্দনীয়। আমি যখন এটি দেখছি:

if (sky.Color != Blue) {
   ...
}  else {
   ...
}

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

আমি যখন এটি দেখছি:

if (sky.Color != Blue) {
   ...
} 
return false;

এটি প্রথম নজরে দেখে মনে হচ্ছে এটি নির্বিশেষে মিথ্যা ফিরিয়ে দেয় এবং optionচ্ছিক পার্শ্ব প্রতিক্রিয়া রয়েছে আকাশটি নীল নয়।

আমি এটি দেখতে হিসাবে, দ্বিতীয় কোডের গঠন কোডটি আসলে কী করে তা প্রতিফলিত করে না। এটা খারাপ. পরিবর্তে, প্রথম বিকল্পটি চয়ন করুন যা যৌক্তিক কাঠামোর প্রতিফলন করে। যৌক্তিক প্রবাহটি জানার জন্য প্রতিটি ব্লকে রিটার্ন / ব্রেক / অবিরত যুক্তি পরীক্ষা করার দরকার নেই।

যে কেউ অন্যটিকে কেন পছন্দ করবে তা আমার কাছে একটি রহস্য, আশা করি কেউ তার বিপরীতে অবস্থানটি আমাকে আলোকিত করবে।

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

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

এই উত্তরের মূল সংস্করণের অল্প সময়ের পরে, আমার প্রকল্পে এর মতো কোডটি আবিষ্কার হয়েছিল:

Foobar merge(Foobar left, Foobar right) {
   if(!left.isEmpty()) {
      if(!right.isEmpty()) {
          Foobar merged = // construct merged Foobar
          // missing return merged statement
      }
      return left;
   }
   return right;
}

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

Comments

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

— সিলালি অ্যাডোবর

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

— টেলাস্টিন

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

— উইনস্টন ইওয়ার্ট

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

— ডক ব্রাউন

... সুতরাং আপনি যা লিখেছেন তা ভুল নয়, তবে আইএমএইচও আপনি যে পরিমাণে উন্নতি করেছেন তা মূল্যবান নয়।

— ডক ব্রাউন

Answer 2

elseআমি যে ব্লকটি পেয়েছি সেটি সরিয়ে ফেলার মূল কারণটি অতিরিক্ত ইনডেন্টিং। elseব্লকের সংক্ষিপ্ত সার্কিট অনেক বেশি চাটুকার কোড কাঠামো সক্ষম করে।

অনেক ifবক্তব্য মূলত প্রহরী are তারা নাল পয়েন্টার এবং অন্যান্য "এই কাজ না!" ত্রুটি। এবং তারা বর্তমান ফাংশনটি দ্রুত সমাপ্তির দিকে নিয়ে যায়। উদাহরণ স্বরূপ:

if (obj === NULL) {
    return NULL;
}
// further processing that now can assume obj attributes are set

এখন মনে হচ্ছে elseএখানে একটি ধারা খুব যুক্তিসঙ্গত হবে:

if (obj === NULL) {
    return NULL;
}
else if (obj.color != Blue) {
   // handle case that object is not blue
}

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

elements = tree.xpath(".//p");
if (elements === NULL) {
    return NULL;
}
p = elements[0]
if ((p.children === NULL) or (p.children.length == 0)) {
    return NULL;
}
for (c in p.children) {
    c.text = c.text.toUpperCase();
}
return p;

গার্ডরা কোডের ইন্ডেন্টেশন বাড়ায় না। একটি elseধারা সহ, সমস্ত আসল কাজ ডানদিকে যেতে শুরু করে:

elements = tree.xpath(".//p");
if (elements === NULL) {
    return NULL;
}
else {
    p = elements[0]
    if ((p.children === NULL) or (p.children.length == 0)) {
        return NULL;
    }
    else {
        for (c in p.children) {
            c.text = c.text.toUpperCase();
        }
        return p;
    }
}

এটির সাথে উল্লেখযোগ্য ডানদিকের গতি শুরু হয় এবং এটি কেবল দুটি রক্ষাকারী শর্ত সহ একটি সুন্দর তুচ্ছ উদাহরণ। প্রতিটি অতিরিক্ত প্রহরী অন্য ইন্ডেন্টেশন স্তর যুক্ত করে। রিয়েল কোড আমি প্রসেসিং XML লিখেছি বা বিস্তারিত জেএসওএন ফিড গ্রহণ করায় সহজেই 3, 4 বা তার বেশি গার্ডের শর্ত থাকতে পারে। আপনি যদি সর্বদা এটি ব্যবহার করেন তবে আপনি else4, 5 বা 6 স্তরগুলিতে ইন্ডেন্টেড শেষ করবেন Maybe এবং এটি অবশ্যই কোড জটিলতার অনুভূতিতে অবদান রাখে এবং কোনটি কী লাইন আপ করে তা বোঝার জন্য আরও সময় ব্যয় করে। দ্রুত, সমতল, প্রারম্ভিক-প্রস্থান শৈলী সেই "অতিরিক্ত কাঠামো" থেকে কিছু সরিয়ে দেয় এবং আরও সহজ বলে মনে হয়।

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

Comments

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

— সেলালি অ্যাডোবর

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

— জোনাথন ইউনিস

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

— উইনস্টন ইওয়ার্ট

অন্য যেসব ক্ষেত্রে এড়ানো যায় তার সঠিক ব্যাখ্যা এটি।

— ক্রিস শিফহাউয়ার

আমি পরিবর্তে মূর্খ NULL উত্পাদন না করার জন্য API কে জড়িয়ে দিতাম।

— উইনস্টন ইওয়ার্ট

Answer 3

আমি যখন এটি দেখছি:

if(something){
    return lamp;
}
return table;

আমি একটি সাধারণ বুদ্ধিমান দেখতে পাচ্ছি । একটি সাধারণ প্যাটার্ন , যা আমার মাথায় অনুবাদ করে:

if(something){
    return lamp;
}
else return table;

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

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

উদাহরণস্বরূপ, নিম্নলিখিত পাঠ্য পড়ুন:

তুমি কি এটা পড়েছ?

আমি বসন্তকালে প্যারিসকে ভালবাসি

যদি তাই হয়, আপনি ভুল। লেখাটি আবার পড়ুন। আসলে যা লেখা আছে তা হচ্ছে

আমি প্যারিসে ভালবাসেন বসন্তকালীন

আছে দুই "" পাঠ্যে শব্দ। তাহলে আপনি দুজনের একজনকে কেন মিস করলেন?

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

উপরের আইডিয়ামের সাথে একই জিনিস। প্রোগ্রামাররা যারা কোড অনেক পড়েছি এই এইজন্য ব্যবহার করা হয় প্যাটার্ন এর if(something) {return x;} return y;। elseএর অর্থ বোঝার জন্য তাদের কোনও এক্সপ্লিসিটের দরকার নেই , কারণ তাদের মস্তিষ্ক 'তাদের জন্য এটি সেখানে রাখে'। তারা এটিকে একটি জ্ঞাত অর্থ সহ একটি প্যাটার্ন হিসাবে স্বীকৃতি দেয়: "সমাধিক্ষেত্রের ধনুর্বন্ধনী পরে যা কেবল কেবল elseপূর্ববর্তীটির অন্তর্নিহিত হিসাবে চলবে if"।

সুতরাং আমার মতে, এটি elseঅপ্রয়োজনীয়। তবে কেবল যা পাঠযোগ্য বলে মনে হয় তা ব্যবহার করুন।

Answer 4

তারা কোডটিতে ভিজ্যুয়াল ক্লটারিং যুক্ত করে, তাই হ্যাঁ, তারা জটিলতা যুক্ত করতে পারে।

তবে বিপরীতটিও সত্য, কোডের দৈর্ঘ্য হ্রাস করার জন্য অতিরিক্ত রিফ্যাক্টরিংও জটিলতা যুক্ত করতে পারে (অবশ্যই এই সাধারণ ক্ষেত্রে নয়)।

আমি এই বক্তব্যটির সাথে একমত যে elseব্লকটি উদ্দেশ্য করে nt তবে আমার উপসংহারটি আলাদা, কারণ এটি অর্জনের জন্য আপনি নিজের কোডটিতে জটিলতা যুক্ত করছেন।

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

আসুন একটি উদাহরণ দেখুন, এখন এটি কেবল সত্যই ফিরে আসে যদি আকাশ নীল থাকে এবং উচ্চ আর্দ্রতা থাকে, আর্দ্রতা বেশি না হয় বা আকাশ লাল হয়। তবে তারপরে, আপনি একটি ধনুর্বন্ধকে ভুল করে ভুলতে রেখে দিন else:

bool CanLeaveWithoutUmbrella() {
    if(sky.Color == Color.Blue)
    {
        if (sky.Humidity == Humidity.High) 
        {
            return true;
        } 
    else if (sky.Humidity != Humidity.High)
    {
        return true;
    } else if (sky.Color == Color.Red) 
    {
            return true;
    }
    } else 
    {
       return false;
    }
}

আমরা প্রোডাকশন কোডে এই ধরণের বোকার মতো ভুল দেখেছি এবং এটি সনাক্ত করা খুব কঠিন হতে পারে।

আমি নিম্নলিখিতটি সুপারিশ করব:

আমি এটি পড়া সহজ বলে মনে করি, কারণ আমি এক নজরে দেখতে পাচ্ছি যে ডিফল্ট false।

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

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

• যদি মামলাটি উপস্থাপিত ব্যক্তির মতোই সহজ হয়, তবে আমার উত্তরটি হ'ল কোনও if elseদফা বাদ দেওয়া উচিত।

  রিটার্ন (স্কাই। কালার == কালার. ব্লু);

• মামলাটি যদি আরও কিছু জটিল হয়, বিভিন্ন ধারা সহ, আমি উত্তর দেব:

  বুল ক্যানলিভ উইথআউটআম্ব্রেলা () {

  if(sky.Color == Color.Blue && sky.Humidity == Humidity.High) {
      return true;
  } else if (sky.Humidity != Humidity.High) {
      return true;
  } else if (sky.Color == Color.Red) {
      return true;
  }
  
  return false;
  

  }

• যদি মামলাটি জটিল হয় এবং সমস্ত ধারাগুলি সত্য না হয় (সম্ভবত তারা ডাবল ফেরত দেয়) এবং আমি কিছু ব্রেকপয়েন্ট বা লগগিন কমান্ড প্রবর্তন করতে চাই, আমি এরকম কিছু বিবেচনা করব:

  double CanLeaveWithoutUmbrella() {
  
      double risk = 0.0;
  
      if(sky.Color == Color.Blue && sky.Humidity == Humidity.High) {
          risk = 1.0;
      } else if (sky.Humidity != Humidity.High) {
          risk = 0.5;
      } else if (sky.Color == Color.Red) {
          risk = 0.8;
      }
  
      Log("value of risk:" + risk);
      return risk;
  

  }

• যদি আমরা এমন কোনও পদ্ধতির কথা বলছি না যা কিছু ফেরত দেয় তবে পরিবর্তে একটি if-else ব্লক যা কিছু পরিবর্তনশীল সেট করে বা কোনও পদ্ধতি কল করে, তবে হ্যাঁ, আমি একটি চূড়ান্ত elseধারাটি অন্তর্ভুক্ত করব ।

সুতরাং, উদাহরণের সরলতা বিবেচনা করার একটি বিষয়ও।

Comments

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

— সিলালী অ্যাডোবর

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

— ফ্র্যানমউইঙ্কেল

এবং যেমনটি আমি লক্ষ্য করি, আমি এটি সুপরিচিত ওপেন / বদ্ধ নীতি সম্পর্কিত বলে উল্লেখ করছি না। আমি মনে করি আপনার পরামর্শ অনুসারে আপনার কোডটি সংশোধন করতে নেতৃত্ব দেওয়ার ধারণাটি ত্রুটিযুক্ত to আমি কেবল এই নীতিটি থেকে এই ধারণা নিচ্ছি।

— ফ্র্যানমউইঙ্কেল

সম্পাদনাগুলি ধরে রাখুন, আপনি ভাল কিছু করছেন, আমি এই মুহূর্তে একটি মন্তব্য

— লিখছি

Answer 5

যদিও বর্ণিত if-অন্য কেসের ক্ষেত্রে আরও জটিলতা রয়েছে, বেশিরভাগ (তবে সমস্ত নয়) ব্যবহারিক পরিস্থিতিতে এটি খুব বেশি গুরুত্ব দেয় না।

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

কারণটা এখানে.

'অন্য' এর উপস্থিতি একটি অন্তর্নিহিত তৃতীয় কেস তৈরি করেছিল যা মূল্যায়ন করতে হয়েছিল - এটি 'যদি' বা 'অন্য' নেওয়া হয় নি। আপনি ভাবছেন (যেমন আমি তখন ছিলাম) ডব্লিউটিএফ?

ব্যাখ্যাটি এভাবে চলে গেল ...

যৌক্তিক দৃষ্টিকোণ থেকে, কেবল দুটি বিকল্প রয়েছে - 'যদি' এবং 'অন্য'। তবে আমরা যা যাচাই করছিলাম তা হ'ল সংকলকটি তৈরি করা অবজেক্ট ফাইল। সুতরাং, যখন একটি 'অন্য' ছিল, তখন উত্পন্ন ব্রাঞ্চিং কোডটি সঠিক ছিল এবং এটি একটি রহস্যজনক 3 র্থ পথটি উপস্থিত হয়নি তা নিশ্চিত করার জন্য একটি বিশ্লেষণ করতে হবে।

এটির ক্ষেত্রে এটির তুলনা করুন যেখানে কেবল 'যদি' এবং 'অন্য' নয়। সেক্ষেত্রে কেবল দুটি বিকল্প রয়েছে - 'যদি' পথ এবং 'যদি না-হয়' পথ path মূল্যায়নের জন্য দুটি ক্ষেত্রে তিনটি কম জটিল।

আশাকরি এটা সাহায্য করবে.

Comments

কোনও অবজেক্ট ফাইলে, কেসটি কি অভিন্ন জম্পাস হিসাবে রেন্ডার হবে না?

— উইনস্টন ইওয়ার্ট

@ উইনস্টনওয়ার্ট - কেউ আশা করবে তাদের একই হবে। তবে, যেটি রেন্ডার করা হয় এবং যা রেন্ডার হওয়ার প্রত্যাশা করে তা হ'ল দুটি আলাদা জিনিস, তারা যতই না ওভারল্যাপ করে।

— স্পার্কি

(আমার ধারণা এসই আমার মন্তব্য খেয়েছে ...) এটি একটি খুব আকর্ষণীয় উত্তর। যদিও আমি বলব যে

— কেসটি উদ্ভাসিত হয়েছে

Answer 6

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

def value(key):
    if key == FROB:
        return FOO
    elif key == NIK:
        return BAR
    [...]
    else:
        return BAZ

এটি বেশ পরিষ্কার - এটি একটি caseবিবৃতি বা অভিধান দেখার সমতুল্য , এর উচ্চ-স্তরের সংস্করণ return foo == bar:

KEY_VALUES = {FROB: FOO, NIK: BAR, [...]}
DEFAULT_VALUE = BAZ

def value(key):
    return KEY_VALUES.get(key, default=DEFAULT_VALUE)

এটি আরও পরিষ্কার, কারণ টোকেনের সংখ্যা বেশি হলেও (দুটি কী / মান জোড়া সহ মূল কোডের জন্য 32 বনাম 24), ফাংশনটির শব্দার্থকতা এখন সুস্পষ্ট: এটি কেবল একটি চেহারা।

(এর রিফ্যাক্টরিংয়ের জন্য পরিণতি রয়েছে - আপনি যদি পার্শ্ব প্রতিক্রিয়া key == NIKকরতে চান তবে আপনার তিনটি পছন্দ রয়েছে:

1. if/ elif/ elseশৈলীতে ফিরে যান এবং key == NIKক্ষেত্রে একটি একক লাইন .োকান ।
2. দেখার ফলাফলটিকে একটি মানে সংরক্ষণ করুন এবং প্রত্যাবর্তনের আগে বিশেষ মামলার জন্য একটি ifবিবৃতি যুক্ত করুন value।
3. কলারে একটি ifবিবৃতি দিন ।

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

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

Comments

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

— জোনাথন ইউনিস

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

— l0b0

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

— সেলাালী অ্যাডোবার

Answer 7

আমি মনে করি এটি নির্ভর করে আপনি কী ধরণের ifবিবৃতি ব্যবহার করছেন depends কিছু ifবিবৃতি এক্সপ্রেশন হিসাবে দেখা যেতে পারে, এবং অন্যদের শুধুমাত্র নিয়ন্ত্রণ-প্রবাহ বিবৃতি হিসাবে দেখা যেতে পারে।

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

টেরিনারি অপারেটরটি ব্যবহার করে, আপনার উদাহরণটি দেখতে এরকম হবে:

bool CanLeaveWithoutUmbrella()
{
    return (sky.Color == Color.Blue)
               ? true
               : false;
}

এটি যেহেতু এটি একটি বুলিয়ান অভিব্যক্তি, যদিও, এটি সত্যই সমস্ত উপায় সরল করা উচিত

bool CanLeaveWithoutUmbrella()
{
    return (sky.Color == Color.Blue);
}

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

Comments

+1, ওপি হ'ল আইএমএইচও একটি প্যাথলজিকাল কেস নিয়ে আলোচনা করছে যা উপরে আপনি যেভাবে দেখিয়েছেন সেভাবে আরও ভাল লেখা উচিত। জন্য আরো অনেক কিছু ঘন ক্ষেত্রে "যদি" "রিটার্ন" সঙ্গে হয় আমার অভিজ্ঞতা "পাহারা" ক্ষেত্রে।

— ডক ব্রাউন

আমি জানি না কেন এটি ঘটতে থাকে তবে লোকেরা প্রশ্নের প্রথম অনুচ্ছেদটিকে এড়িয়ে চলে। আসলে, আপনি সবাই কোডের সঠিক লাইনটি ব্যবহার করছেন যা আমি স্পষ্টভাবে ব্যবহার না করার জন্য বলছি। I ask that you ignore the many other ways the function can be written, and changes that can be made to it. (I know most people are itching to write return sky.Color == Color.Blue.)

— সিলালী অ্যাডোবর

এবং আপনার শেষ প্রশ্নটি পুনরায় পড়া আপনার মনে হচ্ছে প্রশ্নের উদ্দেশ্যকে ভুল বুঝবে।

— সেলালি অ্যাডোবর

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

— মাইকেল শ

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

— সেগুলি সমস্তটি

Answer 8

এই যুক্তিতে আরও একটি বিষয় চিন্তা করতে হবে হ'ল প্রতিটি পদ্ধতির অভ্যাসটি প্রচার করে।

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

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

• অবশ্যই 3 বা ততোধিক কেস রয়েছে (এন), যেখানে আমরা সাধারণত যদি / অন্য চেইনটি ত্যাগ করতে এবং কেস / সুইচ স্টেটমেন্ট বা পলিমারফিজম ব্যবহার করতে উত্সাহিত করি।

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

টুলটি আসলে যা সম্পর্কে অভিযোগ করছে তা হ'ল যদি আপনার ব্লকের ভিতরে ফিরতি / বিরতি / নিক্ষিপ্ত হয়। যতদূর এটি উদ্বিগ্ন, আপনি একটি গার্ড ক্লজ লিখেছিলেন তবে এটি খারাপ করে দিয়েছেন। আপনি সরঞ্জামটি খুশি করতে বা এটির পরামর্শ গ্রহণ না করেই তার পরামর্শটিকে "বিনোদন" দিতে পারেন।

Comments

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

— সেলাালী অ্যাডোবর

@ এসর্টেড ট্রিলমিক্স ডান, আপনি elseশব্দার্থবিজ্ঞানের কথা ভাবছেন কোড কোড বিশ্লেষণ সরঞ্জামগুলি সাধারণত বহিরাগত নির্দেশাবলীর সন্ধান করে কারণ তারা প্রায়শই নিয়ন্ত্রণ প্রবাহের একটি ভুল বোঝাবুঝিকে হাইলাইট করে। তার elseপরে ifফেরত বিট নষ্ট হয়। if(1 == 1)প্রায়শই একই ধরণের সতর্কতা ট্রিগার করে।

— স্টিভ জ্যাকসন

Answer 9

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

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

আপনি ইএলএসই অন্তর্ভুক্ত বা অপসারণের সিদ্ধান্ত নেওয়ার আগে, এটি কী উপস্থাপন করে তা স্থির করুন, এটি আপনাকে উপস্থিত থাকতে হবে কিনা তা আপনাকে জানিয়ে দেবে।

Answer 10

উত্তরটি কিছুটা সাবজেক্টিভ। একটি elseব্লক কোডের একটি ব্লক উভয় ব্লকের মাধ্যমে পড়ার প্রয়োজন ছাড়াই কোডের অন্য একটি ব্লকে একচেটিয়াভাবে সম্পাদন করে এটি পাঠযোগ্যতার সহায়তা করতে পারে। উভয় ব্লক তুলনামূলকভাবে দীর্ঘ হলে এটি সহায়ক হতে পারে। মামলা আছে, যদিও যেখানে আছেifঅনেকগুলি এস ছাড়া elseএস থাকা আরও পাঠযোগ্য। নীচের কোডটি বেশ কয়েকটি if/elseব্লকের সাথে তুলনা করুন :

if(a == b) {
    if(c <= d) {
        if(e != f) {
            a.doSomeStuff();
            c.makeSomeThingsWith(b);
            f.undo(d, e);
            return 9;
        } else {
            e++;
            return 3;
        }
    } else {
        return 1;
    }
} else {
    return 0;
}

সঙ্গে:

if(a != b) {
    return 0;
}

if(c > d) {
    return 1;
}

if(e != f) {
    e++;
    return 3;
}

a.doSomeStuff();
c.makeSomeThingsWith(b);
f.undo(d, e);
return 9;

কোডের দ্বিতীয় ব্লকটি নেস্টেডকে পরিবর্তন করে if স্টেটমেন্টগুলিকে গার্ড ক্লজগুলিতে । এটি ইনডেন্টেশন হ্রাস করে এবং রিটার্নের কিছু শর্ত পরিষ্কার করে তোলে ("যদি a != bতবেই আমরা ফিরে আসি)0 !")

---

মন্তব্যগুলিতে এটি ইঙ্গিত করা হয়েছে যে আমার উদাহরণে কিছু ছিদ্র থাকতে পারে, তাই আমি এটি আরও কিছুটা খুঁজে বের করব।

আমরা এখানে কোডের প্রথম ব্লকটি আরও পাঠ্যযোগ্য করে তুলতে এটি লিখতে পারতাম:

if(a != b) {
    return 0;
} else if(c > d) {
    return 1;
} else if(e != f) {
    e++;
    return 3;
} else {
    a.doSomeStuff();
    c.makeSomeThingsWith(b);
    f.undo(d, e);
    return 9;
}

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

...
if(e != f) {
    e++;
    return 3;
}

g.doSomeLogicWith(a);

if(!g.isGood()) {
    return 4;
}

a.doSomeStuff();
...

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

তবে সত্যই, এটি উপলব্ধি করে। if/elseদুর্বলভাবে ব্যবহার করা অংশগুলির মধ্যে সম্পর্ককে বোঝায়। আমরা এটি শৃঙ্খলিত সংস্করণে a != bকোনওভাবে সম্পর্কিত হতে পারি । এই ধারণাটি বিভ্রান্তিকর হবে, কারণ আমরা গার্ড ক্লজ সংস্করণ থেকে দেখতে পাচ্ছি যে তারা আসলে সম্পর্কিত নয়। এর অর্থ হ'ল আমরা স্বতন্ত্র ধারাগুলির সাথে আরও নতুন কিছু করতে পারি, যেমন সেগুলি পুনরায় সাজানো (সম্ভবত ক্যোয়ারীর কার্য সম্পাদনকে অনুকূল করতে বা যৌক্তিক প্রবাহকে উন্নত করতে)। আমরা তাদের অতীত হয়ে গেলে আমরা তাদের জ্ঞানীয়ভাবে এড়িয়ে যেতে পারি। একটি শৃঙ্খলে, আমি নিশ্চিত যে এর মধ্যে সমতা সম্পর্ক কম surec > dif/elseif/elsea এবং bপরে পপ আপ হবে না।

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

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

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

bool CanLeaveWithoutUmbrella()
{
    if(sky.Color != Color.Blue)
    {
        return false;
    }
    return true;
}

এর মতো কোড লেখার জন্য একটি বৈধ ব্যাখ্যা হতে পারে যে "আকাশ নীল না হলে আমাদের কেবল ছাতা দিয়েই চলে যেতে হবে।" এখানে একটি সীমাবদ্ধতা রয়েছে যে কোডটি চালানোর জন্য বৈধ হওয়ার জন্য আকাশটি নীল হতে হবে। আমি আপনার ছাড়ের সংজ্ঞা পেয়েছি।

আমি যদি বলি যে যদি আকাশের রঙ কালো হয় তবে এটি পরিষ্কার রাত, তাই কোনও ছাতা দরকার নেই। (এটি লেখার সহজ উপায় রয়েছে তবে পুরো উদাহরণটি লেখার সহজ উপায় রয়েছে are)

bool CanLeaveWithoutUmbrella()
{
    if(sky.Color == Color.Blue)
    {
        return true;
    }

    if(sky.Color == Color.Black)
    {
        return true;
    }

    return false;
}

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

আমি আরও উল্লেখ করব যে আপনার সাধারণ উদাহরণটিও এত সহজ নয়। নন-বাইনারি মানের জন্য একটি পরীক্ষা উল্টো ফলাফলের সাথে সেই পরীক্ষার বিপরীত হিসাবে একই নয়।

Comments

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

— সিলালী অ্যাডোবর

আপনার প্রথম সংস্করণটি উপলব্ধি করা শক্ত, তবে আমি মনে করি না / যদি তবে / অন্যটি ব্যবহার করে এটি আবশ্যক। আমি এটি কীভাবে লিখব তা দেখুন: gist.github.com/winstonewert/c9e0955bc22ce44930fb ।

— উইনস্টন ইওয়ার্ট

@ উইনস্টনওয়ার্ট আপনার মন্তব্যের প্রতিক্রিয়ার জন্য সম্পাদনাগুলি দেখুন।

— সিবিজার

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

— উইনস্টন ইভার্ট

Answer 11

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

void DoOneOfTwoThings(bool which)
{
    if (which)
        DoThingOne();
    else
        DoThingTwo();
}

... এর চেয়ে বেশি পঠনযোগ্য ...

void DoOneOfTwoThings(bool which)
{
    if (which) {
        DoThingOne();
        return;
    }
    DoThingTwo();
}

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

void ProcessInputOfTypeOne(String input)
{
    if (InputIsReallyTypeTwo(input)) {
        ProcessInputOfTypeTwo(input);
        return;
    }
    ProcessInputDefinitelyOfTypeOne(input);

}

... এর চেয়ে বেশি পঠনযোগ্য ...

void ProcessInputOfTypeOne(String input)
{
    if (InputIsReallyTypeTwo(input))
        ProcessInputOfTypeTwo(input);
    else
        ProcessInputDefinitelyOfTypeOne(input);
}

... কারন ইচ্ছাকৃতভাবে না সমান্তরাল কাঠামো স্থাপনের ভবিষ্যতে পাঠক একটি সুরুক যে ইনপুট যে পেয়ে এখানে "সত্যিই দুই টাইপ করুন" প্রদান করে অস্বাভাবিক । (বাস্তব জীবনে, ProcessInputDefinitelyOfTypeOneএকটি পৃথক ফাংশন হবে না, তাই পার্থক্যটি আরও স্পষ্ট হবে be)

Comments

দ্বিতীয় ক্ষেত্রে আরও দৃ concrete় উদাহরণ বেছে নেওয়া ভাল। এটি সম্পর্কে আমার তাত্ক্ষণিক প্রতিক্রিয়া হ'ল, "আপনি যদি এগিয়ে যান এবং যেভাবেই প্রক্রিয়া করেন তবে এটি এতটা অস্বাভাবিক হতে পারে না।"

— উইনস্টন ইওয়ার্ট

@ উইনস্টোনওয়ার্ট অস্বাভাবিক সম্ভবত ভুল শব্দ। তবে আমি জ্যাকের সাথে একমত, আপনার যদি কোনও ডিফল্ট (কেস 1) থাকে এবং একটি ব্যতিক্রম হয় তবে এটি » if-> ব্যতিক্রমী করুন এবং ছেড়ে যান as হিসাবে একটি রিটার্ন-শুরুর কৌশল হিসাবে লেখা উচিত । কোডটি ভাবুন, যেখানে ডিফল্টটিতে আরও চেক অন্তর্ভুক্ত থাকে, প্রথমে ব্যতিক্রমী কেসটি হ্যান্ডেল করা দ্রুততর হবে।

— থমাস জাঙ্ক

এটি যে মামলার সাথে আমি কথা বলছিলাম তাতে পতিত হচ্ছে বলে মনে হচ্ছে when using an if block to apply a constraint that must be logically satisfied for all following code, such as a null-check (or any other guards)। যৌক্তিকভাবে, যে কোনও কাজ ProcessInputOfTypeOneএই সত্যের উপর নির্ভর করে !InputIsReallyTypeTwo(input), সুতরাং আমাদের আমাদের আমাদের সাধারণ প্রক্রিয়াজাতকরণের বাইরে এটি ধরা উচিত। সাধারণত ProcessInputOfTypeTwo(input);সত্যই এটি হবে throw ICan'tProccessThatExceptionযা মিলকে আরও স্পষ্ট করে তুলবে।

— সিলালী অ্যাডোবর

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

— zwol

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

— zwol

Answer 12

হ্যাঁ, জটিলতা বৃদ্ধি পেয়েছে কারণ অন্য ধারাটি অপ্রয়োজনীয় । কোডটি হাতা এবং বোঝাতে এইভাবে ছেড়ে যাওয়া ভাল। এটি রিডানডেন্ট thisকোয়ালিফায়ার (জাভা, সি ++, সি #) বাদ দেওয়া এবং returnবিবৃতিতে প্যারেনেসেসিস বাদ দেওয়া এবং একইভাবে same

একজন ভাল প্রোগ্রামার মনে করেন "আমি কী যুক্ত করতে পারি?" যখন একজন দুর্দান্ত প্রোগ্রামার মনে করে "আমি কী সরাতে পারি?"

Comments

আমি যখন elseব্লকটি বাদ দিই দেখি , যদি এটি ওয়ান-লাইনারে ব্যাখ্যা করা হয় (যা প্রায়শই হয় না) এটি প্রায়শই এই ধরণের যুক্তি দিয়ে থাকে, সুতরাং আমি "ডিফল্ট" যুক্তিটি উপস্থাপনের জন্য +1 করি তবে আমি তা করি না এটি একটি শক্তিশালী যথেষ্ট যুক্তি হিসাবে মনে হয়। A good programmer things "what can I add?" while a great programmer things "what can I remove?".একটি প্রচলিত প্রবন্ধ বলে মনে হচ্ছে যে প্রচুর লোক সাবধানতার সাথে বিবেচনা না করেই বাড়াবাড়ি করে, এবং আমি ব্যক্তিগতভাবে এটি এ জাতীয় একটি ঘটনা বলে মনে করি।

— সেলালি অ্যাডোবর

হ্যাঁ, আপনার প্রশ্নটি পড়ে আমি অবিলম্বে অনুভব করেছি আপনি ইতিমধ্যে আপনার মন তৈরি করেছেন, তবে নিশ্চিতকরণ চেয়েছিলেন confir এই উত্তরটি আপনি যা চেয়েছিলেন তা স্পষ্টতই নয়, তবে কখনও কখনও আপনার মতামতগুলির সাথে একমত নন এমন মতামত বিবেচনা করাও গুরুত্বপূর্ণ। এটা খুব কিছু আছে?

— 0143

Answer 13

আমি লক্ষ্য করেছি, এই ক্ষেত্রে আমার মন পরিবর্তন।

এক বছর আগে এই প্রশ্নটি জিজ্ঞাসা করা হলে, আমি এরকম কিছু উত্তর দিয়েছি:

A কোনও পদ্ধতিতে কেবল একটি entryএবং এক হওয়া উচিত exit«এবং এই বিষয়টি মনে রেখে আমি কোডটিতে পুনরায় চুল্লি করার পরামর্শ দিই:

bool CanLeaveWithoutUmbrella()
{
    bool result

    if(sky.Color == Color.Blue)
    {
        result = true;
    }
    else
    {
        result = false;
    }

    return result;
}

যোগাযোগের দৃষ্টিকোণ থেকে এটি পরিষ্কার , কী করা উচিত। Ifকিছু একটা ঘটনা, এক ভাবে ফলাফলের নিপূণভাবে , else অন্য উপায়ে তা নিপূণভাবে ।

তবে এর মধ্যে একটি অপ্রয়োজনীয় জড়িত else। elseপ্রকাশ ডিফল্ট-কেস । সুতরাং একটি দ্বিতীয় ধাপে, আমি এটিতে রিফ্যাক্টর করতে পারি

bool CanLeaveWithoutUmbrella()
{
    bool result=false

    if(sky.Color == Color.Blue)
    {
        result = true;
    }
    return result;
}

তারপরে প্রশ্ন উত্থাপিত হয়: কেন সাময়িকভাবে একটি অস্থায়ী পরিবর্তনশীল ব্যবহার? রিফ্যাক্টরাইজেশনের পরবর্তী ধাপে বাড়ে:

bool CanLeaveWithoutUmbrella()
{

    if(sky.Color == Color.Blue)
    {
        return true;
    }
    return false;
}

সুতরাং এটি পরিষ্কার করে। আমি আরও একধাপ এগিয়ে যেতে চাই:

bool CanLeaveWithoutUmbrella()
{

    if(sky.Color == Color.Blue) return true;
    return false;
}

বা অজ্ঞান হৃদয়ের জন্য :

bool CanLeaveWithoutUmbrella()
{

    if(sky.Color == Color.Blue) { return true; }
    return false;
}

আপনি এটা যে ভালো পড়তে পারে: »CanLeaveWithoutUmbrella একটি ফেরৎ bool, । বিশেষ কিছু না হলে এটি মিথ্যা প্রত্যাবর্তন করে উপরে থেকে নীচে এটি প্রথম পঠিত «

এবং তারপরে আপনি কন্ডিশনটি "পার্স" করেন »শর্তটি পূরণ হলে এটি সত্য হয়ে যায় completely আপনি শর্তসাপকে পুরোপুরি এড়িয়ে যেতে পারেন এবং বুঝতে পেরেছিলেন, ডিফল্ট- কেসে এই ফাংশনটি কী করে । আপনার চোখ এবং মন কেবল ডান অংশটি না পড়েই বাম দিকে কয়েকটি অক্ষর দিয়ে স্কিম করতে হবে।

উভয় ব্লকের কোড সরাসরি সম্পর্কিত কিনা তা উল্লেখ করে আমি অন্য প্রত্যক্ষভাবে সরাসরি অভিপ্রায় জানায় আমি ছাপের নীচে।

হ্যা সেটা ঠিক. তবে সেই তথ্য অপ্রয়োজনীয় । আপনার একটি ডিফল্ট কেস এবং একটি "ব্যতিক্রম" রয়েছে যা ifস্টেটমেন্ট দ্বারা আচ্ছাদিত ।

জটিল কাঠামোগুলির সাথে কাজ করার সময়, আমি অন্য কৌশলটি বেছে নেব ifবা এটিকে মোটেও কুরুচিপূর্ণ ভাই বাদ দিয়ে switch।

Comments

+1 অপ্রয়োজনীয় স্পষ্টভাবে কেবল জটিলতা নয়, বিভ্রান্তির বৃদ্ধি দেখায়। আমি জানি আমি অনর্থকতার কারণে সর্বদা ঠিক এভাবে লেখা ডাবল চেক কোডটি শেষ করেছিলাম।

— ডায়েটবুদ্ধ

আপনি কি কেস শুরু হওয়ার পরে মামলাগুলি সরাতে So this is clear in what it does...এবং এটিতে প্রসারিত করতে পারবেন? (এর আগের মামলাগুলিও সন্দেহজনক প্রাসঙ্গিক)। আমি এটি বলছি কারণ প্রশ্নটি যা জিজ্ঞাসা করছে তা আমরা পরীক্ষা করে দেখছি। আপনি আপনার অবস্থানটি বর্ণনা করেছেন, অন্য ব্লকটি বাদ দিয়ে, এবং এটি আসলে এমন অবস্থান যা সম্পর্কে আরও ব্যাখ্যা প্রয়োজন (এবং যেটি আমাকে এই প্রশ্ন জিজ্ঞাসা করতে পেরেছিল)। প্রশ্ন থেকে:I ask that you ignore the many other ways the function can be written, and changes that can be made to it. (I know most people are itching to write return sky.Color == Color.Blue.)

— সেলি অ্যাডোবর

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

— টমাস জাঙ্ক

এবং না! ডাউনভোট বুঝি না।

— থমাস জাঙ্ক

Answer 14

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

return true;

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

আপনার প্রশ্নে, আপনার উল্টানোর পরে if শর্তটি উল্টিয়ে দেওয়ার এবং বাদ দেওয়ার পরে else, আপনি নিম্নলিখিতটি বলেছেন:

প্রথম শর্তটি তাত্ক্ষণিকভাবে সঠিকভাবে স্বীকৃতি না দিয়ে নিজের অবস্থার প্রতিবন্ধকতা রাখছে যদি কেউ প্রথম উদাহরণের পরে একটি শর্তের ভিত্তিতে ব্লক যুক্ত করতে পারে তবে এখন নতুন যুক্ত করতে পারেন।

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

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

এটি মূলত এখানে কী ঘটছে। আপনি থেকে ফিরে করছি ifব্লক, যাতে ifঅবস্থা মূল্যায়নের false হয় একটি বাধ্যতা যে কথাটি নিম্নলিখিত সমস্ত কোড সন্তুষ্ট করতে হবে।

অন্য ব্লকটি অন্তর্ভুক্ত না করে জটিলতা বাড়ানো কি?

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

Comments

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

— মাইকেল শ

@ মিশেলশা আমি মনে করি আভিভ কোনের উত্তর আমি যা বলছি তাতে চলে যায়।

— Panzercrisis

Answer 15

আপনি যে নির্দিষ্ট উদাহরণ দিয়েছেন, তা তা করে does

• এটি কোনও ত্রুটি নয় তা নিশ্চিত করার জন্য এটি একটি পর্যালোচককে কোডটি আবার পড়তে বাধ্য করে।
• এটি (অপ্রয়োজনীয়) সাইক্লোমেটিক জটিলতা যুক্ত করে কারণ এটি প্রবাহের গ্রাফটিতে একটি নোড যুক্ত করে।

আমি মনে করি এটি এর চেয়ে সহজতর কোনও হতে পারে না:

bool CanLeaveWithoutUmbrella()
{
    return (sky.Color == Color.Blue);
}

Comments

আমি বিশেষত সত্যটি সম্বোধন করেছি এই খুব সরলীকৃত উদাহরণটিif বিবৃতিটি সরাতে পুনরায় লেখা যেতে পারে । বাস্তবে আমি আপনার সঠিক কোডটি ব্যবহার করে আরও সরলীকরণকে স্পষ্টভাবে নিরুৎসাহিত করি। অতিরিক্তভাবে সাইক্লোমেটিক জটিলতা elseব্লক দ্বারা বাড়ানো হয় না ।

— সিলালী অ্যাডোবর

Answer 16

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

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool CanLeaveWithoutUmbrella()
    {
        if(this.color == Color.Blue)
        {
            return true;
        }
        else
        {
            return false;
        }
    }
}

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

প্রথমত, elseশাখা সম্পর্কে আপনার প্রশ্ন আছে । আমি কোনওভাবেই আপত্তি করি না, তবে এটিকে ছেড়ে যেতে ঝোঁক else। আমি সুস্পষ্ট হওয়ার বিষয়ে যুক্তিটি বুঝতে পারি, তবে আমার অভিমত হল যে ifবিবৃতিগুলির মতো 'alচ্ছিক' শাখা মোড়ানো উচিত return true। আমি return falseশাখাটিকে 'alচ্ছিক' বলব না , কারণ এটি আমাদের ডিফল্ট হিসাবে কাজ করে acting যেভাবেই হোক না কেন, আমি এটিকে একটি অতি সামান্য সমস্যা হিসাবে দেখছি এবং নিম্নলিখিত বিষয়গুলির চেয়ে অনেক কম গুরুত্বপূর্ণ:

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool CanLeaveWithoutUmbrella()
    {
        if(this.color == Color.Blue)
        {
            return true;
        }
        return false;
    }
}

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

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool CanLeaveWithoutUmbrella()
    {
        return (this.color == Color.Blue)
            ? true
            : false;
    }
}

এখন আমরা আমাদের ফলাফলের সাথে সাদৃশ্যপূর্ণ অপ্রয়োজনে পৌঁছেছি this.color == Color.Blue। আমি জানি আপনার প্রশ্নটি আমাদের এটিকে উপেক্ষা করতে বলেছে, তবে আমি মনে করি এটি অত্যন্ত গুরুত্বপূর্ণ যে এটি একটি খুব প্রথম-ক্রম, চিন্তার পদ্ধতিগত পদ্ধতি: আপনি ইনপুট মানগুলি ভেঙে ফেলছেন এবং কিছু আউটপুট মান তৈরি করছেন। এটি ঠিক আছে, তবে সম্ভব হলে ইনপুট এবং আউটপুটের মধ্যে সম্পর্ক বা রূপান্তরগুলির ক্ষেত্রে বিবেচনা করা আরও বেশি শক্তিশালী । এক্ষেত্রে সম্পর্কটি অবশ্যই স্পষ্টত যে তারা একই রকম তবে আমি প্রায়শই এর মতো সংশ্লেষিত পদ্ধতিগত কোড দেখতে পাই যা কিছু সাধারণ সম্পর্ককে অস্পষ্ট করে। আসুন এগিয়ে যান এবং এই সরলীকরণ করুন:

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool CanLeaveWithoutUmbrella()
    {
        return (this.color == Color.Blue);
    }
}

আমি বাতলান চাই পরবর্তী জিনিস আপনার এপিআই একটি ডবল-নেগেটিভ রয়েছে: এটা জন্য সম্ভব CanLeaveWithoutUmbrellaহতে false। এটি অবশ্যই NeedUmbrellaসত্ত্বাকে সহজ করে তোলে trueতাই আসুন এটি করা যাক:

class Sky {
    Sky(Colour c)
    {
        this.color = c;
    }
    bool NeedUmbrella()
    {
        return (this.color != Color.Blue);
    }
}

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

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

class Sky {
    bool NeedUmbrella()
    {
        return true;
    }
}

class BlueSky extends Sky {
    bool NeedUmbrella()
    {
        return false;
    }
}

নোট করুন যে ক্রিয়াকলাপের প্রোগ্রামিংয়ে এক্সপ্রেশনগুলির মধ্যে শাখায় টার্নারি অপারেটর ব্যবহার করা সাধারণ ।

Comments

উত্তরের প্রথম অনুচ্ছেদটি প্রশ্নের উত্তর দেওয়ার পথে রয়েছে বলে মনে হচ্ছে তবে এটি তাত্ক্ষণিকভাবে সঠিক বিষয়টির দিকে সরিয়ে নিয়ে গেছে আমি খুব স্পষ্টভাবে উদাহরণের জন্য একজনকে উপেক্ষা করার জন্য স্পষ্টভাবে বলতে চাই । প্রশ্ন থেকে: I ask that you ignore the many other ways the function can be written, and changes that can be made to it. (I know most people are itching to write return sky.Color == Color.Blue.)। আসলে আপনি উল্লিখিত কোডের সঠিক লাইনটি ব্যবহার করেন। অধিকন্তু, প্রশ্নের এই অংশটি বিষয়বস্তু না থাকাকালীন আমি বলব যে আপনি নিজের অনুমানের দিক থেকে অনেক দূরে চলে যাচ্ছেন। কোডটি কী তা আপনি আমূল পরিবর্তন করেছেন।

— সিলালি অ্যাডোবর

@ অ্যাসোর্টড ট্রাইলিক্স এটি খাঁটি শৈলীর প্রশ্ন। এটি শৈলী সম্পর্কে যত্নবান হওয়ার অর্থবোধ করে এবং এটিকে এড়িয়ে চলা বোঝাপড়া করে (কেবলমাত্র ফলাফলের উপর দৃষ্টি নিবদ্ধ করে)। আমি মনে করি না এটা সম্পর্কে যত্ন জ্ঞান করে তোলে return false;বনাম else { return false; }থাকাকালীন না শাখা প্রান্তিকতা, ডায়নামিক প্রেরণ, ternaries, ইত্যাদি বিষয়ে চিন্তা আপনি একটি OO যেমন পণ্য ভাষায় পদ্ধতিগত কোড লেখা থাকেন, আমূল পরিবর্তন প্রয়োজন;)

— Warbo

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

— সিলালী অ্যাডোবর

আমি কখনই বলিনি যে ওও সমাধানটি আরও ভাল (আসলে আমি কার্যকরী প্রোগ্রামিং পছন্দ করি), আমি কেবল বলেছি এটি ভাষার সাথে আরও সুসংগত it's "ধনাত্মকতা" দ্বারা আমি বোঝাতে চেয়েছি কোনটি জিনিস "সত্য" এবং কোনটি "মিথ্যা" (আমি এটি "নিডবম্ব্রেলা" দিয়ে স্যুইচ করেছি)। ওও ডিজাইনে, সমস্ত নিয়ন্ত্রণ প্রবাহ গতিশীল প্রেরণের দ্বারা নির্ধারিত হয়। উদাহরণস্বরূপ, স্মলটক অন্য কিছু অনুমতি দেয় না en.wikipedia.org/wiki/Smalltalk#Control_structures (এছাড়াও দেখুন c2.com/cgi/wiki?HeInventedTheTerm )

— Warbo

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

— zwol