Чи великий виразний вираз виразніше, ніж той самий вираз, розбитий на предикативні методи? [зачинено]

Що простіше зрозуміти, великий булевий вислів (досить складний) або той самий вислів, розбитий на методи предикатів (багато зайвого коду для читання)?

Варіант 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;
    }

Я вважаю за краще другий підхід, тому що назви методів розглядаю як коментарі, але розумію, що це проблематично, оскільки вам потрібно прочитати всі методи, щоб зрозуміти, що робить код, тому він абстрагує наміри коду.

Що простіше зрозуміти

Останній підхід. Це не тільки простіше зрозуміти, але і простіше писати, перевіряти, рефактор і розширювати. Кожну необхідну умову можна безпечно розв’язати і поводити по-своєму.

це проблематично, оскільки вам потрібно прочитати всі методи, щоб зрозуміти код

Це не проблематично, якщо методи названі правильно. Насправді, було б простіше зрозуміти, як назва методу описувала б умову умови.
Для глядача 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, IEquatableі комунальні послуги , як System.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))));

Це принаймні на півдорозі пристойно відформатовано (якщо форматування є складним, це тому, що умова if є складним), і у вас є принаймні шанс зрозуміти, чи є щось у ній дурниці. У порівнянні з вашим сміттям, відформатованим, якщо що-небудь ще краще. Але вам здається, що ви можете зробити лише крайнощі: або повне безладдя твердження 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;
}

Мені не подобається жодне з цих рішень, їх важко міркувати і важко читати. Абстрагування менших методів лише для менших методів не завжди вирішує проблему.

В ідеалі, я думаю, ви б метапрогматично порівнювали властивості, так що у вас немає визначення нового методу або якщо галузь кожен раз, коли ви хочете порівняти новий набір властивостей.

Я не впевнений у c #, але у javascript щось подібне було б МНОГО кращим і могло б принаймні замінити MatchesDefinitionId та MatchesParentId

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