বাসা বাঁধতে হ্রাস করতে "যদি" বিবৃতিটি উল্টে দিন


272

যখন আমি আমার কোডে রিশার্পার চালাই , উদাহরণস্বরূপ:

    if (some condition)
    {
        Some code...            
    }

রিশার্পার আমাকে উপরের সতর্কতা দিয়েছেন (বাসা বাঁধতে হ্রাস করতে "যদি" বিবৃতিটি উল্টে দিন), এবং নিম্নলিখিত সংশোধনটির পরামর্শ দিয়েছেন:

   if (!some condition) return;
   Some code...

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


1
আমি বিশ্বাস করি যে শুরুতে ব্যতিক্রম যাচাই এবং ফিরে আসা ঠিক আছে, তবে আমি শর্তটি পরিবর্তন করব যাতে আপনি কিছু না (যেমন (কিছুটা শোধ) ফিরে না পেয়ে) সরাসরি ব্যতিক্রমের জন্য পরীক্ষা করছেন।
ব্রুসিয়েটক

36
না, এটি পারফরম্যান্সের জন্য কিছুই করবে না।
শেঠ কার্নেগি

3
আমার পদ্ধতির বদলে যদি খারাপ ডেটা পাস করা হত তবে আমি একটি আর্গুমেন্ট এক্সেপশন নিক্ষেপ করার জন্য প্রলুব্ধ হব।
asawyer

1
@ সাওয়ের হ্যাঁ, দৃ functions় ব্যর্থতা ব্যবহারের বিপরীতে - এমন ফাংশনগুলি সম্পর্কে সম্পূর্ণ পার্শ্ব-আলোচনা রয়েছে যা অযৌক্তিক ইনপুটগুলি খুব ক্ষমা করে দেয়। সলিড কোড লিখে আমার চোখ খুলে গেল। যা ক্ষেত্রে, এই কিছু হবে ASSERT( exampleParam > 0 )
গ্রেগ হেন্ডারশট

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

উত্তর:


296

পদ্ধতির মাঝখানে ফিরে আসা অগত্যা খারাপ নয়। কোডটি পরিষ্কার করার উদ্দেশ্যে যদি এটি পরিষ্কার করে দেয় তবে অবিলম্বে ফিরে আসাই ভাল। উদাহরণ স্বরূপ:

double getPayAmount() {
    double result;
    if (_isDead) result = deadAmount();
    else {
        if (_isSeparated) result = separatedAmount();
        else {
            if (_isRetired) result = retiredAmount();
            else result = normalPayAmount();
        };
    }
     return result;
};

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

double getPayAmount() {
    if (_isDead)      return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired)   return retiredAmount();

    return normalPayAmount();
};   

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


13
এটি সত্যিই চমৎকার উদাহরণ! রিফ্যাক্টর কোডটি কেস স্টেটমেন্টের মতো আরও পড়ে।
অন্যদিকে

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

2
উদাহরণস্বরূপ, এই সরল, আইডি ২ য় উপায়টি ভাল, তবে এটির কারণেই এটি ঘটছে because
অ্যান্ড্রু বুলক

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

@ মার্ক টি ভিজ্যুয়াল স্টুডিওতে সেটিংসটি যাতে সেই কোডটি ভেঙে ফেলা যায় সেগুলিতে সেটিংস রয়েছে।
অ্যারন স্মিথ

333

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

অন্যদিকে, এটি আপনার পদ্ধতির একাধিক প্রস্থান পয়েন্টও তৈরি করে, এমন একটি বিষয় যা অন্য গ্রুপের বিশ্বাস করে যে এটি একটি নো-হ্যাঁ।

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

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


41
একক প্রস্থান পয়েন্ট? কার দরকার?
sq33G

3
@ এসকিউ 33 জি: এসইএসইতে এই প্রশ্নটি (এবং অবশ্যই উত্তরগুলি) দুর্দান্ত। লিঙ্কের জন্য ধন্যবাদ!
জন

আমি উত্তরে শুনতে থাকি যে এমন কিছু লোক আছে যারা একক বহির্গমন পয়েন্টের পক্ষে কথা বলে তবে আমি কখনও কখনও এমন কাউকে বাস্তবে উকিল করতে দেখিনি, বিশেষত সি # এর মতো ভাষায়।
টমাস বনিনি

1
@ আন্দ্রেস বোনিনি: প্রমাণের অনুপস্থিতি অনুপস্থিতির প্রমাণ নয়। :-)
জন

হ্যাঁ, আমি কেবল আশ্চর্যজনকভাবেই অনুভব করি যে প্রত্যেকে বলার প্রয়োজন বোধ করে যে কিছু লোক যদি অন্যরকম পদ্ধতির পছন্দ করে তবে যদি তারা নিজেরাই এটি বলার প্রয়োজন বোধ না করে =)
টমাস বোনিিনি

102

এটি কিছুটা ধর্মীয় যুক্তি, তবে আমি রিশার্পারের সাথে একমত যে আপনার কম বাসা বাঁধাই পছন্দ করা উচিত। আমি বিশ্বাস করি যে এটি কোনও ফাংশন থেকে একাধিক রিটার্ন পাথের নেতিবাচকতা ছাড়িয়ে যায়।

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

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

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

কোনও ফাংশনে একাধিক রিটার্ন পাওয়া রক্ষণাবেক্ষণ প্রোগ্রামারের কাজকে প্রভাবিত করে না।

দরিদ্র কোড পাঠযোগ্যতা।


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

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

3
এখানে জনের সাথে একমত হোন ... পুরো ফাংশনটি সবেমাত্র পদক্ষেপে আমি সমস্যাটি দেখতে পাচ্ছি না।
নাইলার

5
@ নাইলার খুব দেরীতে, আমি বিশেষত একমত, কারণ যদি ফাংশনটি খুব বড় হয়ে যায় তবে এটি কোনওভাবেই একাধিক ফাংশনে বিভক্ত হওয়া উচিত!
এইডিয়াকাপি

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

70

অন্যরা যেমন উল্লেখ করেছে, পারফরম্যান্স হিট হওয়া উচিত নয়, তবে অন্যান্য বিবেচনা রয়েছে। এই বৈধ উদ্বেগগুলি বাদ দিয়ে, এটি কিছু পরিস্থিতিতে আপনাকে গ্যাটাচসের জন্য উন্মুক্ত করতে পারে। মনে করুন আপনি doubleপরিবর্তে এর সাথে কাজ করছেন:

public void myfunction(double exampleParam){
    if(exampleParam > 0){
        //Body will *not* be executed if Double.IsNan(exampleParam)
    }
}

আপাতদৃষ্টিতে সমতুল্য বিপর্যয়ের সাথে এর বিপরীতে:

public void myfunction(double exampleParam){
    if(exampleParam <= 0)
        return;
    //Body *will* be executed if Double.IsNan(exampleParam)
}

সুতরাং কিছু পরিস্থিতিতে এএ যা সঠিকভাবে উল্টানো দেখা যায় ifতা নাও হতে পারে।


4
এটিও লক্ষ করা উচিত যে পুনঃভাগের দ্রুত কুইক ফিক্স উদাহরণগুলি পরম> 0 থেকে উদাহরণ পরম <0 উদাহরণ নয় পারম <= 0 যা আমাকে ধরা দিয়েছে।
14

1
এবং এই কারণেই সেই চেকটি সামনে হওয়া উচিত এবং পাশাপাশি দেবকে দেওয়া উচিত যে কোনও নানকে জামিন দেওয়া উচিত।
ব্যবহারকারী 441521

51

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

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

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


6
ব্যতিক্রমগুলি কেন উগলিএন্ডএভিল [টিএম] ... ;-) ব্যতিক্রমগুলি অভিনব, ব্যয়বহুল ছদ্মবেশে ব্যতিক্রম You
এরিকশাফার

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

এই উত্তরটি আমি সত্যিই খুঁজছিলাম! এখানে দুর্দান্ত উত্তর রয়েছে, তবে তাদের বেশিরভাগ উদাহরণগুলিতে মনোনিবেশ করেন, এই সুপারিশটির জন্মের প্রকৃত কারণের উপর নয়।
গুস্তাভো মরি

এটি সর্বোত্তম উত্তর, যেহেতু এটি ব্যাখ্যা করে যে কেন এই পুরো যুক্তিটি প্রথম স্থানে উঠেছিল।
বাটল বুটকাস

If you've got deep nesting, maybe your function is trying to do too many things.=> এটি আপনার পূর্ববর্তী বাক্যাংশ থেকে সঠিক ফলাফল নয়। কারণ আপনি বলার ঠিক আগে আপনি আচরণের ক্ষেত্রে কোড সি সহ আচরণটি করতে পারবেন কোড ডি সহ কোড ডি কোড ডি ক্লিনার, মঞ্জুর, তবে "অনেকগুলি জিনিস" আচরণকে বোঝায়, যা পরিবর্তিত হয়নি। অতএব আপনি এই উপসংহারের সাথে কোনও ধারণা রাখবেন না।
v.oddou

30

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

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

http://c2.com/cgi/wiki?GuardClause


2
যথাযথভাবে। এটি একটি রিফ্যাক্টরিং আরও। এটি আপনার উল্লেখ হিসাবে কোডটি আরও সহজভাবে পড়তে সহায়তা করে।
আরপট্টবী

গার্ড ক্লজটির জন্য 'রিটার্ন' যথেষ্ট এবং ভয়ঙ্কর নয়। আমি করতাম: যদি (প্রাক্তন <= 0) র্রংপ্রামভ্যালিউএক্স ("[মেথডনাম] খারাপ ইনপুট প্যারাম 1 মান {0} ... ফেলে দেয় এবং আপনাকে ব্যতিক্রমটি ধরে আপনার অ্যাপ্লিকেশন
লগতে

3
@John। আপনি যদি সত্যিই ত্রুটি হয়ে থাকেন তবে আপনি ঠিক বলেছেন। তবে প্রায়শই তা হয় না। এবং পদ্ধতিটিকে যে পদ্ধতিতে ডাকা হয় সেখানে প্রতিটি স্থানে কিছু পরীক্ষা করার পরিবর্তে এটি পরীক্ষা করে কিছু না করে ফিরে আসে।
পাইওটার পেরাক

3
আমি এমন কোনও পদ্ধতিটি পড়তে পছন্দ করব না যা কোড, পিরিয়ড, ifগুলি এবং না এর দুটি পর্দা । lol
jpmc26

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

22

এটি কেবল নান্দনিকতাকেই প্রভাবিত করে না, তবে কোড নেস্টিং প্রতিরোধ করে।

এটি আপনার ডেটাও বৈধ কিনা তা নিশ্চিত করার জন্য এটি পূর্ব শর্ত হিসাবে কাজ করতে পারে।


18

এটি অবশ্যই বিষয়গত, তবে আমি মনে করি এটি দুটি পয়েন্টের সাথে দৃ strongly়ভাবে উন্নতি করেছে:

  • এটি এখনই তাত্ক্ষণিকভাবে স্পষ্ট যে আপনার ফাংশনটির যদি conditionধরে রাখে তবে কিছুই করার বাকি নেই ।
  • এটি নীড়ের স্তরটি নীচে রাখে। বাসা বাঁধলে পড়াশোনার ক্ষতি হয় আপনার ভাবার চেয়ে বেশি।

15

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

আপনি এবং আপনার সহকর্মীদের পড়া সহজ বলে মনে হয় এটি অবশেষে নেমে আসে।


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

1
সংবাদ: প্রকৃতপক্ষে আমি খুব বিরতি এবং রিটার্নগুলি খারাপ হওয়ার খুব কার্যকর কারণ খুঁজে পেয়েছি এবং এটি আমি যা বলেছি তার প্রত্যক্ষ পরিণতি, স্থির বিশ্লেষণ। আপনি এখানে যান, ইন্টেল সি ++ সংকলক ব্যবহার-গাইড কাগজ: d3f8ykwhia686p.cloudfront.net/1live/intel/… । মূল বাক্যাংশ:a loop that is not vectorizable due to a second data-dependent exit
v.oddou

12

পারফরম্যান্স অনুযায়ী, দুটি পদ্ধতির মধ্যে কোনও লক্ষণীয় তফাত থাকবে না।

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

প্রতিযোগিতামূলক বিদ্যালয়গুলি রয়েছে যেগুলি সম্পর্কে কোন পদ্ধতির পক্ষে অগ্রাধিকারযোগ্য।

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

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


11

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

if (something) {
    // a lot of indented code
}

আপনি শর্তটি বিপরীত করুন এবং যদি বিপরীত শর্তটি পূর্ণ হয় তবে বিরতি দিন

if (!something) return false; // or another value to show your other code the function did not execute

// all the code from before, save a lot of tabs

returnকাছাকাছি কোথাও হিসাবে নোংরা goto। এটি আপনাকে আপনার বাকী কোডটি ফাংশনটি চালাতে পারে না তা দেখানোর জন্য একটি মান পাস করার অনুমতি দেয়।

নেস্টেড অবস্থায় এটি কোথায় প্রয়োগ করা যেতে পারে তার সেরা উদাহরণগুলি আপনি দেখতে পাবেন:

if (something) {
    do-something();
    if (something-else) {
        do-another-thing();
    } else {
        do-something-else();
    }
}

বনাম:

if (!something) return;
do-something();

if (!something-else) return do-something-else();
do-another-thing();

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

আমি এক মুহুর্তের জন্যও প্রস্তাব দেব না যে প্রাকসনগুলি আপনার জীবন বদলে দেবে বা আপনাকে পাড়া দেবে তবে আপনি সম্ভবত আপনার কোডটি পড়তে পারেন little


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

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

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

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

9

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


8

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

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


7

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

যেমন।

 bool PerformDefaultOperation()
 {
      bool succeeded = false;

      DataStructure defaultParameters;
      if ((defaultParameters = this.GetApplicationDefaults()) != null)
      {
           succeeded = this.DoSomething(defaultParameters);
      }

      return succeeded;
 }

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


4
বুল পারফর্মডফল্টঅপ্রেশন () {ডেটা স্ট্রাকচার ডিফল্টপ্যারামিটারস = এটি etঅনলাইন অ্যাপ্লিকেশনডেফাল্টস (); প্রত্যাবর্তন করুন (ডিফল্টপ্যারামিটারগুলি! = নুল && এটি.ডোসোমিংথিং (ডিফল্টপ্যারামিটার))} সেখানে, এটি আপনার জন্য স্থির করে
রেখেছে

1
এই উদাহরণটি খুব মৌলিক এবং এই প্যাটার্নটির বিন্দুটি মিস করে। এই ফাংশনটির ভিতরে আরও 4 টি চেক রয়েছে এবং তারপরে এটি আরও পাঠযোগ্য বলে আমাদের বলুন কারণ এটি তা নয়।
ব্যবহারকারী 441521

5

কোডটি কেমন দেখাচ্ছে তা সম্পর্কে অনেকগুলি ভাল কারণ । তবে ফলাফল কী হবে?

আসুন কয়েকটি সি # কোড এবং এর আইএল সংকলিত ফর্মটি একবার দেখুন:


using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length == 0) return;
        if ((args.Length+2)/3 == 5) return;
        Console.WriteLine("hey!!!");
    }
}

এই সাধারণ স্নিপেটটি সংকলন করা যায়। আপনি ইল্ডাস্ম সহ উত্পন্ন .exe ফাইলটি খুলতে পারেন এবং ফলাফল কী তা পরীক্ষা করতে পারেন। আমি সমস্ত সমাবেশকারী জিনিস পোস্ট করব না তবে আমি ফলাফলগুলি বর্ণনা করব।

উত্পন্ন আইএল কোড নিম্নলিখিতটি করে:

  1. যদি প্রথম শর্তটি মিথ্যা হয় তবে দ্বিতীয়টি যেখানে থাকে সেখানে কোডটি লাফ দেয়।
  2. যদি এটি সত্যিকারের শেষ নির্দেশের দিকে ঝাপ দেয়। (দ্রষ্টব্য: শেষ নির্দেশটি একটি রিটার্ন)।
  3. দ্বিতীয় শর্তে ফলাফল গণনার পরে একই ঘটে। তুলনা করুন এবং: কনসোলটিতে পেয়েছি false রাইটলাইন যদি মিথ্যা হয় বা শেষ হয় তবে এটি সত্য হয়।
  4. বার্তা মুদ্রণ করুন এবং ফিরে।

সুতরাং মনে হচ্ছে কোডটি শেষ পর্যন্ত চলে যাবে। নেস্টেড কোড সহ যদি আমরা একটি সাধারণ করি তবে কী হবে?

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length != 0 && (args.Length+2)/3 != 5) 
        {
            Console.WriteLine("hey!!!");
        }
    }
}

আইএল নির্দেশাবলীতে ফলাফলগুলি বেশ অনুরূপ। পার্থক্যটি হ'ল শর্ত অনুযায়ী জাম্প করার আগে: মিথ্যা যদি পরবর্তী কোডের কোডে যায়, যদি সত্য হয় তবে শেষ হয়। এবং এখন আইএল কোডটি আরও ভাল প্রবাহিত হয় এবং এতে 3 টি জাম্প রয়েছে (সংকলক এটি কিছুটা অনুকূলিত করে): ১. প্রথম লাফ: যখন দৈর্ঘ্য 0 অংশে থাকে যেখানে কোডটি আবার শেষ হয় (তৃতীয় জাম্প) শেষ হয়। ২. দ্বিতীয়: একটি নির্দেশ এড়াতে দ্বিতীয় শর্তের মাঝামাঝি। ৩. তৃতীয়: দ্বিতীয় শর্তটি মিথ্যা হলে শেষের দিকে ঝাঁপুন।

যাইহোক, প্রোগ্রামের কাউন্টার সর্বদা লাফিয়ে উঠবে।


5
এটি ভাল তথ্য - তবে ব্যক্তিগতভাবে আমি কম যত্ন নিতে পারিনি যদি আইএল "আরও ভাল প্রবাহিত হয়" কারণ যে লোকেরা কোড পরিচালনা করবে তারা কোনও আইএল দেখতে পাবে না
জনআইডল

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

5

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

শাখা ভবিষ্যদ্বাণী আরও এখানে


4

এটি কেবল বিতর্কিত। তাড়াতাড়ি প্রত্যাবর্তনের প্রশ্নে কোনও "প্রোগ্রামারদের মধ্যে চুক্তি" নেই। যতদূর আমি জানি এটি সর্বদা সাবজেক্টিভ।

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

আমি মনে করি না যে আপনি এই প্রশ্নের একটি চূড়ান্ত উত্তর পাবেন।


আমি আপনার পারফরম্যান্স যুক্তি বুঝতে পারি না। শর্তগুলি বুলিয়ান তাই ফলাফল যাই হোক না কেন, সর্বদা দুটি ফলাফল হয় ... আমি কেন দেখছি না যে কোনও বিবৃতি (বা না) বিপরীত করলে ফলাফল পরিবর্তন হবে। (আপনি যদি না শর্তে "না" যোগ করার কথা না বলছেন তবে পরিমাপের পরিমাপযোগ্য পরিমাণ যুক্ত হয় ...
অলি

2
অপ্টিমাইজেশন এটির মতো কাজ করে: আপনি যদি নিশ্চিত হন যে সর্বাধিক সাধারণ কেস অন্য ব্লকের পরিবর্তে যদি ইফ ব্লকে রয়েছে তবে সিপিইউ সাধারণত ইতিমধ্যে তার পাইপলাইনে লোড হওয়া ব্লকের বিবৃতি উপস্থিত করবে। যদি শর্তটি মিথ্যা প্রত্যাবর্তন করে তবে সিপিইউকে তার পাইপলাইনটি খালি করতে হবে এবং ...
অন্যদিকে

আমি কেবল পাঠযোগ্যতার জন্য অন্যেরা যা বলছে তা করাও আমার পছন্দ, আমি "অন্য" এর চেয়ে "তত্ক্ষণ" ব্লকে নেতিবাচক মামলাগুলি ঘৃণা করি। সিপিইউ কী করছে তা না জেনে বা বিবেচনা না করেও এটি করার অর্থ বোধ হয়
অ্যান্ড্রু বুলক 6:58

3

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

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

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

সুতরাং এটি অন্য পরিস্থিতি হতে পারে যেখানে উল্টানো আইএফস একটি পরিষ্কার কোডে অবদান রাখতে পারে।


3

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

তবে 99% ক্ষেত্রে অতিরিক্ত কন্সট্রাক্টর এবং ডেস্ট্রাক্টর কলগুলি সংরক্ষণ করা নেস্টেড ifব্লকগুলি প্রবর্তনযোগ্যতা হ্রাসের জন্য উপযুক্ত নয় (যেমন অন্যরা উল্লেখ করেছেন)।


2
আছে। অবশেষে এনআরভিওর উল্লেখ করে এমন কাউকে খুঁজে পেতে, একই জিনিস (যার মধ্যে 2 টি হিমায়িত হচ্ছে) জিজ্ঞাসা করে আমাকে 3 টি দশকের উত্তর দশটি দীর্ঘ পাঠ পড়েছিল। জি ... ধন্যবাদ
v.oddou

2

এটা মতামত বিষয়।

আমার স্বাভাবিক পদ্ধতিটি হ'ল একক লাইন ifs এড়ানো এবং কোনও পদ্ধতির মাঝখানে ফিরে আসা।

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


2

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

যদি আপনি আসলে কোনও রিটার্নভ্যালু ফিরিয়ে আনেন - বাসা বাঁধাই সাধারণত আপনার আরও ভাল উপায় হ'ল কারণ আপনার রিটার্নভ্যালুটি কেবলমাত্র এক জায়গায় (শেষে - দুহ) ফিরে আসে এবং এটি পুরো ক্ষেত্রে আপনার কোডটিকে আরও রক্ষণাবেক্ষণ করে তুলতে পারে।


1

আমি নিশ্চিত নই, তবে আমি মনে করি, আর # খুব লাফানো এড়ানোর চেষ্টা করে। আপনার যদি আইএফ-ইএলএসই থাকে, সংকলক এরকম কিছু করে:

শর্তটি মিথ্যা -> মিথ্যা_সংশ্লিষ্ট_প্রেমীতে অনেকদূর

সত্য_কন্ডিশন_লবেল: নির্দেশ 1 ... নির্দেশ_ন

false_condition_label: নির্দেশ 1 ... নির্দেশ_ন

শেষ ব্লক

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


0

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


0

আমার ধারণা হ'ল ফাংশনটির মাঝামাঝি "রিটার্নটি এত" সাবজেক্টিভ "হওয়া উচিত নয়। কারণটি বেশ সহজ, এই কোডটি নিন:

    ফাংশন do_something (তথ্য) {

      যদি (! is_ अवैध_data (ডেটা)) 
            প্রত্যাবর্তন মিথ্যা;


       কি_সামান্য_এই_পট_এ_আর (ডেটা);

       istance = নতুন অবজেক্ট_সহ_প্রতি_পেনফুল_ কনস্ট্রাক্টর (ডেটা);

          যদি (istance বৈধ নয়) {
               ভুল বার্তা( );
                প্রত্যাবর্তন

          }
       কানেক্ট_টো_ড্যাটাবেস ();
       get_some_other_data ();
       আসতে;
    }

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


একটি ব্যতিক্রম ভাষা নিয়ে আপনার কাছে এই সমস্যাগুলি নেই।
ব্যবহারকারী 441521

0

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


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

1
আমি সম্মত নই - প্রথম আইনটি অ্যালগরিদম সঠিক হওয়ার বিষয়ে। তবে আমরা সকলেই প্রকৌশলী, যা আমাদের যে সংস্থান আছে সেগুলি দিয়ে সঠিক সমস্যাটি সমাধান করার জন্য এবং উপলভ্য বাজেটে করা সম্পর্কে। একটি অ্যাপ্লিকেশন যা খুব ধীর গতির জন্য উপযুক্ত নয় is
ডেভিড অ্যালান ফিঞ্চ 11
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.