একই অভিব্যক্তিটির পূর্বাভাস পদ্ধতিতে ভাঙার চেয়ে বড় বুলিয়ান অভিব্যক্তিটি আরও বেশি পঠনযোগ্য? [বন্ধ]

Question

কী বোঝা সহজ, একটি বড় বুলিয়ান স্টেটমেন্ট (বেশ জটিল), বা একই বক্তব্যটি প্রাক্কলিত পদ্ধতিতে বিভক্ত হয়ে পড়েছে (পড়ার জন্য প্রচুর অতিরিক্ত কোড পড়ে)?

বিকল্প 1, বিগ বুলিয়ান এক্সপ্রেশন:

    private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
    {

        return propVal.PropertyId == context.Definition.Id
            && !repo.ParentId.HasValue || repo.ParentId == propVal.ParentId
            && ((propVal.SecondaryFilter.HasValue && context.SecondaryFilter.HasValue && propVal.SecondaryFilter.Value == context.SecondaryFilter) || (!context.SecondaryFilter.HasValue && !propVal.SecondaryFilter.HasValue));
    }

বিকল্প 2, শর্তগুলি ভাঙ্গা পদ্ধতিতে বিভক্ত:

    private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
    {
        return MatchesDefinitionId(context, propVal)
            && MatchesParentId(propVal)
            && (MatchedSecondaryFilter(context, propVal) || HasNoSecondaryFilter(context, propVal));
    }

    private static bool HasNoSecondaryFilter(CurrentSearchContext context, TValToMatch propVal)
    {
        return (!context.No.HasValue && !propVal.SecondaryFilter.HasValue);
    }

    private static bool MatchedSecondaryFilter(CurrentSearchContext context, TValToMatch propVal)
    {
        return (propVal.SecondaryFilter.HasValue && context.No.HasValue && propVal.SecondaryFilter.Value == context.No);
    }

    private bool MatchesParentId(TValToMatch propVal)
    {
        return (!repo.ParentId.HasValue || repo.ParentId == propVal.ParentId);
    }

    private static bool MatchesDefinitionId(CurrentSearchContext context, TValToMatch propVal)
    {
        return propVal.PropertyId == context.Definition.Id;
    }

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

Comments

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

— প্রোগ্রামার

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

— thepacker

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

— স্টিভ জেসোপ

বিকল্প 3: আমি একটিও পছন্দ করি না। দ্বিতীয়টি হাস্যকরভাবে ভার্বোজ, প্রথমটি দ্বিতীয়টির সমতুল্য নয়। প্যারেন্টেসিস সহায়তা।

— ডেভিড হামেন

এটি পেডেন্টিক হতে পারে তবে কোডের কোনও ব্লকে আপনার কোনও if বক্তব্য নেই। আপনার প্রশ্নটি বুলিয়ান এক্সপ্রেশন সম্পর্কে ।

— কাইল স্ট্র্যান্ড

Answer 1

কি বুঝতে সহজ হয়

পরের পন্থা। এটি কেবল বোঝা সহজ নয় তবে এটি লেখার, পরীক্ষা করা, রিফ্যাক্টরটি পাশাপাশি প্রসারিত করাও সহজ। প্রতিটি প্রয়োজনীয় শর্তটি নিরাপদে ডিকোপল করা এবং নিজস্ব পদ্ধতিতে পরিচালনা করা যায়।

এটি সমস্যাযুক্ত কারণ আপনার কোডটি বোঝার জন্য সমস্ত পদ্ধতি পড়তে হবে

পদ্ধতিগুলি সঠিকভাবে নামকরণ করা থাকলে এটি সমস্যাযুক্ত নয়। প্রকৃতপক্ষে এটি বোঝা সহজ হবে কারণ পদ্ধতির নামটি শর্তের উদ্দেশ্যটি বর্ণনা করে।
একজন দর্শকের if MatchesDefinitionId()পক্ষে এর চেয়ে বেশি ব্যাখ্যাযোগ্যif (propVal.PropertyId == context.Definition.Id)

[ব্যক্তিগতভাবে, প্রথম দৃষ্টিভঙ্গিটি আমার চোখের পোটায়]

Comments

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

— BЈовић

এবং দয়া করে, তাদের (পদ্ধতির নাম) তাত্পর্যপূর্ণ এবং সংক্ষিপ্ত করুন। 20+ অক্ষর পদ্ধতির নামগুলি আমার চোখে ব্যথা করে। MatchesDefinitionId()বর্ডারলাইন।

— মাইন্ডউইন

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

— আজেদী 32

@ আজেদী 32 কে পদ্ধতির নামের উপর পদ্ধতিটি কী করে বা গ্রামীটিক্যালি শব্দ পদ্ধতির নাম থাকতে পারে তার উপর একটি রচনা লিখতে হবে না। যদি কেউ সংক্ষেপের মানগুলি পরিষ্কার করে রাখে (কর্ম গ্রুপ বা সংস্থা জুড়ে) সংক্ষিপ্ত নাম এবং পাঠযোগ্যতা নিয়ে সমস্যা হবে না।

— মাইন্ডউইন

জিপফের আইন ব্যবহার করুন: তাদের ব্যবহারকে নিরুৎসাহিত করার জন্য জিনিসগুলিকে আরও ভার্বোজ করুন ।

— hoosierEE

Answer 2

যদি এই প্রাকটিক ফাংশনগুলির একমাত্র স্থান ব্যবহার করা হয় তবে আপনি এর boolপরিবর্তে স্থানীয় ভেরিয়েবলগুলিও ব্যবহার করতে পারেন :

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    bool matchesDefinitionId = (propVal.PropertyId == context.Definition.Id);
    bool matchesParentId = (!repo.ParentId.HasValue || repo.ParentId == propVal.ParentId);
    bool matchesSecondaryFilter = (propVal.SecondaryFilter.HasValue && context.No.HasValue && propVal.SecondaryFilter.Value == context.No);
    bool hasNoSecondaryFilter = (!context.No.HasValue && !propVal.SecondaryFilter.HasValue);

    return matchesDefinitionId
        && matchesParentId
        && matchesSecondaryFilter || hasNoSecondaryFilter;
}

এগুলি আরও ভাঙ্গতে পারে এবং এগুলিকে আরও পাঠযোগ্য, যেমন এর সাথে পুনরায় সাজানো যায়

bool hasSecondaryFilter = propVal.SecondaryFilter.HasValue;

এবং তারপরে সমস্ত দৃষ্টান্ত প্রতিস্থাপন propVal.SecondaryFilter.HasValue। তারপরে একটি জিনিস তাৎক্ষণিকভাবে বাইরে চলে যায় তা হ'ল hasNoSecondaryFilterঅবহেলিত HasValueবৈশিষ্ট্যগুলিতে matchesSecondaryFilterলজিক্যাল অ্যান্ড ব্যবহার করা হয়, অন্যদিকে একটি যৌক্তিক এবং অন-উপেক্ষিতগুলিতে ব্যবহার করা হয় HasValue- সুতরাং এটি ঠিক বিপরীত নয়।

Comments

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

— বুভিনে

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

— সুইভ

@ এসভিক এতে সন্দেহ নেই যে বেশিরভাগ সময় এটি কোনও পারফরম্যান্স ইস্যু প্রবর্তন করে না। তবুও, আপনি যদি পঠনযোগ্যতা না হারিয়ে অপারেশনগুলি হ্রাস করতে পারেন, তবে কেন এটি করবেন না? আমি নিশ্চিত না যে এটি আমার সমাধানের চেয়ে অনেক বেশি পাঠযোগ্য। এটি পরীক্ষাগুলিতে স্বতন্ত্র ডকুমেন্টিং "নামগুলি" দেয় - যা দুর্দান্ত ... আমি মনে করি এটি নির্দিষ্ট ব্যবহারের ক্ষেত্রে নেমে আসে এবং পরীক্ষাগুলি কীভাবে বোধগম্য হয় তার নিজের ক্ষেত্রে।

— বুভিনে

মন্তব্য যুক্ত করা পঠনযোগ্যতাও সাহায্য করতে পারে ...

— বুভিন জে

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

— সুইভ

Answer 3

সাধারণভাবে, দ্বিতীয়টি পছন্দ করা হয়।

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

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

Comments

হ্যাঁ, যদিও আপনার উত্তরটিতে repoস্থির ক্ষেত্র / সম্পত্তি, অর্থাত্ একটি বিশ্বব্যাপী চলক হিসাবে উপস্থিত ব্যবহারের স্থিরতাও ঠিক করা উচিত । স্ট্যাটিক্সের পদ্ধতিগুলি নির্বিচারে হওয়া উচিত এবং বৈশ্বিক ভেরিয়েবলগুলি ব্যবহার করা উচিত নয়।

— ডেভিড আরনো

@ ডেভিড আর্নো - যদিও এটি দুর্দান্ত নয় তবে হাতে থাকা প্রশ্নের কাছে এটি স্পর্শকাতর বলে মনে হচ্ছে। এবং আরও কোড ছাড়াই এটি প্রশংসনীয় যে ডিজাইনের মতো কাজ করার জন্য একটি আধা-বৈধ কারণ রয়েছে।

— টেলাস্টিন

হ্যাঁ, কিছুই নয়। আমাকে কোডটি কিছুটা

— আপত্তি জানাতে

Answer 4

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

এটি পড়তে সহজ (আপনার উদাহরণের জন্য আপনার যুক্তি দ্বিগুণ করতে হবে, তবে ধারণাটি সত্য ধারণ করে):

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    if( propVal.PropertyId != context.Definition.Id ) return false;

    if( repo.ParentId.HasValue || repo.ParentId != propVal.ParentId ) return false;

    if( propVal.SecondaryFilter.HasValue && 
        context.SecondaryFilter.HasValue && 
        propVal.SecondaryFilter.Value == context.SecondaryFilter ) return true;

    if( !context.SecondaryFilter.HasValue && 
        !propVal.SecondaryFilter.HasValue) return true;

    return false;   
}

Comments

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

— বুভিনেজে

@ বুভিনজে: এর সাথে একেবারেই কোনও ভুল নেই। আসল কোডের মতোই, আপনার দশক প্যারেনেসিস এবং স্ক্রিনের শেষ প্রান্তে প্রসারিত একক লাইন নিয়ে লড়াই করতে হবে না except আমি সেই কোডটি উপর থেকে নীচে পড়তে পারি এবং তা অবিলম্বে বুঝতে পারি। ডব্লিউটিএফ গণনা = 0.

— gnasher729

ফাংশনের শেষে ছাড়া অন্যটি ফিরিয়ে দেওয়া কোডকে কম পাঠযোগ্য, আরও পাঠযোগ্য নয়, আইএমও করে তোলে makes আমি একক প্রস্থান পয়েন্ট পছন্দ করি কিছু ভাল যুক্তি এই লিঙ্কে উভয় উপায়। stackoverflow.com/questions/36707/…

— ব্র্যাড থমাস

@ ব্র্যাড থোমাস আমি একক বহির্গমন পয়েন্টের সাথে একমত হতে পারি না। এটি সাধারণত গভীর নেস্টেড প্রথম বন্ধনী বাড়ে। ফিরতি পথটি শেষ হয় তাই আমার পক্ষে পড়া সহজ।

— বোরজব

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

— বুভিনে

Answer 5

আমি বিকল্প 2 আরও ভাল চাই, তবে একটি কাঠামোগত পরিবর্তন প্রস্তাব করব। শর্তসাপেক্ষে শেষ লাইনে দুটি চেক একক কলে একত্রিত করুন।

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    return MatchesDefinitionId(context, propVal)
        && MatchesParentId(propVal)
        && MatchesSecondaryFilterIfPresent(context, propVal);
}

private static bool MatchesSecondaryFilterIfPresent(CurrentSearchContext context, 
                                                    TValToMatch propVal)
{
    return MatchedSecondaryFilter(context, propVal) 
               || HasNoSecondaryFilter(context, propVal);
}

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

আমি নিশ্চিত নই MatchesSecondaryFilterIfPresent()যে সংমিশ্রণের সেরা নাম কিনা ; তবে এর চেয়ে ভাল আর কিছু মনে হচ্ছে না।

Comments

খুব সুন্দর, পদ্ধতিগুলির মধ্যে যা করা হচ্ছে তা বোঝানোর চেষ্টা করা কেবল মাত্র পুনর্গঠন কলগুলির চেয়ে ভাল।

— klaar

Answer 6

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

আপনার এই কোডটি আরও অবজেক্ট-ভিত্তিক ফর্মে রূপান্তর করা উচিত। আপনি যখন করবেন, আপনি দেখতে পাবেন যে কোড স্থাপনের জন্য বুদ্ধিমান স্থান রয়েছে যা বস্তুর তুলনা করে, ক্ষেত্র ইত্যাদি .. সম্ভবত আপনি যদি অবজেক্টগুলিকে নিজের তুলনা করতে বলতে পারেন, যা আপনার বিবৃতিতে আপনার বিবরণকে হ্রাস করবে তুলনা করার জন্য সহজ অনুরোধ (উদাহরণস্বরূপ if ( a.compareTo (b) ) { }, এতে সমস্ত ক্ষেত্রের তুলনা অন্তর্ভুক্ত থাকতে পারে))

বস্তু এবং তাদের ক্ষেত্রের সাথে তুলনা করার জন্য সি # এর ইন্টারফেস এবং সিস্টেম ইউটিলিটিগুলির একটি সমৃদ্ধ সেট রয়েছে। সুস্পষ্ট বিয়ন্ড .Equalsপদ্ধতি, নতুনদের জন্য, দেখব IEqualityComparer, IEquatable, এবং ইউটিলিটি মত System.Collections.Generic.EqualityComparer.Default।

Answer 7

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

Answer 8

আমি বলব যে দু'জনের প্রায় একইরকম, যদি আপনি পাঠযোগ্যতার জন্য কিছু শ্বেত স্পেস যোগ করেন এবং পাঠকদের আরও অস্পষ্ট অংশগুলির জন্য কিছু মন্তব্য করতে পারেন।

মনে রাখবেন: ভাল মন্তব্যটি কোডটি লেখার সময় আপনি কী ভাবছিলেন তা পাঠককে বলে ।

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

Comments

একটি +1 প্রাপ্য। অন্যান্য উত্তরের উপর ভিত্তি করে জনপ্রিয় মতামত না থাকলেও চিন্তার জন্য ভাল খাবার। ধন্যবাদ :)

— উইলিম

@ উইলিম না, এটি +1 এর প্রাপ্য নয়। দুটি পন্থা এক নয়। অতিরিক্ত মন্তব্যগুলি বোকা এবং বিনা শর্তে।

— BЈовић

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

— আশ্চর্যজনকভাবে

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

— বোরজব

Answer 9

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

এখন, আসুন আপনার প্রথম বিকল্পটি দেখুন, এবং স্বীকার করুন যে না আপনার ইন্ডেন্টেশন এবং লাইন-ব্রেকিং ছিল যে সমস্ত দরকারী, না শর্তসাপেক্ষে যে সমস্ত ভাল কাঠামোগত ছিল:

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal) {
    return propVal.PropertyId == context.Definition.Id && !repo.ParentId.HasValue
        || repo.ParentId == propVal.ParentId
        && propVal.SecondaryFilter.HasValue == context.SecondaryFilter.HasValue
        && (!propVal.SecondaryFilter.HasValue || propVal.SecondaryFilter.Value == context.SecondaryFilter.Value);
}

Answer 10

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

    return (   (   propVal.PropertyId == context.Definition.Id
                && !repo.ParentId.HasValue)
            || (   repo.ParentId == propVal.ParentId
                && (   (   propVal.SecondaryFilter.HasValue
                        && context.SecondaryFilter.HasValue 
                        && propVal.SecondaryFilter.Value == context.SecondaryFilter)
                    || (   !context.SecondaryFilter.HasValue
                        && !propVal.SecondaryFilter.HasValue))));

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

নোট করুন (cond1 && cond2) || (! cond1 && cond3) হিসাবে লেখা যেতে পারে

cond1 ? cond2 : cond3

যা গণ্ডগোল হ্রাস করবে। আমি লিখতাম

if (propVal.PropertyId == context.Definition.Id && !repo.ParentId.HasValue) {
    return true;
} else if (repo.ParentId != propVal.ParentId) {
    return false;
} else if (propVal.SecondaryFilter.HasValue) {
    return (   context.SecondaryFilter.HasValue
            && propVal.SecondaryFilter.Value == context.SecondaryFilter); 
} else {
    return !context.SecondaryFilter.HasValue;
}

Answer 11

আমি সেগুলির সমাধানগুলির কোনওটি পছন্দ করি না, সেগুলি সম্পর্কে তর্ক করা শক্ত এবং পড়া কঠিন read কেবলমাত্র ছোট পদ্ধতির জন্য ছোট পদ্ধতির বিমূর্ততা সবসময় সমস্যার সমাধান করে না।

আদর্শভাবে, আমি মনে করি আপনি রূপক হিসাবে বৈশিষ্ট্যগুলি তুলনা করবেন, সুতরাং আপনার কাছে কোনও নতুন পদ্ধতি সংজ্ঞায়িত করা হবে না বা প্রতিবার যখন আপনি নতুন সংখ্যার বৈশিষ্ট্যের সেট তুলনা করতে চান তবে শাখাগুলি।

আমি সি # সম্পর্কে নিশ্চিত নই, তবে জাভাস্ক্রিপ্টে এর চেয়ে ভাল কিছু হতে পারে এবং কমপক্ষে ম্যাচস ডেফিনিশনআইডি এবং ম্যাচস প্যারেন্টআইড প্রতিস্থাপন করতে পারে

function compareContextProp(obj, property, value){
  if(obj[property])
    return obj[property] == value
  return false
}

Comments

সি # তে এরকম কিছু বাস্তবায়নে সমস্যা হওয়া উচিত নয়।

— স্নুপ

আমি দেখছি কিভাবে ~ 5 এর একটি বুলিয়ান সমন্বয় কল compareContextProp(propVal, "PropertyId", context.Definition.Id)ফর্মের ~ 5 তুলনা ওপি এর বুলিয়ান সমন্বয় চেয়ে পড়ার জন্য সহজ হবে propVal.PropertyId == context.Definition.Id। এটি উল্লেখযোগ্যভাবে দীর্ঘ এবং কল সাইট থেকে জটিলতার কোনও কিছুই না লুকিয়ে অতিরিক্ত স্তর যুক্ত করে। (যদি এটি গুরুত্বপূর্ণ হয় তবে আমি

— ডাউনওয়েট করিনি