นิพจน์บูลีนขนาดใหญ่สามารถอ่านได้มากกว่านิพจน์เดียวกันที่แบ่งออกเป็นวิธีเพรดิเคตหรือไม่ [ปิด]

จะเข้าใจอะไรได้ง่ายกว่าคำสั่งบูลีนขนาดใหญ่ (ค่อนข้างซับซ้อน) หรือคำเดียวกันนี้แบ่งออกเป็นเมธอดเพรดิเคต (มีโค้ดพิเศษมากมายให้อ่าน)

ตัวเลือก 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;
    }

ฉันชอบวิธีที่สองเพราะฉันเห็นชื่อวิธีเป็นความคิดเห็น แต่ฉันเข้าใจว่ามันเป็นปัญหาเพราะคุณต้องอ่านวิธีการทั้งหมดเพื่อทำความเข้าใจว่าโค้ดทำอะไรดังนั้นจึงสรุปเจตนาของโค้ด

สิ่งที่เข้าใจง่ายกว่าคือ

แนวทางหลัง มันไม่เพียง แต่ง่ายต่อการเข้าใจ แต่ยังง่ายกว่าในการเขียนทดสอบ refactor และขยายอีกด้วย แต่ละเงื่อนไขที่ต้องการสามารถแยกได้อย่างปลอดภัยและจัดการในแบบของตัวเอง

มันเป็นปัญหาเพราะคุณต้องอ่านวิธีการทั้งหมดเพื่อทำความเข้าใจโค้ด

มันไม่มีปัญหาหากวิธีการตั้งชื่ออย่างถูกต้อง ในความเป็นจริงมันจะง่ายต่อการเข้าใจเป็นชื่อวิธีจะอธิบายถึงเจตนาของเงื่อนไข
สำหรับผู้สังเกตการณ์if MatchesDefinitionId()นั้นมีคำอธิบายมากกว่าif (propVal.PropertyId == context.Definition.Id)

[โดยส่วนตัววิธีแรกที่ทำให้ตาของฉันเจ็บ]

หากนี่เป็นเพียงที่เดียวที่จะใช้ฟังก์ชันเพรดิเคตเหล่านี้คุณสามารถใช้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ใช้ตรรกะ AND กับHasValueคุณสมบัติที่ถูกทำให้ยุ่งเหยิงในขณะที่matchesSecondaryFilterใช้ตรรกะ AND บนที่ไม่ถูกปฏิเสธHasValue- ดังนั้นจึงไม่ใช่สิ่งที่ตรงกันข้าม

โดยทั่วไปแล้วจะนิยมใช้หลัง

ทำให้ไซต์การโทรสามารถนำมาใช้ซ้ำได้มากขึ้น รองรับ DRY (หมายถึงคุณมีสถานที่น้อยกว่าที่จะเปลี่ยนเมื่อเกณฑ์เปลี่ยนแปลงและสามารถทำได้มากขึ้นอย่างน่าเชื่อถือ) และบ่อยครั้งที่เกณฑ์ย่อยเหล่านี้เป็นสิ่งที่จะถูกนำมาใช้ซ้ำได้อย่างอิสระที่อื่นช่วยให้คุณทำเช่นนั้นได้

โอ้และมันทำให้การทดสอบหน่วยนี้ง่ายขึ้นมากให้ความมั่นใจกับคุณว่าคุณทำถูกต้องแล้ว

หากอยู่ระหว่างตัวเลือกทั้งสองตัวเลือกหลังจะดีกว่า อย่างไรก็ตามสิ่งเหล่านี้ไม่ใช่ตัวเลือกเท่านั้น! วิธีการเกี่ยวกับการแบ่งฟังก์ชั่นเดียวออกเป็นหลาย ๆ ifs? ทดสอบหาวิธีออกจากฟังก์ชั่นเพื่อหลีกเลี่ยงการทดสอบเพิ่มเติมโดยจำลอง "ลัดวงจร" ในการทดสอบบรรทัดเดียว

สิ่งนี้ง่ายต่อการอ่าน (คุณอาจต้องตรวจสอบตรรกะอีกครั้งสำหรับตัวอย่างของคุณ แต่แนวคิดนั้นมีจริง):

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;   
}

ฉันชอบตัวเลือก 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);
}

เหตุผลที่ฉันแนะนำนี่คือการตรวจสอบสองรายการเป็นหน่วยการทำงานเดียวและการซ้อนวงเล็บในเงื่อนไขมีข้อผิดพลาดเกิดขึ้นได้ง่าย: ทั้งจากมุมมองของการเขียนรหัสเริ่มต้นและจากมุมมองของบุคคลที่อ่าน โดยเฉพาะอย่างยิ่งในกรณีที่องค์ประกอบย่อยของนิพจน์ไม่เป็นไปตามรูปแบบเดียวกัน

ฉันไม่แน่ใจว่าMatchesSecondaryFilterIfPresent()เป็นชื่อที่ดีที่สุดสำหรับชุดค่าผสมหรือไม่ แต่ไม่มีอะไรดีกว่าที่จะนึกขึ้นมาทันที

แม้ว่าใน C # รหัสไม่เชิงวัตถุมาก มันใช้วิธีการคงที่และสิ่งที่ดูเหมือนว่าสนามคงที่ (เช่นrepo) โดยทั่วไปแล้วจะถือได้ว่าสถิตศาสตร์ทำให้โค้ดของคุณยากต่อการปรับโครงสร้างและยากที่จะทดสอบในขณะที่การขัดขวางการนำกลับมาใช้ใหม่และสำหรับคำถามของคุณ: การใช้งานแบบคงที่เช่นนี้ไม่สามารถอ่านได้

คุณควรแปลงรหัสนี้เป็นรูปแบบเชิงวัตถุมากขึ้น เมื่อคุณทำเช่นนี้คุณจะพบว่ามีสถานที่ที่เหมาะสมในการใส่รหัสที่ทำการเปรียบเทียบวัตถุของเขตข้อมูล ฯลฯ เป็นไปได้ว่าคุณสามารถขอให้วัตถุเปรียบเทียบตัวเองซึ่งจะลดขนาดใหญ่ลงถ้าคำสั่งเป็น คำของ่าย ๆ ในการเปรียบเทียบ (เช่นif ( a.compareTo (b) ) { }ซึ่งอาจรวมถึงการเปรียบเทียบข้อมูลทั้งหมด)

C # มีชุดอินเตอร์เฟสและยูทิลิตีของระบบจำนวนมากสำหรับทำการเปรียบเทียบกับวัตถุและฟิลด์ นอกเหนือจากที่เห็นได้ชัด.Equalsวิธีการสำหรับการเริ่มดูเป็นIEqualityComparer, และสาธารณูปโภคเช่นIEquatableSystem.Collections.Generic.EqualityComparer.Default

อย่างหลังนี้เป็นที่ต้องการแน่นอนฉันได้เห็นกรณีที่มีวิธีแรกและมันเกือบจะเป็นไปไม่ได้ที่จะอ่าน ฉันทำผิดวิธีแรกและถูกขอให้เปลี่ยนเป็นวิธีอธิบาย

ฉันจะบอกว่าทั้งสองเป็นเรื่องเดียวกันถ้าคุณเพิ่มช่องว่างสำหรับการอ่านและความคิดเห็นบางส่วนเพื่อช่วยให้ผู้อ่านในส่วนที่คลุมเครือมากขึ้น

โปรดจำไว้ว่า: คำวิจารณ์ที่ดีจะบอกผู้อ่านว่าคุณคิดอย่างไรเมื่อคุณเขียนโค้ด

ด้วยการเปลี่ยนแปลงเช่นที่ฉันแนะนำฉันอาจจะไปกับแนวทางก่อนหน้านี้เพราะมันรกและกระจายน้อยลง การเรียกรูทีนย่อยเหมือนกับเชิงอรรถ: พวกเขาให้ข้อมูลที่เป็นประโยชน์ แต่ขัดขวางการไหลของการอ่าน ถ้าภาคแสดงมีความซับซ้อนมากขึ้นฉันก็จะแยกพวกมันออกเป็นวิธีการแยกเพื่อให้แนวคิดที่พวกเขารวบรวมสามารถสร้างขึ้นในกลุ่มที่เข้าใจได้

ถ้ามีชิ้นส่วนที่คุณอาจต้องการนำมาใช้ซ้ำการแยกส่วนเหล่านั้นออกเป็นฟังก์ชันที่ตั้งชื่ออย่างเหมาะสมนั้นเป็นแนวคิดที่ดีที่สุด
แม้ว่าคุณอาจจะไม่เคยนำมาใช้ใหม่, การทำเช่นนั้นอาจจะช่วยให้คุณดีกว่าโครงสร้างเงื่อนไขของคุณและให้พวกเขามีป้ายอธิบายสิ่งที่พวกเขาหมายถึง

ตอนนี้ลองมาดูตัวเลือกแรกของคุณและยอมรับว่าไม่มีการเยื้องและการแบ่งบรรทัดของคุณทั้งหมดที่มีประโยชน์และไม่มีโครงสร้างแบบมีเงื่อนไขที่ดีทั้งหมด:

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);
}

คนแรกน่ากลัวจริงๆ คุณใช้ | | สำหรับสองสิ่งในบรรทัดเดียวกัน นั่นเป็นข้อบกพร่องในรหัสของคุณหรือมีเจตนาที่จะทำให้งงงวยรหัสของคุณ

    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))));

นั่นคือการจัดรูปแบบ decently อย่างน้อยครึ่งหนึ่ง (หากการจัดรูปแบบมีความซับซ้อนนั่นเป็นเพราะ if-condition นั้นซับซ้อน) และคุณมีโอกาสอย่างน้อยที่จะทราบว่ามีสิ่งใดที่ไร้สาระ เปรียบเทียบกับขยะที่คุณจัดรูปแบบถ้ามีอย่างอื่นดีกว่า แต่ดูเหมือนว่าคุณจะสามารถทำได้แค่สุดขั้ว: ไม่ว่าจะเป็นคำสั่ง if ที่สมบูรณ์หรือสี่วิธีที่ไร้จุดหมายอย่างสมบูรณ์

โปรดทราบว่า (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;
}

ฉันไม่ชอบวิธีแก้ปัญหาทั้งสองวิธีพวกเขาทั้งคู่ยากที่จะให้เหตุผลและอ่านยาก วิธีการย่อขนาดเล็กเพียงเพื่อประโยชน์ที่มีขนาดเล็กลงไม่ได้แก้ปัญหาเสมอไป

ฉันคิดว่าคุณจะเปรียบเทียบคุณสมบัติของ metaprogrmatically ดังนั้นคุณจึงไม่ได้กำหนดวิธีการใหม่หรือแยกสาขาทุกครั้งที่คุณต้องการเปรียบเทียบชุดคุณสมบัติใหม่

ฉันไม่แน่ใจเกี่ยวกับ c # แต่ในจาวาสคริปต์บางอย่างเช่นนี้จะดีขึ้นมากและอย่างน้อยก็สามารถแทนที่ MatchesDefinitionId และ MatchesParentId ได้

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