একটি আইএফ বিবৃতি উল্টানো


39

তাই আমি কয়েক বছর ধরে প্রোগ্রামিং করছি এবং সম্প্রতি রিশার্পার আরও ব্যবহার শুরু করেছি। রিশার্পার আমাকে সর্বদা একটি পরামর্শ দেয় তা হ'ল "বাসা বাঁধতে কমাতে বিবৃতি" যদি "উল্টে ফেলা হয়"।

ধরা যাক আমার এই কোডটি রয়েছে:

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
    }
}

এবং রিশার্পার পরামর্শ দেবে যে আমি এটি করি:

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;
}

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

আমার প্রশ্ন হ'ল: ব্যক্তিগত পছন্দ বা পঠনযোগ্যতা বাদে বাসা বাঁধতে হ্রাস করার কোনও কারণ আছে কি? একটি পারফরম্যান্স পার্থক্য বা অন্য কিছু যা আমি সচেতন নাও হতে পারে?


1
সম্ভাব্য সদৃশ Keep এর খাঁজ স্তর কম
মশা

24
এখানে মূল জিনিসটি হ'ল "পুনঃভাগের পরামর্শ"। পরামর্শটি একবার দেখুন, যদি কোডটি পড়া সহজ হয় এবং ধারাবাহিক হয় তবে এটি ব্যবহার করুন। প্রতিটি লুপের জন্য / এর জন্য এটি একই কাজ করে।
জন রেয়নর

আমি সাধারণত এই পুনঃনির্বাচিত ইঙ্গিতগুলি হ্রাস করি, আমি সর্বদা অনুসরণ করি না, তাই তারা আর পাশের বারে প্রদর্শিত হবে না।
কোডসইনচাউস

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

2
রিশার্পার কি শর্তসাপেক্ষে ক্যোয়ারিতে স্থানান্তর করার পরামর্শ দেয় না? পূর্বাভাস (সামান্য কিছু অবজেক্টলাইস্টে ।অবজেক্ট => অবজেক্ট! = নাল) {...}
রোমান রেইনার

উত্তর:


63

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

আমরা কেবল মানুষ এবং একসময় আমাদের মাথায় একাধিক জিনিস রাখা কঠিন।

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


64
বিকাশকারী মতামতের জোয়ার এই পথে যেতে দেখে আমি পছন্দ করি। সেখানে কোডে এত পাখির কারণ যে একটি অসাধারণ জনপ্রিয় বিভ্রমের আছে break, continueএবং একাধিক returnকাঠামোবদ্ধ নেই।
জিমি জেমস 13

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

2
@ ইভান: 'এই ক্যান্টটি এক্স হতে পারে বা এটি শীর্ষে লুপটি বেরিয়ে যেত' এবং 'এটি এক্স হতে পারে না বা এটি এই ব্লকে প্রবেশ করত না' এর মধ্যে পার্থক্য কী?
কলিন

এক্স এর জটিলতা এবং অর্থ কিছুই যা গুরুত্বপূর্ণ তা নয়
ইভান

4
@ ইভান: আমি মনে করি break/ / continue/ returnএকটি elseব্লক থেকে একটি সত্য সুবিধা আছে । প্রারম্ভিক গেট আউটগুলির সাথে, দুটি ব্লক রয়েছে : গেট -আউট ব্লক এবং সেখানে থাকা ব্লক; সঙ্গে elseআছে 3 ব্লক যদি, অন্য আর যাই হোক না কেন পরে আসে (যা যাই হোক না কেন শাখা নিয়ে যাওয়া ব্যবহার করা হয়)। আমি কম ব্লক থাকা পছন্দ করি
ম্যাথিউ এম।

33

নেতিবাচক এড়াবেন না। সিপিইউ তাদের পছন্দ করলেও মানবগুলি তাদের পার্সিং হিসাবে স্তন্যপান করে।

যাইহোক, মূর্খতা শ্রদ্ধা। আমরা মানুষগুলি অভ্যাসের প্রাণী তাই আমরা আগাছা পূর্ণ পথগুলিতে ভাল পরা পথ পছন্দ করি।

foo != nullদুর্ভাগ্যক্রমে, একটি প্রতিমা হয়ে উঠেছে। আমি আলাদাভাবে আর আলাদা অংশগুলি লক্ষ্য করি। আমি এটিকে দেখি এবং কেবল মনে করি, "ওহ, এটি fooএখন থেকে ডট করা নিরাপদ "।

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

তবে আপনি আমাদের যা দিয়েছেন তা হ'ল:

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;
}

যা এমনকি কাঠামোগত একই নয়!

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;

    if(someGlobalObject == null) continue;
    someSideEffectObject = someGlobalObject.SomeProperty;
}

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

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


1
ঠিক আছে, লুপটিতে আপনার আরও কোড থাকলে এটি কীভাবে কাজ করে তা নির্ভর করে এটি কীভাবে সমস্ত একসাথে আসে। এটি স্বতন্ত্র কোড নয়। প্রশ্নের রিফ্যাক্টর কোড উদাহরণের জন্য সঠিক ছিল, তবে বিচ্ছিন্ন না হয়েও সঠিক হতে পারে না - আপনি যে বিন্দুটির জন্য যাচ্ছিলেন সেটিই ছিল? (+1 যদিও নেতিবাচকতা এড়াতে পারবেন না)
বাল্ড্রিক ২

@ বালড্রিক if (foo != null){ foo.something() }আমাকে শূন্য থাকলে যত্ন না করেই কোড যুক্ত করতে দেয় foo। এটা হয় না। এমনকি এখন আমার এটি করার প্রয়োজন না থাকলেও "ভবিষ্যতের স্ক্রু বলার জন্য আমি অনুপ্রাণিত বোধ করি না" ভাল তারা যদি তাদের প্রয়োজন হয় তবে এটি কেবল এটি রিফ্যাক্টর করতে পারে "। Feh। সফ্টওয়্যারটি কেবল তখনই নরম হয় যদি এটি পরিবর্তন করা সহজ।
candied_orange

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

সম্পর্কিত এবং জড়িত একই জিনিস নয়।
candied_orange

1
নেতিবাচকতা এড়াবেন না: ডি
ভিটালিবি

20

বিরতি খারাপ যে বাসা বাঁধে সে সম্পর্কে এটি পুরানো যুক্তি।

লোকেরা প্যারামিটার চেকগুলির জন্য প্রারম্ভিক রিটার্ন গ্রহণ করবে বলে মনে হয়, তবে এটি একটি পদ্ধতির বেশিরভাগ অংশে নষ্ট হয়ে যায়।

ব্যক্তিগতভাবে আমি চালিয়ে যাওয়া, ভাঙ্গা, গোটো ইত্যাদি এড়িয়ে চলি যদিও এর চেয়ে বেশি বাসা বাঁধে। তবে বেশিরভাগ ক্ষেত্রে আপনি উভয় এড়াতে পারেন।

foreach (someObject in someObjectList.where(i=>i != null))
{
    someOtherObject = someObject.SomeProperty;
}

যখন আপনার অনেক স্তর থাকে তখন অবশ্যই বাসা বাঁধার জিনিসগুলি মেনে চলা শক্ত করে

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
        if(someObject.x > 5) 
        {
            x ++;
            if(someObject.y > 5) 
            {
                x ++;
            }
        }
    }
}

সবচেয়ে খারাপটি যখন আপনার উভয়ই থাকে

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
        if(someObject.x > 5) 
        {
            x ++;
            if(someObject.y > 5) 
            {
                x ++;
                return;
            }
            continue;
        }
        someObject.z --;
        if(myFunctionWithSideEffects(someObject) > 6) break;
    }
}

11
এই লাইনটি ভালবাসুন: foreach (subObject in someObjectList.where(i=>i != null))কেন আমি কখনই এরকম কিছু ভেবে দেখিনি।
ব্যারি ফ্র্যাঙ্কলিন

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

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

হাস্যকরভাবে, পুনঃভাগে সম্পাদনা করাতে নীড়ের ঠিক একই স্তর রয়েছে, কারণ এটির পরে যদি একটি ওয়ান-লাইনার থাকে।
পিটার

হেই, যদিও ধনুর্বন্ধনী! যা স্পষ্টতই অনুমোদিত: /
ইভান

6

সমস্যাটি continueহ'ল আপনি কোডটিতে আরও লাইন যুক্ত করলে যুক্তিটি জটিল হয়ে যায় এবং এতে বাগ থাকতে পারে। যেমন

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;

    ...  imagine that there is some code here ...

    // added later by a Junior Developer
    doSomeOtherFunction(someObject);
}

আপনি কি সমস্ত কিছু অবজেক্টের doSomeOtherFunction()জন্য কল করতে চান , বা কেবল নন-নাল থাকলে? মূল কোড সহ আপনার কাছে বিকল্প রয়েছে এবং এটি আরও পরিষ্কার। সঙ্গে এক ভুলবেন পারে "উহু, হাঁ, পিছনে আমরা NULLs এড়ানো" এবং আপনি এমনকি, এটা সব someObjects জন্য কল করার অপশন না থাকে যদি না আপনি পদ্ধতি শুরুর যা সম্ভব অথবা সঠিক নাও হতে পারে যে কল করা অন্যান্য কারণেcontinue

হ্যাঁ, অনেক বাসা বাঁধাই কুৎসিত এবং সম্ভবত বিভ্রান্তিকর, তবে এই ক্ষেত্রে আমি traditionalতিহ্যবাহী স্টাইলটি ব্যবহার করব।

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


12
লুপের ভিতরে পর্যাপ্ত কোড থাকা উচিত নয় যা আপনি এর উপরে শীর্ষে নাল-চেক দেখতে পাচ্ছেন না can't
ব্রায়ান বোয়েচার 16

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

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

1
@ করসিকা অ্যাপল এসএসএল বাগটি আসলে একটি গোটো বাগ, তবে সহজেই বিরতি বা বাগ চালিয়ে যেতে পারত। তবে কোডটি ভয়াবহ ...
user949300

3
@ ব্রায়ানবোটচার সমস্যাটি আমার কাছে মনে হয় যে একই ডেভস যারা চালিয়ে যেতে বা একাধিক রিটার্ন ভাবেন ঠিক আছে তারাও মনে করেন যে বৃহত পদ্ধতিতে তাদের সমাহিত করাও ঠিক। সুতরাং চালিয়ে / একাধিক রিটার্ন সহ আমার প্রতিটি অভিজ্ঞতা কোডের বিশাল মেসে পড়ে।
অ্যান্ডি

3

ধারণাটি প্রথম দিকের প্রত্যাবর্তন। প্রারম্ভিক returnএকটি লুপ প্রথম দিকে হয়ে continue

এই প্রশ্নে প্রচুর ভাল উত্তর: আমি কি খুব শীঘ্রই কোনও ফাংশন থেকে ফিরে আসব বা একটি বিবৃতি ব্যবহার করব?

লক্ষ্য করুন যে প্রশ্নটি মতামত ভিত্তিতে বন্ধ হয়ে গেলে, 430+ ভোট তাড়াতাড়ি ফেরতের পক্ষে, are 50 ভোট "এটি নির্ভর করে", এবং 8 তাড়াতাড়ি প্রত্যাবর্তনের বিরুদ্ধে। সুতরাং একটি ব্যতিক্রমী দৃ strong় sensক্যমত্য আছে (হয় তা হয়, বা আমি গণনায় খারাপ, যা প্রশংসনীয়)।

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


2

এই পদ্ধতিটি প্রাক-শর্তাদি শংসাপত্রের জন্য কার্যকর যখন যখন আপনার শর্তগুলি পূরণ করা হয় তখন আপনার পদ্ধতির মূল অংশ থাকে।

আমরা প্রায়শই ifsআমার কাজে উল্টে ফ্যান্টমকে অন্য কোনও কাজে নিযুক্ত করি। এটি বেশ ঘন ঘন ব্যবহৃত হত যে কোনও পিআর পর্যালোচনা করার সময় আমি নির্দেশ করতে পারি যে কীভাবে আমার সহকর্মী বাসা বাঁধার তিনটি স্তর অপসারণ করতে পারে! এটি আমাদের আইএফএস রোল আউট করার পরে এটি কম ঘন ঘন ঘটে।

এখানে এমন কিছু খেলনার উদাহরণ যা রোল আউট করা যায়

function foobar(x, y, z) {
    if (x > 0) {
        if (z != null && isGamma(y)) {
            // ~10 lines of code
            // return something
        }
        else {
           return y
        }
    }
    else {
      return y + z
    }
}

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

function foobar(x, y, z) {
    if (x <=0) {
        return y + z
    }
    if (z == null || !isGamma(y) {
       return y
    }
    // ~ 10 lines of code
    // return something
}

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


ওপির কোড নমুনার প্রতিক্রিয়া হিসাবে, আমি সম্মতি জানাই যে এটি একটি ওভারেয়র ধসে পড়ে। বিশেষত 1 টিবি-র মধ্যে, আমি যে স্টাইলটি ব্যবহার করি, বিপরীতের ফলে কোডটি আকার বাড়ায় increase


0

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

অন্যান্য সমস্ত জিনিস সমান হওয়ায়, কম বাসা বাঁধাই বেশি পছন্দনীয়, এজন্যই রিসার্পার এমন একটি রূপান্তর প্রস্তাব করবে যা নীড় বাঁধবে reduce তবে অন্যান্য সমস্ত জিনিস সমান নয় : এক্ষেত্রে রূপান্তরটির জন্য একটি প্রবর্তন প্রয়োজন continue, যার অর্থ ফলস্বরূপ কোডটি অনুসরণ করা আসলে আরও শক্ত।

ইন কিছু ক্ষেত্রে, একটি জন্য পাখির একটি স্তর বিনিময় continue পারে প্রকৃতপক্ষে একটি উন্নতি হতে, কিন্তু এই প্রশ্নে কোড, যা ReSharpers যান্ত্রিক নিয়ম বোঝার পরলোক হল এর শব্দার্থবিদ্যা উপর নির্ভর করে।

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


0

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

for(obj in objectList) {
    if(obj == null) continue;
    if(obj.getColour().equals(Color.BLUE)) {
        // Handle blue objects
    } else {
        // Handle non-blue objects
    }
}

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

items.stream()
    .filter(i -> (i != null))
    .filter(i -> i.getColour().equals(Color.BLUE))
    .forEach(i -> {
        // Process blue objects
    });

ঘটনাক্রমে, পার্লের উল্টানো সম্পর্কে আমি খুব পছন্দ করি এটিগুলির মধ্যে একটি যদি ( unless) একক বিবৃতিতে প্রয়োগ করা হয়, যা নিম্নলিখিত ধরণের কোডকে মঞ্জুরি দেয় যা আমি খুব সহজেই পড়তে পারি:

foreach my $item (@items) {
    next unless defined $item;
    carp "Only blue items are supported! Failed on item $item" 
       unless ($item->get_colour() eq 'blue');
    ...
}
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.