শর্ট সার্কিট মূল্যায়ন, এটা কি খারাপ অভ্যাস?

Question

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

if (smartphone != null && smartphone.GetSignal() > 50)
{
   // Do stuff
}

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

এটি অন্যান্য পরিস্থিতিতেও কার্যকর হতে পারে যেমন একটি সূচকের বিন্যাসের সীমানা রয়েছে কিনা তা পরীক্ষা করা এবং এই জাতীয় কৌশলটি বিভিন্ন ভাষায় করা যেতে পারে, আমার জ্ঞান অনুসারে: জাভা, সি #, সি ++, পাইথন এবং মতলব।

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

Comments

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

— Kilian Foth

বেশিরভাগ ভাষাগুলি আপনাকে কী আচরণ চান তা চয়ন করতে দেয়। সি # অপারেটর ||শর্ট সার্কিটগুলিতে অপারেটর |(একক পাইপ) ( &&এবং &একই আচরণ করে ) করে না । যেহেতু শর্ট সার্কিট অপারেটরগুলি বেশি ঘন ঘন ব্যবহৃত হয়, আমি আপনাকে কেন তাদের আচরণের প্রয়োজন তা বোঝাতে একটি মন্তব্য দিয়ে নন-শর্ট সার্কিটের ব্যবহারগুলি চিহ্নিত করার পরামর্শ দিই (বেশিরভাগ পদ্ধতি যেমন পদ্ধতিতে অনুরোধ করা হয় যা সব ঘটতে হবে)।

— লিনাক 20'15

@ লিনাক এখন ডানদিকে কিছু রেখে &বা |পার্শ্ব-প্রতিক্রিয়া ঘটে তা নিশ্চিত করার জন্য আমি অবশ্যই বলি খারাপ অভ্যাস: এই পদ্ধতি কলটি তার নিজের লাইনে লাগাতে আপনার কোনও ব্যয় হবে না।

— জন হান্না

@ লিনাক: সি এবং সি ++ &&এ শর্ট সার্কিট এবং &এটি নয়, তবে তারা খুব আলাদা অপারেটর। &&একটি যৌক্তিক "এবং"; &কিছুটা দিক "এবং"। মিথ্যা x && yহলেও সত্য হওয়া সম্ভব x & y।

— কিথ থম্পসন

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

— Random832

Answer 1

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

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

কিছুটা সতর্কতা:

জটিলতা এবং পাঠযোগ্যতার বিষয়ে সাধারণ জ্ঞান ব্যবহার করুন

নিম্নলিখিতটি এত ভাল ধারণা নয়:

if ((text_string != null && replace(text_string,"$")) || (text_string = get_new_string()) != null)

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

আপনার যদি ত্রুটিগুলি পরিচালনা করতে হয় তবে প্রায়শই আরও ভাল উপায় থাকে

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

একই অবস্থার বারবার চেক এড়িয়ে চলুন

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

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

Comments

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

— নীল

@ নীল, ভাল পয়েন্ট; আমি উত্তর আপডেট।

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

— ব্রায়ান

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

— অ্যারোনএলএস

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

Answer 2

ধরা যাক আপনি কোনও সি-স্টাইলের ভাষা ব্যবহার করছেন &&এবং আপনার প্রশ্নের মতো সমান কোডটি করার প্রয়োজন ছিল।

আপনার কোডটি হবে:

if(smartphone != null)
{
  if(smartphone.GetSignal() > 50)
  {
    // Do stuff
  }
}

এই প্যাটার্নটি অনেক বেশি পরিণত হবে।

এখন আমাদের অনুমানমূলক ভাষার পরিচয় 2.0 এর সংস্করণটি কল্পনা করুন &&। আপনি কতটা শীতল মনে করেন তা ভাবুন!

&&উপরোক্ত আমার উদাহরণটি যা করে তা করার স্বীকৃত, মুশকিল উপায়। এটি ব্যবহার করা খারাপ অভ্যাস নয়, এটি উপরের মতো ক্ষেত্রে এটি ব্যবহার না করা খারাপ অভ্যাস: এই জাতীয় ভাষার অভিজ্ঞ অভিজ্ঞ কোডার ভাবছেন elseযে স্বাভাবিক ফ্যাশনে জিনিস না করার কারণটি বা অন্য কারণটি ছিল।

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

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

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

বিবেচনা:

if(smartphone != null && smartphone.GetSignal() > ((range = (range != null ? range : GetRange()) != null && range.Valid ? range.MinSignal : 50)

এটি চেক করার জন্য আপনার কোডটি প্রসারিত করে range। যদি এটি rangeনাল হয় তবে এটি একটি কল দিয়ে সেট করার চেষ্টা করে GetRange()যদিও এটি ব্যর্থ rangeহতে পারে তবে এখনও শূন্য হতে পারে। যদি এর পরে যদি পরিসীমাটি শূন্য না হয়, এবং এটি হয় Validতবে এর MinSignalসম্পত্তিটি ব্যবহৃত হয়, অন্যথায় একটি ডিফল্ট 50ব্যবহৃত হয়।

&&এটিও নির্ভর করে , তবে এটি একটি লাইনে রেখে দেওয়া সম্ভবত খুব চালাক (আমি এটি সঠিক বলে 100% নিশ্চিত নই, এবং আমি ডাবল-চেক করতে যাচ্ছি না কারণ এই সত্যটি আমার বক্তব্যটি দেখায়)।

এটা না &&যে সমস্যা এখানে যদিও, কিন্তু এক অভিব্যক্তি অনেক করা করার জন্য এটি ব্যবহার করার ক্ষমতা (একটি ভাল জিনিস) আমাদের অকারণে (একটি খারাপ জিনিস) এক ধরনের হার্ড-টু-বুঝতে এক্সপ্রেশন লেখার ক্ষমতা বৃদ্ধি পায়।

এছাড়াও:

if(smartphone != null && (smartphone.GetSignal() == 2 || smartphone.GetSignal() == 5 || smartphone.GetSignal() == 8 || smartPhone.GetSignal() == 34))
{
  // do something
}

এখানে আমি &&নির্দিষ্ট মানগুলির জন্য একটি চেক ব্যবহারের সাথে একত্রিত করছি । এটি ফোন সিগন্যালের ক্ষেত্রে বাস্তবসম্মত নয়, তবে অন্যান্য ক্ষেত্রেও আসে। এখানে, এটি আমার যথেষ্ট চালাক না হওয়ার একটি উদাহরণ। যদি আমি নিম্নলিখিতটি করতাম:

if(smartphone != null)
{
  switch (smartphone.GetSignal())
  {
    case 2: case 5: case 8: case 34:
      // Do something
      break;
  }
}

আমি পঠনযোগ্যতা এবং সম্ভবত পারফরম্যান্স উভয়ই অর্জন করতে পেরেছি (একাধিক কল GetSignal()সম্ভবত অপ্টিমাইজড না হত)।

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

একটি চূড়ান্ত কেস যা সেরা অনুশীলন থেকে সরে যায়:

if(a && b)
{
  //do something
}

তুলনা করা:

if(a & b)
{
  //do something
}

আমরা কেন পরবর্তীকালের পক্ষে হতে পারি, তার সর্বোত্তম যুক্তি হ'ল মূল্যায়ন করার ক্ষেত্রে কিছুটা পার্শ্ব-প্রতিক্রিয়া রয়েছে bযা আমরা aসত্য বা না তা চাই । আমি এতে একমত নই: যদি সেই পার্শ্ব-প্রতিক্রিয়াটি এত গুরুত্বপূর্ণ হয়, তবে কোডের একটি পৃথক লাইনে এটি ঘটান।

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

প্রথমটির অবশ্য আরও একটি শাখা রয়েছে। যদি আমরা আমাদের অনুমান সি-স্টাইলের ভাষায় এটির সাথে আবার লিখি তবে বিবেচনা করুন &&:

if(a)
{
  if(b)
  {
    // Do something
  }
}

এই অতিরিক্ত ifআমাদের ব্যবহারের মধ্যে লুকানো আছে &&, কিন্তু এটি এখনও আছে। এবং এর মতো এটি এমন একটি ক্ষেত্রে যেখানে শাখার পূর্বাভাস ঘটে চলেছে এবং সম্ভাব্যত তাই শাখার ভুল পূর্বাভাস।

যে কারণে if(a & b)কিছু ক্ষেত্রে কোড আরও কার্যকর হতে পারে।

এখানে আমি বলতে চাই যে if(a && b)এটি এখনও শুরু করার সবচেয়ে ভাল অনুশীলন পদ্ধতির: আরও সাধারণ, কিছু ক্ষেত্রে একমাত্র কার্যকর (যেখানে মিথ্যা bহলে ত্রুটি ঘটবে a) এবং প্রায়শই দ্রুত হয় না। এটি লক্ষণীয় যে if(a & b)এটি নির্দিষ্ট ক্ষেত্রে যদিও এটির জন্য প্রায়শই একটি দরকারী অপ্টিমাইজেশন।

Comments

সাফল্যের ক্ষেত্রে যদি এমন একটি tryপদ্ধতি ফিরে আসে তবে trueআপনি কী ভাবেন if (TryThis || TryThat) { success } else { failure }? এটি কম কমন আইডিয়াম, তবে কোড নকল বা পতাকা যুক্ত না করে কীভাবে একই জিনিসটি সম্পন্ন করতে হয় তা আমি জানি না। একটি পতাকার জন্য প্রয়োজনীয় মেমরিটি একটি অ-ইস্যু হতে পারে, বিশ্লেষণের দিক থেকে, পতাকা যুক্ত করে কার্যকরভাবে দুটি সমান্তরাল মহাবিশ্বে কোড বিভক্ত হয় - একটি পতাকাটি trueযখন পৌঁছায় তখন পৌঁছতে পারে এমন একটি বিবৃতি থাকে এবং অন্যটি যখন বিবৃতিতে পৌঁছায় তখন false। কখনও কখনও একটি DRY দৃষ্টিকোণ থেকে ভাল, কিন্তু আইকি।

— সুপারক্যাট 20'15

আমি কিছুই ভুল দেখছি না if(TryThis || TryThat)।

— জন হানা

জঘন্য উত্তর, স্যার।

— বিশপ

FWIW, Kernighan, Plauger & পাইক বেল ল্যাবস থেকে সহ চমৎকার প্রোগ্রামারদের স্বচ্ছতার স্বার্থে মত অগভীর নিয়ন্ত্রণ কাঠামো ব্যবহার করার জন্য সুপারিশ if {} else if {} else if {} else {}মত নেস্টেড নিয়ন্ত্রণ কাঠামো বদলে if { if {} else {} } else {}, এমনকি যদি এটি একই অভিব্যক্তি একাধিকবার মূল্যায়নের মানে। লিনাস টোরভাল্ডস অনুরূপ কিছু বলেছিলেন: "আপনার যদি 3 স্তরের বেশি ইন্ডেন্টেশন প্রয়োজন হয় তবে আপনি যেভাবেই ত্রুটিযুক্ত" " শর্ট সার্কিট অপারেটরদের ভোট হিসাবে এটি গ্রহণ করা যাক।

— স্যাম ওয়াটকিন্স

যদি (একটি & বি) বিবৃতি; প্রতিস্থাপন করা যুক্তিসঙ্গতভাবে সহজ। যদি (একটি এবং বি এবং & সি এবং& ডি) বিবৃতি 1; অন্য বিবৃতি 2; একটি বাস্তব ব্যথা।

— gnasher729

Answer 3

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

open($handle, "<", "filename.txt") or die "Couldn't open file!";

মূর্তিমান। openসাফল্যের জন্য কিছু ননজারো ফিরিয়ে দেয় (যাতে dieঅংশটি orকখনই ঘটে না), তবে ব্যর্থতার উপর অপরিবর্তিত, এবং তারপরে কলটি dieঘটবে (এটি পার্লের ব্যতিক্রম উত্থাপনের উপায়)।

যে ভাষাগুলিতে সবাই এটি করে সেখানে এটি ঠিক।

Comments

ভাষা নকশায় পার্লের সর্বাধিক অবদান এটি কীভাবে করবেন না তার একাধিক উদাহরণ সরবরাহ করা।

— জ্যাক এইডলি 20'15

@ জ্যাকএইডলি: আমি পার্ল unlessএবং পোস্টফিক্স শর্তাবলীর ( send_mail($address) if defined $address) যদিও মিস করছি ।

— রিমকো গ্রিলিচ

@ জ্যাকএইডলি আপনি কীভাবে 'বা মারা' খারাপ বলে একটি নির্দেশক সরবরাহ করতে পারেন? এটি কি ব্যতিক্রমগুলি পরিচালনা করার একটি নিষ্পাপ উপায়?

— বিগস্টোন

পার্লে প্রচুর ভয়ঙ্কর কাজ করা সম্ভব তবে এই উদাহরণটি সহ আমি সমস্যাটি দেখতে ব্যর্থ হয়েছি। এটি সহজ, সংক্ষিপ্ত এবং স্পষ্ট - একটি স্ক্রিপ্টিং ভাষায় ত্রুটি পরিচালনা করতে আপনার ঠিক কী চান should

@ রেমকো গ্রিলিচ রুবি সেই শৈলীর কিছু উত্তরাধিকার সূত্রে পেয়েছেন:send_mail(address) if address

— -153 এ বোনহ

Answer 4

যদিও আমি সাধারণত ড্যান 1111 এর উত্তরের সাথে একমত, এটির মধ্যে একটি বিশেষ গুরুত্বপূর্ণ বিষয় রয়েছে যা এটি আবৃত করে না: সেই ক্ষেত্রে যেখানে smartphoneএকই সাথে ব্যবহৃত হয়। সেই দৃশ্যে, এই ধরণের প্যাটার্নগুলি বাগগুলি খুঁজে পাওয়া শক্তির একটি সুপরিচিত উত্স।

সমস্যাটি হ'ল শর্ট সার্কিট মূল্যায়ন পারমাণবিক নয়। তোমার থ্রেড পরীক্ষা করতে পারবেন যে smartphoneহয় null, অন্য থ্রেড আসতে পারেন এবং এটি খর্ব, এবং তারপর আপনার থ্রেড অবিলম্বে করার চেষ্টা করে GetSignal()এবং আপ মারতে লাগল।

তবে অবশ্যই, এটি শুধুমাত্র করেন যে, যখন বড় সারিবদ্ধ এবং আপনার থ্রেড 'সময়জ্ঞান হয় মাত্র ঠিক আছে।

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

Answer 5

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

সুতরাং লজিক্যাল এক্সপ্রেশনগুলির গ্যারান্টিযুক্ত শর্ট সার্কিট মূল্যায়নের জন্য একটি বিশাল প্রয়োজন ছিল। এটি পাস্কলে উপস্থিত ছিল না (যার গ্যারান্টিযুক্ত শর্ট সার্কিট মূল্যায়ন ছিল) যা একটি বড় ব্যথা ছিল; এটি আমি প্রথম অ্যাডা এবং সিতে দেখেছি

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

Comments

"এটি পুনর্লিখন করুন যাতে এটি শর্ট সার্কিট মূল্যায়ন ব্যতীত সূক্ষ্মভাবে কাজ করবে এবং ফিরে এসে আপনি কীভাবে পছন্দ করেছেন তা আমাদের জানান।" - হ্যাঁ, এটি পাস্কালের স্মৃতি ফিরিয়ে এনেছে। এবং না, আমি এটি পছন্দ করি না।

— টমাস প্যাড্রন-ম্যাকার্থি

Answer 6

অন্যান্য বিবেচনায় উল্লিখিত না হওয়া একটি বিবেচনা: কখনও কখনও এই চেকগুলি নাল অবজেক্ট ডিজাইনের প্যাটার্নকে একটি সম্ভাব্য রিফ্যাক্টরিংয়ে ইঙ্গিত করতে পারে । উদাহরণ স্বরূপ:

if (currentUser && currentUser.isAdministrator()) 
  doSomething();

সহজ হতে সহজ হতে পারে:

if (currentUser.isAdministrator())
  doSomething ();

যদি currentUserকোনও 'বেনাম ব্যবহারকারী' বা 'নাল ব্যবহারকারীর' কাছে ফ্যালব্যাক প্রয়োগের সাথে ডিফল্ট হয় যদি ব্যবহারকারী লগ ইন না করে থাকে।

না সবসময় একটি কোড গন্ধ, কিন্তু কিছু বিবেচনা করতে হবে।

Answer 7

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

অর্থাত

 if(quickLogicA && slowLogicB) {doSomething();}

ভাল, কিন্তু

if(logicA && doSomething()) {andAlsoDoSomethingElse();}

খারাপ, এবং অবশ্যই কারও সাথে একমত হবে না ?!

if(doSomething() || somethingElseIfItFailed() && anotherThingIfEitherWorked() & andAlwaysThisThing())
{/* do nothing */}

যুক্তি:

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

কারণ 1. orতিহাসিক

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

যদিও সি # তে ভাষা নির্দিষ্টকরণ বুলিয়ান গ্যারান্টি দেয় 'এবং' অপারেটর শর্ট সার্কিট করে। এটি সমস্ত ভাষা এবং সংকলকগুলির ক্ষেত্রে সত্য নয়।

উইকিপিডায় বিভিন্ন ভাষাগুলির তালিকা রয়েছে এবং তাদের শর্ট সার্কিট http://en.wikedia.org/wiki/Short-circuit_e মূল্যায়ন হিসাবে আপনি নিতে পারেন অনেকগুলি পদ্ধতির তালিকা করে। এবং বেশ কয়েকটি অতিরিক্ত সমস্যা আমি এখানে প্রবেশ করি না।

বিশেষত, ফরট্রান, পাস্কেল এবং ডেলফির সংকলক পতাকা রয়েছে যা এই আচরণটি টগল করে।

অতএব: আপনি মুক্তির জন্য সংকলিত হওয়ার সময় কোডটি কাজ করতে পারেন তবে ডিবাগ বা বিকল্প সংকলক ইত্যাদির সাথে নয় etc.

কারণ 2. ভাষার পার্থক্য

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

বিশেষত ভিবি.নেটের 'এবং' অপারেটরের শর্ট সার্কিট হয় না এবং টিএসকিউএল কিছু বিশেষত্ব রয়েছে।

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

কারণ ৩. কোনও ভাষার মধ্যে পার্থক্য

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

কারণ ৪. কোনও ফাংশনের প্যারামিটারটি পরীক্ষা করা আপনার নালীর নির্দিষ্ট উদাহরণ

এটি একটি খুব ভাল উদাহরণ। এতে এটি প্রত্যেকেরই কিছু হয় তবে আপনি যখন এটি সম্পর্কে চিন্তা করেন তখন এটি আসলে খারাপ অভ্যাস।

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

তবে এটি একাধিক কারণে সেরা অনুশীলনে ব্যর্থ হয়!

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

   if (smartphone == null)
   {
       //throw an exception
   }
   // perform functionality

2. আপনি এর থেকে একটি ফাংশন আহ্বান করা হয় মধ্যে শর্তসাপেক্ষ বিবৃতি। যদিও আপনার ফাংশনের নামটি বোঝায় যে এটি কেবল একটি মান গণনা করে, এটি পার্শ্ব প্রতিক্রিয়াগুলি আড়াল করতে পারে। যেমন

   Smartphone.GetSignal() { this.signal++; return this.signal; }
   
   else if (smartphone.GetSignal() < 1)
   {
       // Do stuff 
   }
   else if (smartphone.GetSignal() < 2)
   {
       // Do stuff 
   }

   সেরা অনুশীলন পরামর্শ দেবে:

   var s = smartphone.GetSignal();
   if(s < 50)
   {
       //do something
   }

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

আমি মনে করি আপনি দেখতে পাবেন এটি অন্যান্য সাধারণ ব্যবহারের ক্ষেত্রেও এটি। আপনার মনে রাখতে হবে আমাদেরও রয়েছে:

ইনলাইন শর্তাদি

var s = smartphone!=null ? smartphone.GetSignal() : 0;

এবং নাল coalescence

var s = smartphoneConnectionStatus ?? "No Connection";

যা আরও স্পষ্টতার সাথে একই সংক্ষিপ্ত কোড দৈর্ঘ্যের কার্যকারিতা সরবরাহ করে

আমার সমস্ত পয়েন্ট সমর্থন করার জন্য অসংখ্য লিঙ্ক:

https://stackoverflow.com/questions/1158614/what-is-the-best-practice-in-case-one-argument-is-null

সি # তে কনস্ট্রাক্টর প্যারামিটারের বৈধতা - সেরা অনুশীলন

যদি নাল প্রত্যাশা না করে তবে কি নাল পরীক্ষা করা উচিত?

https://msdn.microsoft.com/en-us/library/seyhszts%28v=vs.110%29.aspx

https://stackoverflow.com/questions/1445867/why-would-a-language-not-use-short-circuit-evaluation

http://orcharddojo.net/orchard-resources/Library/DevelopmentGuidelines/BestPractices/CSharp

সংক্ষিপ্ত সার্কিটকে প্রভাবিত করে সংকলক পতাকাগুলির উদাহরণ:

ফরট্রান: "দর্শন | nosce ডিফল্টরূপে, সংকলক এক্সএল ফোর্টরান বিধিগুলি ব্যবহার করে নির্বাচিত যৌক্তিক অভিব্যক্তিগুলিতে শর্ট সার্কিট মূল্যায়ন করে। "ডিফল্টটি নাক ডাকা হয়।"

পাস্কাল: "বি - শর্ট সার্কিট মূল্যায়ন নিয়ন্ত্রণকারী একটি পতাকা নির্দেশনা short ব্যবহারকারীর ম্যানুয়ালে নথিভুক্ত) "।

ডেলফি: "ডেল্ফি ডিফল্টরূপে শর্ট সার্কিট মূল্যায়ন সমর্থন করে It OO OO $ বুলিভাল অফ} সংকলক নির্দেশিকা ব্যবহার করে এটি বন্ধ করা যেতে পারে।"

Comments

মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।

— বিশ্ব প্রকৌশলী