Đặt tên cho các phương thức bool: Is vs. Can vs.

Cái tên nào tốt hơn cho một phương thức trả về boolean?

IsSupportContentType

hoặc là

CanSupportContentType

naming naming-standards

— Người hòa giải
nguồn

Vì mục đích là để tên truyền đạt rõ ràng trạng thái hoặc hành vi và bạn sẽ không bao giờ nói "lớp này là loại nội dung hỗ trợ X", nên tên tốt hơn là CanSupportContentType. Bạn sẽ nói một cái gì đó như "lớp này có thể hỗ trợ loại nội dung X."

— Craig

Không phải là một người bản xứ nhưng sẽ không Liệu SupportContentType là "ngữ pháp" tùy chọn nhất?

— Roman Reiner

Đầu tiên người ta phải IsSupportedContentTypeđúng về mặt ngữ pháp. (trừ khi "loại nội dung hỗ trợ" hoạt động như một danh từ, điều này dường như không thể xảy ra)

— CodeInChaos

Còn đơn giản supportsContentTypethì sao? Sau đây là hoàn toàn có thể đọc được : if (abc.supportsContentType("text/html")). "Có thể hỗ trợ" ngụ ý rằng có nhiều điều kiện hơn để hỗ trợ loại nội dung.

— Olivier Grégoire

@WeylandYutani IsCanHasSupportCheezburger?

— RM

Câu trả lời:

106

Là so với có thể

Theo khuyến nghị quy ước đặt tên của Microsoft , cả "Is" và "Can" đều ổn (và "Has") là tiền tố của Boolean.

Trong tiếng Anh đơn giản, "Is" sẽ được sử dụng để xác định một cái gì đó về chính loại đó, chứ không phải những gì nó có thể làm. Ví dụ, IsFixed, IsDerivedFrom, IsNullableđều có thể được tìm thấy trong các loại CLR và phương pháp. Trong tất cả các trường hợp này, "Is" được theo sau bởi một tính từ .

Trong khi đó, "có thể" rõ ràng hơn cho thấy một khả năng, ví dụ như CanEdit, CanRead, CanSeek. Trong mỗi trường hợp này, có thể được theo sau bởi một động từ .

Vì "Hỗ trợ" là một động từ, tôi nghĩ trong trường hợp của bạn CanSupportContentTypelà tốt hơn.

Thay thế ngắn hơn

Mặt khác, các quy ước nói rằng tiền tố là tùy chọn. Hơn nữa, thật là vui khi đưa loại đối số vào tên phương thức, vì nhà phát triển có thể thấy loại đối số trong intellisense. Vì vậy, bạn có thể chỉ cần đặt tên cho phương thức của bạn Supportsvà định nghĩa nó như thế này:

public bool Supports(System.Net.Mime.ContentType contentType)

... Đó là ngắn hơn và vẫn rõ ràng truyền đạt mục đích. Bạn sẽ gọi nó như thế này:

ContentType contentType = new ContentType("text/plain");
var someClass = new MediatorsClass();
bool ok = someClass.Supports(contentType);

Hoặc như một sự thỏa hiệp có lẽ điều này là tốt nhất:

public bool CanSupport(System.Net.Mime.ContentType contentType)

— John Wu
nguồn

Thật tuyệt khi nó đọc tốt:if ( someClass.Supports(contentType) )

— candied_orange

Ngày hoặchasSupportedContentType

— Bergi

Một phương pháp được gọi là "CanSupports" khởi đầu khiến tôi tự hỏi ai đã dành thời gian để làm cho phần mềm có thể hỗ trợ lon (như trong lon thiếc). Chỉ cần "Hỗ trợ" là lựa chọn tốt hơn, không còn nghi ngờ gì nữa!

— T. Sar - Phục hồi Monica

Đôi khi các nhà phát triển không thể biết khi nào một cái gì đó "nghe có vẻ kỳ lạ", ví dụ nếu tiếng Anh không phải là ngôn ngữ đầu tiên của họ.

— John Wu

Đôi khi một phiên bản ngắn hơn là tồi tệ hơn. Ví dụ, trong thư viện C ++ Standard chúng ta có std::vector::empty(). Chỉ từ tên của nó, nó có làm trống vector không? Hoặc nó trả về cho dù vector trống? Trên thực tế sau này, vì nhiệm vụ trước được thực hiện bởi std::vector::clear(). Nhưng nói chung bạn phải đọc tài liệu để chắc chắn. Một ví dụ ngược lại, Qt's QVectordễ hiểu hơn về vấn đề này, vì phương pháp kiểm tra sự trống rỗng của nó là QVector::isEmpty().

— Ruslan

Điều đáng nói là tiền tố " nên " cũng có thể được sử dụng. Theo hướng dẫn của Apple , không chỉ " có thể " và " nên ", các động từ phương thức nói chung có thể được sử dụng để đặt tên cho các hàm trả về boolean. Tôi không thể thấy nhiều cách sử dụng " ý chí " nhưng " nên " là tốt cho các câu hỏi tìm kiếm lời khuyên, như đã thấy trong Reacjs:

shouldComponentUpdate: (newProps: any) => boolean

— Harry
nguồn

Tôi nên đặt tên khá kém, "tốt, nó sẽ đóng tài liệu, nhưng tôi thực sự không chắc lắm"

— Lovis

@lovis: Tôi nghĩ nhận xét của Harry rất hợp lệ. Ví dụ: tôi có thể ủy quyền một số hành động liên quan đến cơ sở dữ liệu thông qua một lớp plugin, mỗi plugin có một phương thức "ShouldCloseConnection" thông báo cho khung công tác rằng một số dọn dẹp nên được thực hiện. Chỉ là một ví dụ, nhưng "nên" chắc chắn là một tiền tố hợp lệ.

— greg

@greg Làm thế nào mà ít mơ hồ hơn WillCloseConnection?

— Cơ bản

@Lovis Chúng ta thường sử dụng is...nhưng sử dụng should...trong một số tên đối số hàm, nơi mà boolean chỉ ra chức năng nào được cho là thay đổi mọi thứ . Nếu một chức năng có thể tùy chọn gần một tài liệu, kêu gọi tham số kiểm soát mà isClosedsẽ là chính xác (nó không phải đóng chưa ) và vì vậy chúng tôi sẽ sử dụng shouldCloseđể chỉ ra rằng đây là những gì hàm được nghĩa vụ phải làm. (Ví dụ tùy tiện; chúng tôi sẽ không có chức năng như thế này, đặc biệt vì việc đóng tài liệu phải đủ trọng lượng để có một cuộc gọi chuyên dụng.)

— KRyan

@Basic Ít nhất trong trường hợp của chúng tôi, will...được dành riêng cho các chức năng không đồng bộ trả lại lời hứa; nếu chức năng được mô tả trong nhận xét trước đây của tôi là đồng bộ, việc sử dụng will...sẽ không phù hợp với cách đặt tên của chúng tôi.

— KRyan