Dòng bổ sung trong khối so với tham số bổ sung trong Clean Code

Bối cảnh

Trong Clean Code , trang 35, nó nói

Điều này ngụ ý rằng các khối trong câu lệnh if, câu lệnh khác, trong khi câu lệnh, v.v. nên dài một dòng. Có lẽ dòng đó nên là một chức năng gọi. Điều này không chỉ giữ cho hàm kèm theo nhỏ mà còn thêm giá trị tài liệu vì hàm được gọi trong khối có thể có một tên mô tả độc đáo.

Tôi hoàn toàn đồng tình, điều đó rất có ý nghĩa.

Sau đó, trên trang 40, nó nói về các đối số chức năng

Số lượng đối số lý tưởng cho một hàm là 0 (niladic). Tiếp đến là một (monadic), theo sát bởi hai (dyadic). Nên tránh ba đối số (bộ ba) nếu có thể. Hơn ba (polyadic) đòi hỏi sự biện minh rất đặc biệt và sau đó không nên sử dụng. Luận cứ thì khó. Họ có rất nhiều sức mạnh khái niệm.

Tôi hoàn toàn đồng tình, điều đó rất có ý nghĩa.

Vấn đề

Tuy nhiên, thay vào đó, tôi thường thấy mình tạo ra một danh sách từ một danh sách khác và tôi sẽ phải sống với một trong hai tệ nạn.

Hoặc là tôi sử dụng hai dòng trong khối , một để tạo điều, một để thêm nó vào kết quả:

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            Flurp flurp = CreateFlurp(badaBoom);
            flurps.Add(flurp);
        }
        return flurps;
    }

Hoặc tôi thêm một đối số vào hàm cho danh sách nơi điều sẽ được thêm vào, làm cho nó "một đối số tồi tệ hơn".

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            CreateFlurpInList(badaBoom, flurps);
        }
        return flurps;
    }

Câu hỏi

Có (không) những lợi thế mà tôi không thấy, điều này làm cho một trong số chúng thích hợp hơn nói chung? Hoặc có những lợi thế như vậy trong các tình huống nhất định; trong trường hợp đó, tôi nên tìm kiếm gì khi đưa ra quyết định?

Những hướng dẫn này là một la bàn, không phải là bản đồ. Họ chỉ cho bạn một hướng hợp lý . Nhưng họ thực sự không thể nói với bạn một cách tuyệt đối về giải pháp nào là tốt nhất. Tại một số điểm, bạn cần dừng bước vào hướng mà la bàn của bạn đang chỉ, bởi vì bạn đã đến đích.

Clean Code khuyến khích bạn chia mã của mình thành các khối rất nhỏ, rõ ràng. Đó là một hướng đi tốt. Nhưng khi được đưa đến mức cực đoan (như một cách giải thích theo nghĩa đen của lời khuyên được trích dẫn gợi ý), thì bạn sẽ chia mã của bạn thành các phần nhỏ vô dụng. Không có gì thực sự làm bất cứ điều gì, tất cả mọi thứ chỉ là đại biểu. Đây thực chất là một loại mã obfuscation.

Công việc của bạn là cân bằng giữa các nhóm nhỏ hơn là tốt hơn so với việc quá nhỏ là vô dụng. Hãy tự hỏi giải pháp nào đơn giản hơn. Đối với tôi, đó rõ ràng là giải pháp đầu tiên vì nó rõ ràng tập hợp một danh sách. Đây là một thành ngữ được hiểu rõ. Có thể hiểu mã đó mà không cần phải xem chức năng khác.

Nếu có thể làm tốt hơn, thì bằng cách lưu ý rằng, chuyển đổi tất cả các yếu tố từ danh sách này sang danh sách khác, là một mô hình phổ biến thường có thể được trừu tượng hóa bằng cách sử dụng một map()hoạt động chức năng . Trong C #, tôi nghĩ nó được gọi là Select. Một cái gì đó như thế này:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(BadaBoom => CreateFlurp(badaBoom)).ToList();
}

Số lượng đối số lý tưởng cho một hàm là 0 (niladic)

Không! Số lượng đối số lý tưởng cho một hàm là một. Nếu nó bằng 0, thì bạn đang đảm bảo rằng hàm phải truy cập thông tin bên ngoài để có thể thực hiện một hành động. "Chú" Bob hiểu điều này rất sai.

Về mã của bạn, ví dụ đầu tiên của bạn chỉ có hai dòng trong khối vì bạn đang tạo một biến cục bộ trên dòng đầu tiên. Xóa nhiệm vụ đó và bạn đang tuân thủ các nguyên tắc mã sạch này:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    List<Flurp> flurps = new List<Flurp>();
    foreach (BadaBoom badaBoom in badaBooms)
    {
        flurps.Add(CreateFlurp(badaBoom));
    }
    return flurps;
}

Nhưng đó là mã dài (C #). Chỉ cần làm như:

IEnumerable<Flurp> CreateFlurps(IEnumerable<BadaBoom> badaBooms) =>
    from badaBoom in babaBooms select CreateFlurp(badaBoom);

Lời khuyên 'Mã sạch' là hoàn toàn sai.

Sử dụng hai hoặc nhiều dòng trong vòng lặp của bạn. Ẩn hai dòng giống nhau trong một hàm có ý nghĩa khi chúng là một số toán học ngẫu nhiên cần một mô tả nhưng nó không làm gì khi các dòng đã được mô tả. 'Tạo' và 'Thêm'

Phương pháp thứ hai mà bạn đề cập trong thực sự không có ý nghĩa gì, vì bạn không bị buộc phải thêm đối số thứ hai để tránh hai dòng.

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            flurps.Add(badaBoom .CreateFlurp());
            //or
            badaBoom.AddToListAsFlurp(flurps);
            //or
            flurps.Add(new Flurp(badaBoom));
            //or
            //make flurps a member of the class
            //use linq.Select()
            //etc
        }
        return flurps;
    }

hoặc là

foreach(var flurp in ConvertToFlurps(badaBooms))...

Như đã lưu ý bởi những người khác, lời khuyên rằng chức năng tốt nhất là một chức năng không có đối số bị sai lệch với OOP ở mức tốt nhất và lời khuyên tồi tệ nhất là tồi tệ nhất

Thứ hai chắc chắn là tồi tệ hơn, vì CreateFlurpInListchấp nhận danh sách và sửa đổi danh sách đó, làm cho chức năng không thuần túy và khó lý luận hơn. Không có gì trong tên phương thức cho thấy phương thức chỉ thêm vào danh sách.

Và tôi cung cấp tùy chọn thứ ba, tốt nhất,:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(CreateFlurp).ToList();
}

Và chết tiệt, bạn có thể nội tuyến phương thức đó ngay lập tức nếu chỉ có một nơi được sử dụng, vì bản thân một lớp rõ ràng, vì vậy nó không cần phải được gói gọn bằng phương thức để cho nó có ý nghĩa.

Phiên bản một đối số là tốt hơn, nhưng không phải chủ yếu vì số lượng đối số.

Lý do quan trọng nhất là tốt hơn là nó có khớp nối thấp hơn , điều này làm cho nó hữu ích hơn, dễ lý luận hơn, dễ kiểm tra hơn và ít có khả năng biến thành bản sao + dán nhái.

Nếu bạn cung cấp cho tôi với một CreateFlurp(BadaBoom), tôi có thể sử dụng với bất kỳ loại của container sưu tập: Đơn giản Flurp[], List<Flurp>, LinkedList<Flurp>, Dictionary<Key, Flurp>, và vân vân. Nhưng với a CreateFlurpInList(BadaBoom, List<Flurp>), tôi sẽ quay lại với bạn vào ngày mai để yêu cầu chế độ CreateFlurpInBindingList(BadaBoom, BindingList<Flurp>)xem của tôi có thể nhận được thông báo rằng danh sách đã thay đổi. Kinh quá!

Là một lợi ích bổ sung, chữ ký đơn giản hơn có nhiều khả năng phù hợp với các API hiện có. Bạn nói rằng bạn có một vấn đề định kỳ

thay vào đó, tôi thường thấy mình tạo một danh sách từ một danh sách khác

Đó chỉ là vấn đề sử dụng các công cụ có sẵn. Phiên bản ngắn nhất, hiệu quả nhất và tốt nhất là:

var Flurps = badaBooms.ConvertAll(CreateFlurp);

Đây không chỉ là mã ít hơn để bạn viết và kiểm tra, nó còn nhanh hơn, bởi vì List<T>.ConvertAll()đủ thông minh để biết rằng kết quả sẽ có cùng số lượng mục với đầu vào và sắp xếp danh sách kết quả theo đúng kích thước. Trong khi mã của bạn (cả hai phiên bản) yêu cầu phát triển danh sách.

Giữ mục tiêu tổng thể trong tâm trí: làm cho mã dễ đọc và duy trì.

Thông thường, sẽ có thể nhóm nhiều dòng thành một hàm duy nhất, có ý nghĩa. Làm như vậy trong những trường hợp này. Đôi khi, bạn sẽ cần xem xét lại cách tiếp cận chung của bạn.

Ví dụ, trong trường hợp của bạn, thay thế toàn bộ triển khai bằng var

flups = badaBooms.Select(bb => new Flurp(bb));

có thể là một khả năng Hoặc bạn có thể làm một cái gì đó như

flups.Add(new Flurp(badaBoom))

Đôi khi, giải pháp sạch nhất và dễ đọc nhất sẽ không phù hợp với một dòng. Vì vậy, bạn sẽ có hai dòng. Đừng làm cho mã khó hiểu hơn, chỉ để thực hiện một số quy tắc tùy ý.

Ví dụ thứ hai của bạn là (theo tôi) khó hiểu hơn đáng kể so với lần đầu tiên. Không chỉ là bạn có tham số thứ hai, mà tham số đó được sửa đổi bởi hàm. Tra cứu những gì Clean Code nói về điều đó. (Không có cuốn sách trong tay ngay bây giờ, nhưng tôi khá chắc chắn về cơ bản là "đừng làm điều đó nếu bạn có thể tránh nó").