Là một biểu thức boolean lớn dễ đọc hơn biểu thức tương tự được chia thành các phương thức vị ngữ? [đóng cửa]

Điều gì dễ hiểu hơn, một câu lệnh boolean lớn (khá phức tạp) hoặc cùng một câu lệnh được chia thành các phương thức vị ngữ (rất nhiều mã bổ sung để đọc)?

Tùy chọn 1, biểu thức boolean lớn:

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

Tùy chọn 2, Các điều kiện được chia thành các phương thức vị ngữ:

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

Tôi thích cách tiếp cận thứ hai, vì tôi xem tên phương thức là nhận xét, nhưng tôi hiểu rằng nó có vấn đề vì bạn phải đọc tất cả các phương thức để hiểu mã làm gì, vì vậy nó trừu tượng hóa ý định của mã.

Những gì dễ hiểu hơn

Cách tiếp cận sau. Nó không chỉ dễ hiểu hơn mà còn dễ viết, kiểm tra, tái cấu trúc và mở rộng hơn. Mỗi điều kiện cần có thể được tách rời và xử lý một cách an toàn theo cách riêng của nó.

nó có vấn đề vì bạn phải đọc tất cả các phương pháp để hiểu mã

Sẽ không có vấn đề gì nếu các phương thức được đặt tên đúng. Trong thực tế, nó sẽ dễ hiểu hơn vì tên phương thức sẽ mô tả ý định của điều kiện.
Đối với một người xem if MatchesDefinitionId()là giải thích nhiều hơnif (propVal.PropertyId == context.Definition.Id)

[Cá nhân, cách tiếp cận đầu tiên làm tôi lo lắng.]

Nếu đây là nơi duy nhất các hàm vị ngữ này sẽ được sử dụng, bạn cũng có thể sử dụng các boolbiến cục bộ:

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

Chúng cũng có thể được chia nhỏ hơn và sắp xếp lại để làm cho chúng dễ đọc hơn, ví dụ như với

bool hasSecondaryFilter = propVal.SecondaryFilter.HasValue;

và sau đó thay thế tất cả các trường hợp propVal.SecondaryFilter.HasValue. Một điều ngay lập tức được đưa ra là hasNoSecondaryFiltersử dụng logic AND trên các HasValuethuộc tính bị phủ định , trong khi matchesSecondaryFiltersử dụng logic AND không bị phủ định HasValue- vì vậy nó không hoàn toàn ngược lại.

Nói chung, sau này được ưa thích.

Nó làm cho các trang web cuộc gọi tái sử dụng nhiều hơn. Nó hỗ trợ DRY (có nghĩa là bạn có ít nơi để thay đổi khi tiêu chí thay đổi và có thể làm điều đó đáng tin cậy hơn). Và rất thường những tiêu chí phụ đó là những thứ sẽ được sử dụng lại một cách độc lập ở nơi khác, cho phép bạn làm điều đó.

Ồ, và nó làm cho công cụ này dễ dàng hơn rất nhiều để kiểm tra đơn vị, giúp bạn tự tin rằng bạn đã thực hiện đúng.

Nếu đó là giữa hai lựa chọn này, thì lựa chọn sau là tốt hơn. Đây không phải là sự lựa chọn duy nhất, tuy nhiên! Làm thế nào về việc chia nhỏ chức năng đơn thành nhiều if? Kiểm tra các cách để thoát khỏi chức năng để tránh các thử nghiệm bổ sung, mô phỏng gần như "ngắn mạch" trong thử nghiệm một dòng.

Điều này dễ đọc hơn (bạn có thể cần kiểm tra lại logic cho ví dụ của mình, nhưng khái niệm này vẫn đúng):

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

Tôi thích tùy chọn 2 tốt hơn, nhưng sẽ đề xuất một thay đổi cấu trúc. Kết hợp hai kiểm tra trên dòng cuối cùng của điều kiện thành một cuộc gọi duy nhất.

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

Lý do tôi đề nghị điều này là hai kiểm tra là một đơn vị chức năng duy nhất và dấu ngoặc đơn lồng trong một điều kiện dễ bị lỗi: Cả hai từ quan điểm ban đầu viết mã và từ quan điểm của người đọc nó. Điều này đặc biệt xảy ra nếu các thành phần phụ của biểu thức không theo cùng một mẫu.

Tôi không chắc MatchesSecondaryFilterIfPresent()là tên tốt nhất cho sự kết hợp; nhưng không có gì tốt hơn là ngay lập tức đến với tâm trí.

Mặc dù trong C #, mã không hướng đối tượng. Nó đang sử dụng các phương thức tĩnh và trông giống như các trường tĩnh (ví dụ repo). Thông thường người ta cho rằng các số liệu thống kê làm cho mã của bạn khó tái cấu trúc và khó kiểm tra, trong khi cản trở khả năng sử dụng lại, và, cho câu hỏi của bạn: sử dụng tĩnh như thế này ít đọc và duy trì hơn so với xây dựng hướng đối tượng.

Bạn nên chuyển đổi mã này sang một hình thức hướng đối tượng hơn. Khi bạn làm như vậy, bạn sẽ thấy rằng có những nơi hợp lý để đặt mã so sánh các đối tượng, của các trường, v.v. Có khả năng sau đó bạn có thể yêu cầu các đối tượng tự so sánh, điều này sẽ làm giảm câu lệnh if lớn của bạn yêu cầu đơn giản để so sánh (ví dụ if ( a.compareTo (b) ) { }, có thể bao gồm tất cả các so sánh trường.)

C # có một bộ giao diện và tiện ích hệ thống phong phú để thực hiện so sánh trên các đối tượng và các lĩnh vực của chúng. Ngoài rõ ràng .Equalsphương pháp, đối với người mới bắt đầu, nhìn vào IEqualityComparer, IEquatablevà các tiện ích như System.Collections.Generic.EqualityComparer.Default.

Loại thứ hai chắc chắn được ưa thích, tôi đã thấy các trường hợp với cách đầu tiên và hầu như không thể đọc được. Tôi đã phạm sai lầm khi thực hiện nó theo cách đầu tiên và được yêu cầu thay đổi nó thành các phương thức vị ngữ.

Tôi sẽ nói rằng hai cái này giống nhau, NẾU bạn thêm một số khoảng trắng để dễ đọc và một số bình luận để giúp người đọc vượt qua những phần khó hiểu hơn.

Hãy nhớ rằng: bình luận tốt cho người đọc biết bạn đang nghĩ gì khi viết mã.

Với những thay đổi như tôi đã đề xuất, tôi có thể sẽ đi theo cách tiếp cận trước đây, vì nó ít lộn xộn và lan tỏa hơn. Các cuộc gọi chương trình con giống như chú thích: chúng cung cấp thông tin hữu ích nhưng làm gián đoạn dòng đọc. Nếu các vị từ phức tạp hơn, thì tôi sẽ chia chúng thành các phương thức riêng biệt để các khái niệm mà chúng thể hiện có thể được xây dựng thành các phần dễ hiểu.

Chà, nếu có những phần bạn có thể muốn sử dụng lại, tách chúng ra thành các chức năng được đặt tên riêng biệt rõ ràng là ý tưởng tốt nhất.
Ngay cả khi bạn có thể không bao giờ sử dụng lại chúng, làm như vậy có thể cho phép bạn cấu trúc tốt hơn các điều kiện của mình và cung cấp cho chúng một nhãn mô tả ý nghĩa của chúng .

Bây giờ, hãy xem xét tùy chọn đầu tiên của bạn và thừa nhận rằng cả thụt lề và ngắt dòng của bạn đều không hữu ích, cũng không phải là điều kiện có cấu trúc tốt như vậy:

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

Điều đầu tiên là hoàn toàn khủng khiếp. Bạn đã và đang sử dụng | | cho hai điều trên cùng một dòng; đó là một lỗi trong mã của bạn hoặc có ý định làm xáo trộn mã của bạn.

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

Điều đó ít nhất là nửa chừng được định dạng (nếu định dạng phức tạp, đó là vì điều kiện if phức tạp) và bạn có ít nhất một cơ hội để tìm hiểu xem có gì vô lý không. So với rác của bạn được định dạng nếu, bất cứ điều gì khác là tốt hơn. Nhưng dường như bạn chỉ có thể thực hiện các thái cực: Hoặc là một mớ hỗn độn của một câu lệnh if hoặc bốn phương thức hoàn toàn vô nghĩa.

Lưu ý rằng (cond1 && cond2) || (! cond1 && cond3) có thể được viết là

cond1 ? cond2 : cond3

Điều này sẽ làm giảm sự lộn xộn. Tôi sẽ viết

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

Tôi không thích một trong những giải pháp đó, cả hai đều khó lý luận và khó đọc. Trừu tượng hóa các phương thức nhỏ hơn chỉ dành cho các phương thức nhỏ hơn vì không phải lúc nào cũng giải quyết được vấn đề.

Lý tưởng nhất, tôi nghĩ rằng bạn sẽ so sánh các thuộc tính siêu hình, vì vậy bạn không có định nghĩa một phương thức mới hoặc nếu nhánh mỗi khi bạn muốn so sánh một tập các thuộc tính mới.

Tôi không chắc chắn về c #, nhưng trong javascript, một cái gì đó như thế này sẽ tốt hơn và ít nhất có thể thay thế MatchesDefDefId và MatchesParentId

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