„A”, „an” i „the” w nazwach metod i funkcji: Jakie masz zdanie? [Zamknięte]

Jestem pewien, że wielu z nas widziało kiedyś takie nazwy metod:

• UploadTheFileToTheServerPlease
• CreateATemporaryFile
• WriteTheRecordToTheDatabase
• ResetTheSystemClock

Oznacza to, że nazwy metod są również poprawnymi gramatycznie zdaniami angielskimi i zawierają dodatkowe słowa, które czynią je jak prozą. Osobiście nie jestem wielkim fanem takich „dosłownych” nazw metod i wolę być pomocny, a jednocześnie być tak jasny, jak to możliwe. Dla mnie słowa takie jak „a”, „an” i „the” wyglądają po prostu niezręcznie w nazwach metod i sprawia, że ​​nazwy metod są niepotrzebnie długie, bez dodawania niczego użytecznego. Wolę następujące nazwy metod dla poprzednich przykładów:

• UploadFileToServer
• CreateTemporaryFile
• WriteOutRecord
• ResetSystemClock

Z mojego doświadczenia wynika, że ​​jest to znacznie częstsze niż inne podejście polegające na pisaniu dłuższych nazw, ale widziałem oba style i byłem ciekawy, co myślą inni ludzie na temat tych dwóch podejść.

Czy jesteś w obozie „nazwy metod, które brzmią jak proza”, czy „nazwy metod, które mówią, co mam na myśli, ale czytają na głos, jak zły obóz tłumaczenia z języka obcego na angielski”?

Zgadzam się, że metody prozy są do kitu z jednym wyjątkiem:

Przypadki testu jednostkowego

Zazwyczaj nigdy nie są one wywoływane w kodzie i pojawiają się w raportach z testów. W związku z tym przydatne są odczyty z nieco większą prozą:

• AddacACustomerOrderFailWhenCustomersIdIsInvalid: nie powiodło się
• OutOfBoundsPriceReturnsAnError: Passed
• CanDeleteAnEventFromASeason: zaliczony

Nawet tego należy robić oszczędnie, ale widzę to jako co najmniej jeden przypadek, w którym dodatki gramatyczne mogą nieco ułatwić wyrażenie tego, co minęło, a co nie. Dzieje się tak, chyba że Twój język / framework zapewnia dobry mechanizm opisów testów w odczycie testu innym niż nazwy metod, w którym to przypadku zignoruj ​​również ten.

Parafrazując Lawrence'a z Office Space ...

Nie, nie, człowieku, wierzę, że jeśli ktoś, z kim tu pracowałem, nazwałby funkcję „UploadTheFileToTheServerPlease”, to on…

Takie „długie” nazwy nie brzmią jak proza . Gdy są sami - być może, ale wraz z resztą kodu, robią jeszcze więcej bałaganu. Sprawdź to:

bool ResultOfTheUpload
      = UploadTheFileToTheServerPlease(TheNameOfTheFile, TheServersAddress);

Yuuuuk! ..

To nie jest poprawny tekst w języku angielskim i w żadnym języku programowania nie będzie wyglądał jak jeden. Więc nie ma sensu wydawać bajtów na artykuły.

Z perspektywy programistów „UploadFileToServer” ma większy sens i jest łatwiejszy do odczytania i zrozumienia niż „UploadTheFileToTheServerPlease”.

Bardziej niż angielska gramatyka, czytelność i zrozumiałość mają większe znaczenie w programowaniu!

Biorąc pod uwagę, ile literówek ma moje życie, skończę

* UploadTehFileToTehServerPleaz
* WriteTehRecordToTehDatabase
* ResetTehSystemClock
* ICanHazTehCheezburger

Poważnie, spojrzałbym nawet na nazwę mojej klasy. Gdyby moja klasa nazywała się „Plik”, prawdopodobnie po prostu bym poszedł

*UploadToServer
*DownloadFromServer

Tak by było

   File file = new file;
   file.UploadtoServer(ServerAddress);

To tylko trywialny przykład, ale mam nadzieję, że jest to wystarczająco ilustracyjne.

Osobiście mnie to nie obchodzi. Widziałem ich i nie przeszkadzają mi. Nawet o nich nie myślałem, dopóki inny programista nie zaczął o nich mówić. Uznałem za szokujące, że komuś tak bardzo zależy na czymś, co tak mało ważne. Mam na myśli, że był z tego powodu zły. Ale to było na początku mojej kariery, około 11 lat temu, i od tego czasu odkryłem, że programiści gniewający się na drobne rzeczy są w rzeczywistości dość powszechny. To dlatego menedżerowie programistów tak dobrze zarabiają. Muszą codziennie kontaktować się z programistami.

Wolałbym to zobaczyć niż „UL_FlToSrv”.