Chỉ định tên tham số tùy chọn mặc dù không bắt buộc?

Hãy xem xét phương pháp sau:

public List<Guid> ReturnEmployeeIds(bool includeManagement = false)
{

}

Và cuộc gọi sau:

var ids = ReturnEmployeeIds(true);

Đối với một nhà phát triển mới sử dụng hệ thống, sẽ rất khó đoán những gì trueđã làm. Điều đầu tiên bạn làm là di chuột qua tên phương thức hoặc đi đến định nghĩa (không phải trong số đó là nhiệm vụ lớn trong một chút). Nhưng, vì mục đích dễ đọc, nên viết:

var ids = ReturnEmployeeIds(includeManagement: true);

Có bất cứ nơi nào, chính thức, thảo luận về việc có hay không chỉ định rõ ràng các tham số tùy chọn khi trình biên dịch không cần bạn không?

Bài viết sau đây thảo luận về các quy ước mã hóa nhất định: https://msdn.microsoft.com/en-gb/l Library / ff926074.aspx

Một cái gì đó tương tự như bài viết ở trên sẽ là tuyệt vời.

Tôi muốn nói rằng trong thế giới C #, một enum sẽ là một trong những lựa chọn tốt nhất ở đây.

Với điều đó, bạn buộc phải đánh vần những gì bạn đang làm và bất kỳ người dùng nào cũng sẽ thấy những gì đang xảy ra. Nó cũng an toàn cho các tiện ích mở rộng trong tương lai;

public enum WhatToInclude
{
    IncludeAll,
    ExcludeManagement
}

var ids = ReturnEmployeeIds(WhatToInclude.ExcludeManagement);

Vì vậy, theo ý kiến ​​của tôi ở đây:

enum> enum tùy chọn> bool tùy chọn

Chỉnh sửa: Do thảo luận với LeopardSkinPillBoxHat bên dưới về [Flags]enum mà trong trường hợp cụ thể này có thể phù hợp (vì chúng tôi đặc biệt đang nói về việc bao gồm / loại trừ mọi thứ), thay vào đó tôi đề xuất sử dụng ISet<WhatToInclude>làm tham số.

Đó là một khái niệm "hiện đại" hơn với một số lợi thế, chủ yếu xuất phát từ thực tế là nó phù hợp với họ các bộ sưu tập LINQ, nhưng cũng [Flags]có tối đa 32 nhóm. Nhược điểm chính của việc sử dụng ISet<WhatToInclude>là làm thế nào các bộ xấu được hỗ trợ trong cú pháp C #:

var ids = ReturnEmployeeIds(
    new HashSet<WhatToInclude>(new []{ 
        WhatToInclude.Cleaners, 
        WhatToInclude.Managers});

Một số có thể được giảm thiểu bằng các hàm trợ giúp, cả để tạo tập hợp và tạo "bộ phím tắt", chẳng hạn như

var ids = ReturnEmployeeIds(WhatToIncludeHelper.IncludeAll)

nó có ý nghĩa để viết:

 var ids=ReturnEmployeeIds(includeManagement: true);

Thật đáng tranh luận nếu đây là "phong cách tốt", nhưng IMHO đây không phải là phong cách xấu, và hữu ích, miễn là dòng mã không trở nên "quá dài". Không có tham số được đặt tên, đó cũng là một kiểu phổ biến để giới thiệu một biến giải thích:

 bool includeManagement=true;
 var ids=ReturnEmployeeIds(includeManagement);

Phong cách đó có lẽ phổ biến hơn đối với các lập trình viên C # so với biến thể tham số được đặt tên, vì các tham số được đặt tên không phải là một phần của ngôn ngữ trước Phiên bản 4.0. Hiệu quả về khả năng đọc gần như giống nhau, nó chỉ cần một dòng mã bổ sung.

Vì vậy, khuyến nghị của tôi: nếu bạn nghĩ sử dụng enum hoặc hai hàm với các tên khác nhau là "quá mức" hoặc bạn không muốn hoặc không thể thay đổi chữ ký vì một lý do khác, hãy tiếp tục và sử dụng tham số được đặt tên.

Nếu bạn gặp mã như:

public List<Guid> ReturnEmployeeIds(bool includeManagement = false)
{

}

bạn có thể đảm bảo khá nhiều thứ bên trong {}sẽ giống như:

public List<Guid> ReturnEmployeeIds(bool includeManagement = false)
{
    if (includeManagement)
        return something
    else
        return something else
}

Nói cách khác, boolean được sử dụng để lựa chọn giữa hai khóa hành động: phương thức có hai trách nhiệm. Điều này là khá nhiều đảm bảo một mùi mã . Chúng ta nên luôn cố gắng để đảm bảo rằng các phương pháp chỉ làm một việc; họ chỉ có một trách nhiệm. Do đó, tôi cho rằng cả hai giải pháp của bạn đều là cách tiếp cận sai. Sử dụng các tham số tùy chọn là một dấu hiệu cho thấy phương thức đang làm nhiều hơn một điều. Các tham số Boolean cũng là một dấu hiệu của điều này. Có cả hai chắc chắn nên đặt chuông báo thức. Do đó, điều bạn nên làm là tái cấu trúc hai bộ chức năng khác nhau thành hai phương thức riêng biệt. Đặt tên cho các phương thức làm rõ những gì chúng làm, ví dụ:

public List<Guid> GetNonManagementEmployeeIds()
{

}

public List<Guid> GetAllEmployeeIds()
{

}

Điều này vừa cải thiện khả năng đọc mã, vừa đảm bảo bạn tuân thủ tốt hơn các nguyên tắc RẮN.

EDIT Như đã được chỉ ra trong các bình luận, trường hợp ở đây là hai phương thức này có thể sẽ có chức năng chia sẻ và chức năng được chia sẻ đó có khả năng tốt nhất sẽ được bọc trong một chức năng riêng sẽ cần một tham số boolean để kiểm soát một số khía cạnh của nó. .

Trong trường hợp này, có nên cung cấp tên tham số không, mặc dù trình biên dịch không cần nó? Tôi đề nghị không có câu trả lời đơn giản cho điều đó và cần phải có sự phán xét trong từng trường hợp cụ thể:

• Đối số để chỉ định tên, là các nhà phát triển khác (bao gồm cả bạn trong sáu tháng) sẽ là đối tượng chính của mã của bạn. Trình biên dịch chắc chắn là một đối tượng thứ cấp. Vì vậy, luôn luôn viết mã để giúp người khác dễ đọc hơn; thay vì chỉ cung cấp những gì trình biên dịch cần. Một ví dụ về cách chúng tôi sử dụng quy tắc này mỗi ngày, là chúng tôi không điền mã của mình bằng các biến _1, _2, v.v., chúng tôi sử dụng các tên có ý nghĩa (không có nghĩa gì với trình biên dịch).
• Đối số truy cập là phương thức riêng là chi tiết thực hiện. Một cách hợp lý có thể mong đợi bất cứ ai nhìn vào một phương thức như dưới đây, sẽ theo dõi mã để hiểu mục đích của tham số boolean khi chúng ở bên trong phần bên trong của mã:

public List<Guid> GetNonManagementEmployeeIds()
{
    return ReturnEmployeeIds(true);
}

Là tập tin nguồn, và các phương thức, nhỏ và dễ hiểu? Nếu có, thì tham số được đặt tên có thể lên tới nhiễu. Nếu không, nó có thể rất hữu ích. Vì vậy, áp dụng các quy tắc theo hoàn cảnh.

Đối với một nhà phát triển mới sử dụng hệ thống, sẽ khá khó để đoán được điều gì thực sự đã làm. Điều đầu tiên bạn làm là di chuột qua tên phương thức hoặc đi đến định nghĩa (không phải trong số đó là nhiệm vụ lớn nhất)

Vâng đúng. Mã tài liệu tự là một điều đẹp. Như các câu trả lời khác đã chỉ ra, có nhiều cách để loại bỏ sự mơ hồ của cuộc gọi ReturnEmployeeIdsbằng cách sử dụng enum, các tên phương thức khác nhau, v.v. Tuy nhiên, đôi khi bạn không thể thực sự tránh trường hợp này nhưng bạn không muốn tắt và sử dụng chúng ở khắp mọi nơi (trừ khi bạn thích tính dài dòng của hình ảnh cơ bản).

Ví dụ, nó có thể giúp làm rõ một cuộc gọi nhưng không nhất thiết phải là một cuộc gọi khác.

Một đối số có tên có thể hữu ích ở đây:

var ids = ReturnEmployeeIds(includeManagement: true);

Không thêm nhiều sự rõ ràng bổ sung (Tôi sẽ đoán rằng đây là phân tích một enum):

Enum.Parse(typeof(StringComparison), "Ordinal", ignoreCase: true);

Nó thực sự có thể làm giảm sự rõ ràng (nếu một người không hiểu khả năng trong danh sách là gì):

var employeeIds = new List<int>(capacity: 24);

Hoặc nơi không quan trọng vì bạn đang sử dụng tên biến tốt:

bool includeManagement = true;
var ids = ReturnEmployeeIds(includeManagement);

Có bất cứ nơi nào, chính thức, thảo luận về việc có hay không chỉ định rõ ràng các tham số tùy chọn khi trình biên dịch không cần bạn không?

Không phải AFAIK. Mặc dù vậy, chúng ta hãy giải quyết cả hai phần: lần duy nhất bạn cần sử dụng rõ ràng các tham số được đặt tên là vì trình biên dịch yêu cầu bạn làm như vậy (nói chung là để loại bỏ sự mơ hồ của câu lệnh). Vì vậy, ngoài việc bạn có thể sử dụng chúng bất cứ khi nào bạn muốn. Bài viết này của MS có một số gợi ý về thời điểm bạn có thể muốn sử dụng chúng nhưng nó không đặc biệt dứt khoát https://msdn.microsoft.com/en-us/l Library / dd264739.aspx .

Cá nhân, tôi thấy tôi sử dụng chúng thường xuyên nhất khi tôi tạo các thuộc tính tùy chỉnh hoặc tìm ra một phương thức mới trong đó các tham số của tôi có thể thay đổi hoặc được sắp xếp lại (các thuộc tính có tên b / c có thể được liệt kê theo bất kỳ thứ tự nào). Ngoài ra, tôi chỉ sử dụng chúng khi tôi đang cung cấp một giá trị tĩnh nội tuyến, nếu không, nếu tôi chuyển một biến tôi cố gắng sử dụng tên biến tốt.

TL; DR

Cuối cùng, nó đi xuống sở thích cá nhân. Tất nhiên có một vài trường hợp sử dụng khi bạn phải sử dụng các tham số được đặt tên nhưng sau đó bạn cần thực hiện một cuộc gọi phán xét. IMO - Sử dụng nó ở bất cứ đâu mà bạn tin rằng nó sẽ giúp ghi lại mã của bạn, giảm sự mơ hồ hoặc cho phép bạn bảo vệ chữ ký phương thức.

Nếu tham số rõ ràng từ tên (đủ điều kiện) của phương thức và sự tồn tại của nó là tự nhiên đối với những gì phương thức được cho là làm, bạn không nên sử dụng cú pháp tham số đã đặt tên. Ví dụ, ReturnEmployeeName(57)rõ ràng đó 57là ID của nhân viên, do đó, không cần thiết phải chú thích nó với cú pháp tham số đã đặt tên.

Với ReturnEmployeeIds(true), như bạn đã nói, trừ khi bạn xem khai báo / tài liệu của hàm thì không thể hiểu được truenghĩa là gì - vì vậy bạn nên sử dụng cú pháp tham số đã đặt tên.

Bây giờ, hãy xem xét trường hợp thứ ba này:

void PrintEmployeeNames(bool includeManagement) {
    foreach (id; ReturnEmployeeIds(includeManagement)) {
        Console.WriteLine(ReturnEmployeeName(id));
    }
}

Cú pháp tham số được đặt tên không được sử dụng ở đây, nhưng vì chúng ta đang truyền một biến cho ReturnEmployeeIdsvà biến đó có một tên và tên đó xảy ra có nghĩa tương tự như tham số mà chúng ta truyền cho nó (thường là trường hợp này - nhưng không phải lúc nào cũng vậy!) - chúng ta không cần cú pháp tham số được đặt tên để hiểu ý nghĩa của nó từ mã.

Vì vậy, quy tắc rất đơn giản - nếu bạn có thể dễ dàng hiểu từ phương thức gọi tham số nghĩa là gì, đừng sử dụng tham số đã đặt tên. Nếu bạn không thể - đó là sự thiếu hụt về khả năng đọc của mã và có lẽ bạn muốn sửa chúng (tất nhiên không phải bằng bất cứ giá nào, nhưng bạn thường muốn mã có thể đọc được). Khắc phục không phải đặt tên tham số - bạn cũng có thể đặt giá trị vào một biến trước hoặc sử dụng các phương thức được đề xuất trong các câu trả lời khác - miễn là kết quả cuối cùng giúp bạn dễ hiểu tham số đó làm gì.

Vâng, tôi nghĩ đó là phong cách tốt.

Điều này có ý nghĩa nhất đối với các hằng số Boolean và số nguyên.

Nếu bạn chuyển vào một biến, tên biến sẽ làm cho ý nghĩa rõ ràng. Nếu không, bạn nên đặt tên cho biến tốt hơn.

Nếu bạn chuyển qua một chuỗi, ý nghĩa thường rõ ràng. Giống như nếu tôi thấy một cuộc gọi đến GetFooData ("Oregon"), tôi nghĩ rằng một người đọc có thể đoán khá nhiều rằng tham số đó là một tên trạng thái.

Tất nhiên không phải tất cả các chuỗi là rõ ràng. Nếu tôi thấy GetFooData ("M") thì trừ khi tôi biết chức năng tôi không biết "M" nghĩa là gì. Nếu đó là một loại mã nào đó, như M = "nhân viên cấp quản lý", thì có lẽ chúng ta nên có một enum thay vì theo nghĩa đen và tên enum phải rõ ràng.

Và tôi cho rằng một chuỗi có thể gây hiểu nhầm. Có thể "Oregon" trong ví dụ của tôi ở trên đề cập đến, không phải cho tiểu bang, mà là một sản phẩm hoặc khách hàng hoặc bất cứ điều gì.

Nhưng GetFooData (đúng) hoặc GetFooData (42) ... điều đó có thể có nghĩa gì cả. Các tham số được đặt tên là một cách tuyệt vời để làm cho nó tự ghi lại. Tôi đã sử dụng chúng cho chính xác mục đích đó trong một số dịp.

Không có bất kỳ lý do siêu rõ ràng nào là tại sao lại sử dụng loại cú pháp này ngay từ đầu.

Nói chung, cố gắng tránh có các đối số boolean mà ở khoảng cách có thể trông tùy ý. includeManagementsẽ (rất có thể) ảnh hưởng đến kết quả rất nhiều. Nhưng đối số có vẻ như mang "trọng lượng nhỏ".

Việc sử dụng một enum đã được thảo luận, nó không chỉ trông giống như đối số "mang nhiều trọng lượng hơn", mà còn cung cấp khả năng mở rộng cho phương thức. Tuy nhiên, đây có thể không phải là giải pháp tốt nhất trong mọi trường hợp, vì tính năng của bạn ReturnEmployeeIdssẽ phải mở rộng cùng với WhatToInclude-enum (xem câu trả lời của NiklasJ ). Điều này có thể khiến bạn đau đầu sau này.

Xem xét điều này: Nếu bạn chia tỷ lệ WhatToInclude-enum, nhưng không phải là ReturnEmployeeIds-method. Sau đó, nó có thể ném một ArgumentOutOfRangeException(trường hợp tốt nhất) hoặc trả lại một cái gì đó hoàn toàn không mong muốn ( nullhoặc trống List<Guid>). Mà trong một số trường hợp có thể gây nhầm lẫn cho lập trình viên, đặc biệt nếu bạn ReturnEmployeeIdsđang ở trong thư viện lớp, nơi mã nguồn không có sẵn.

Người ta sẽ cho rằng WhatToInclude.Traineessẽ hoạt động nếu WhatToInclude.Allcó, thấy rằng các thực tập sinh là một "tập hợp con" của tất cả.

Điều này không (tất nhiên), phụ thuộc vào cách ReturnEmployeeIds thực hiện.

Trong trường hợp một đối số boolean có thể được truyền vào, thay vào đó tôi cố gắng chia nó thành hai phương thức (hoặc nhiều hơn, nếu cần), trong trường hợp của bạn; người ta có thể trích xuất ReturnAllEmployeeIds, ReturnManagementIdsvà ReturnRegularEmployeeIds. Điều này bao gồm tất cả các cơ sở và hoàn toàn tự giải thích cho bất cứ ai thực hiện nó. Điều này cũng sẽ không có quy mô "mở rộng", được đề cập ở trên.

Vì chỉ có hai kết quả cho một cái gì đó có một đối số boolean. Thực hiện hai phương pháp, mất rất ít nỗ lực.

Ít mã hơn, hiếm khi tốt hơn.

Với điều này đã nói, có là một số trường hợp rõ ràng tuyên bố đối số cải thiện khả năng đọc. Xem xét ví dụ. GetLatestNews(max: 10). GetLatestNews(10)là vẫn khá tự giải thích, tuyên bố rõ ràng về maxý chí giúp làm sáng tỏ bất kỳ sự nhầm lẫn.

Và nếu bạn hoàn toàn phải có một đối số boolean, việc sử dụng không thể được suy ra bằng cách chỉ đọc truehoặc false. Sau đó tôi sẽ nói rằng:

var ids = ReturnEmployeeIds(includeManagement: true);

.. hoàn toàn tốt hơn và dễ đọc hơn:

var ids = ReturnEmployeeIds(true);

Vì trong ví dụ thứ hai, truecó thể có nghĩa là hoàn toàn bất cứ điều gì . Nhưng tôi sẽ cố gắng tránh tranh luận này.