যদি-অন্য সিঁড়িটি যা সমস্ত শর্তটি ধরার কথা বলে - তবে কি একটি অতিরিক্ত বাজে চূড়ান্ত ধারা যুক্ত করা উচিত?

Question

এটি এমন একটি জিনিস যা আমি ইদানীং অনেক করছি।

উদাহরণ:

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else if (i > current) {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }
}

প্রায়শই যদি / অন্য মই এর চেয়ে উল্লেখযোগ্যভাবে জটিল হয় ...

চূড়ান্ত ধারাটি দেখুন? এটা নিরর্থক। মই চূড়ান্তভাবে সমস্ত সম্ভাব্য শর্তটি ধরার কথা। সুতরাং এটি এটি আবার লিখতে পারে:

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }
}

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

যাহোক:

• সুস্পষ্টভাবে চূড়ান্ত অবসন্ন অবস্থা লিখতে আমার নিজের ধারণা এবং আমার নিজের ধারণাগুলি নিয়ে খারাপ অভিজ্ঞতা হয় - সাধারণত লোকেরা আমাকে চিত্কার করে যে আমি কী বীভৎস করছি - এবং (কখনও কখনও অনেক পরে) আমি জানতে পারি যে এটি আসলেই ছিল দরুণ পর্যাপ্ত;
• এটি কেন একটি খারাপ ধারণা হতে পারে তার একটি ইঙ্গিত: জাভাস্ক্রিপ্টের জন্য প্রযোজ্য নয়, তবে অন্যান্য ভাষায়, সংকলকরা ফাংশনটির শেষে পৌঁছানোর বিষয়ে নিয়ন্ত্রণ বা সতর্কতা বা ত্রুটি প্রদান করার ঝোঁক রাখে। এরকম কিছু করার ইঙ্গিত দেওয়া খুব জনপ্রিয় নাও হতে পারে বা আমি এটি ভুল করে চলেছি।
  • সংকলক অভিযোগগুলি আমাকে মাঝে মধ্যে একটি মন্তব্যে চূড়ান্ত শর্তটি লিখতে বাধ্য করে, তবে আমার ধারণা যে কোডগুলি করা নয়, মন্তব্যগুলির মত, মন্তব্যগুলি প্রকৃত প্রোগ্রামের শব্দার্থবিজ্ঞানের উপর কোনও প্রভাব ফেলেনি since

    } else { // i > current
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }

আমি কিছু অনুপস্থিত করছি? অথবা আমি যা বর্ণনা করেছি তা করা ঠিক আছে বা এটি একটি খারাপ ধারণা?

Comments

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

— এরিক tদ

@ এরিক এডিট> যেহেতু এর থেকে বলা হয়েছে যে আপনি একটি ফাংশন থেকে ফিরে আসছেন না বা লুপ থেকে "ব্রেকিং" না করলে (যা উপরের উদাহরণে তেমন নয়) যদি না হয় তবে এক সাথে +1 ম্যাচের পরেও সমস্ত অবস্থার মূল্যায়ন করা উচিত।

— দারেক নডজা

+1, দুর্দান্ত প্রশ্ন। একদিকে যেমন এটি আপনার আগ্রহী হতে পারে যে NaN- এর উপস্থিতিতে উদাহরণটি পরিপূর্ণ নয়।

— মনোকেল

Answer 1

উভয় পদ্ধতির বৈধ। তবে আসুন আমাদের ভাল এবং বিপরীতে ঘনিষ্ঠভাবে নজর দেওয়া যাক।

ifএখানে মত তুচ্ছ পরিস্থিতি সঙ্গে একটি চেইনের জন্য , এটি আসলে কিছু যায় আসে না:

• চূড়ান্তভাবে else, অন্যটি কোন অবস্থায় ট্রিগার হয়েছে তা পাঠকের পক্ষে খুঁজে পাওয়া সুস্পষ্ট;
• চূড়ান্ত সাথে else if, এটি পাঠকের পক্ষেও স্পষ্ট যে elseআপনি সমস্ত কিছু covered েকে রাখার পরে কোনও অতিরিক্ত প্রয়োজন নেই ।

তবে, প্রচুর ifশৃঙ্খলা রয়েছে যা আরও জটিল অবস্থার উপর নির্ভর করে, বেশ কয়েকটি ভেরিয়েবলের রাজ্যগুলির সংমিশ্রণ করে, সম্ভবত একটি জটিল যৌক্তিক প্রকাশের সাথে। এই ক্ষেত্রে এটি কম সুস্পষ্ট। এবং এখানে প্রতিটি শৈলীর ফলাফল:

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

সুতরাং চূড়ান্ত অনর্থক অবস্থা ঝুঁকির একটি উত্স। এজন্য আমি বরং ফাইনালে যাওয়ার পরামর্শ দিই else।

সম্পাদনা করুন: উচ্চ নির্ভরযোগ্যতা কোডিং

আপনি যদি উচ্চ নির্ভরযোগ্যতার কথা মাথায় রেখে বিকাশ করছেন, তবে আপনি অন্য কোনও রূপে আগ্রহী হতে পারেন: কোনও অপ্রত্যাশিত পরিস্থিতি ধরতে আপনার ফাইনালকে ফাইনালের else ifসাথে সম্পূর্ণ করতে হবে redelse

এটি ডিফেন্সিভ কোডিং। এটি SEI CERT বা MISRA এর মতো কিছু সুরক্ষা বিবরণ দ্বারা সুপারিশ করা হয়েছে । কিছু স্থির বিশ্লেষণ সরঞ্জাম এমনকি এটিকে নিয়ম হিসাবে পরীক্ষা করা নিয়ম হিসাবে প্রয়োগ করে (এটি আপনার সংকলক সতর্কবার্তা ব্যাখ্যা করতে পারে)।

Comments

চূড়ান্ত পুনর্বাসন শর্তের পরে যদি আমি অন্য একটি যুক্ত করি যা সর্বদা একটি ব্যতিক্রম ছুঁড়ে দেয় যা বলে যে "আপনার আমার কাছে পৌঁছানোর কথা ছিল না!" - এটি কি আমার পদ্ধতির কিছু সমস্যা উপশম করবে?

— গাজকাম

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

— ক্রিস্টোফ

@gaazkam আমি আমার উত্তর সম্পাদনা করেছি আপনার মন্তব্যে উল্লিখিত অতিরিক্ত ধারণাটিও সম্বোধন করার জন্য

— ক্রিস্টোফ

@ গাজকাম একটি ব্যতিক্রম ছুঁড়ে দেওয়া ভাল। যদি আপনি তা করেন তবে বার্তায় অপ্রত্যাশিত মান অন্তর্ভুক্ত করতে ভুলবেন না। এটি পুনরুত্পাদন করা শক্ত হতে পারে এবং অপ্রত্যাশিত মান সমস্যার উত্স সম্পর্কে একটি সূত্র সরবরাহ করতে পারে।

— মার্টিন মাট

আরেকটি বিকল্প হ'ল assertফাইনালে নামা else if। আপনার শৈলীর নির্দেশিকা যদিও এটি একটি ভাল আইডিয়া হয় তার উপর ভিন্ন হতে পারে। ( assertপ্রোগ্রামারটি ভুল না হলে একটিের অবস্থা কখনই মিথ্যা হওয়া উচিত নয় So সুতরাং এটি অন্ততপক্ষে তার উদ্দেশ্যযুক্ত উদ্দেশ্যে বৈশিষ্ট্যটি ব্যবহার করছে But তবে এত লোক এটির অপব্যবহার করে যে প্রচুর দোকান একেবারেই নিষিদ্ধ করেছে))

— কেভিন

Answer 2

কোন উত্তর যা এখন পর্যন্ত উত্তর থেকে অনুপস্থিত তা হ'ল কোন ধরণের ব্যর্থতা কম ক্ষতিকারক।

যদি আপনার যুক্তিটি ভাল হয় তবে আপনি যা করেন তা আসলেই গুরুত্বপূর্ণ নয়, গুরুত্বপূর্ণ সমস্যাটি হ'ল আপনার যদি বাগ থাকে তবে কী হয়।

আপনি চূড়ান্ত শর্ত সাপেক্ষে বাদ দিন: চূড়ান্ত বিকল্পটি কার্যকর করা যদি এটি করা ঠিক না হয় তবে তা কার্যকর করে।

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

আপনি চূড়ান্ত শর্তযুক্ত এবং একটি ব্যতিক্রম যুক্ত করুন: এটি ছুড়ে দেয়।

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

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

Answer 3

আমি যা প্রস্তাব দিচ্ছি তা হ'ল assertএই দুটি স্টাইলের যে কোনও একটিতে আপনার চূড়ান্ত কোনও বিবৃতিটি ব্যবহার করা :

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else {
        assert i > current
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }
}

বা একটি ডেড কোড দাবি:

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else if (i > current) {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    } else {
        assert False, "Unreachable code"
    }
}

কোড কভারেজ সরঞ্জামটি প্রায়শই কভারেজ রিপোর্ট থেকে "মিথ্যা দান করুন" এর মতো কোড উপেক্ষা করার জন্য কনফিগার করা যেতে পারে।

---

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

Comments

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

— লরেন পেচটেল

Answer 4

আমি একটি ম্যাক্রো সংজ্ঞায়িত করেছি "দৃserted়" যা একটি শর্তের মূল্যায়ন করে এবং একটি ডিবাগ বিল্ডে ডিবাগারের মধ্যে পড়ে।

সুতরাং আমি যদি তিন শতাংশ শর্তের মধ্যে একটির অবশ্যই সত্য হতে পারি তবে আমি 100 শতাংশ নিশ্চিত, আমি লিখি

If condition 1 ...
Else if condition 2 .,,
Else if asserted (condition3) ...

এটি এটিকে যথেষ্ট স্পষ্ট করে তোলে যে একটি শর্ত সত্য হবে এবং দৃ an়তার জন্য কোনও অতিরিক্ত শাখার প্রয়োজন নেই।

Answer 5

আমি পুরোপুরি অন্য কিছু এড়ানো পরামর্শ দিচ্ছি । ifকোডের ব্লকটি কী পরিচালনা করবে বলে ঘোষণা করার জন্য ব্যবহার করুন এবং ফাংশনটি থেকে বেরিয়ে ব্লকটি শেষ করুন।

কোডে এটি ফলাফল যা খুব স্পষ্ট:

setCircle(circle, i, { current })
{
    if (i == current)
    {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
        return
    }
    if (i < current)
    {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
        return
    }
    if (i > current)
    {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
        return
    }
    throw new Exception("Condition not handled.");
}

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

Comments

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

— gnasher729

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

— জেরি জেরেমিয়া

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

— জন উ

তবে উভয় শৈলীর চক্রবৃত্তীয় জটিলতা অবিকল ঠিক একই নয়? অর্থাত্ শর্তের সংখ্যার সমান

— গজকাম