Nazewnictwo metod bool: Czy vs. Czy vs.

Jaka jest lepsza nazwa metody zwracającej wartość logiczną?

IsSupportContentType

lub

CanSupportContentType

Czy vs.

Zgodnie z zaleceniami konwencji nazewnictwa Microsoft zarówno „Is”, jak i „Can” są OK (podobnie jak „Has”) jako przedrostek logiczny.

W prostym języku angielskim, „Is” byłoby użyte do zidentyfikowania czegoś na temat samego typu, a nie tego, co może zrobić. Na przykład IsFixed, IsDerivedFrom, IsNullablemożna je znaleźć w CLR typów i metod. We wszystkich tych przypadkach po „Is” następuje przymiotnik .

Tymczasem, „może” bardziej wyraźnie wskazuje na możliwość, na przykład CanEdit, CanRead, CanSeek. W każdym z tych przypadków po może występować czasownik .

Ponieważ „Wsparcie” jest czasownikiem, myślę, że w twoim przypadku CanSupportContentTypejest to lepsze.

Krótsza alternatywa

Z drugiej strony konwencje mówią, że przedrostek jest opcjonalny. Co więcej, umieszczenie typu argumentu w nazwie metody jest trochę tandetne, ponieważ programista może zobaczyć typ argumentu w inteligencji. Więc mógł tylko wymienić metodę Supportsi zdefiniować ją tak:

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

... który jest krótszy i nadal jasno określa cel. Nazwałbyś to tak:

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

A może jako kompromis najlepiej:

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

Warto wspomnieć, że można również użyć prefiksu „ powinien ”. Zgodnie z wytycznymi Apple , nie tylko „ można ” i „ należy ”, czasowniki modalne w ogóle mogą być używane do nazwania funkcji zwracających wartość logiczną. Nie widzę wielu zastosowań „ woli ”, ale „ powinien ” jest miły dla haczyków pytających o porady, jak widać w reakjs:

shouldComponentUpdate: (newProps: any) => boolean