Czy powinienem wskazać błędy ortograficzne / gramatyczne w czyimś kodzie? [Zamknięte]

Przeglądając kod współpracownika, natknąłem się na niektóre błędy ortograficzne w nazwach funkcji, a także błędy gramatyczne, takie jak „doesUserHasPermission ()” zamiast „doesUserHavePermission ()” w nazwach funkcji i zmiennych.

Czy powinienem mu to wskazać, czy też jestem zbyt pedantyczny, zauważając je?

Kod z błędów ortograficznych i gramatycznych jest unmaintainable .

• Ludzie nie będą pamiętać złej gramatyki, więc spróbują wywołać funkcję tak, jak powinna być napisana, i tak właśnie się dzieje.

• Nie możesz grepować o coś w kodzie, jeśli nie wiesz, jak to się pisze.

• Większość osób, które tworzą gramatykę / pisownię, robi to niekonsekwentnie, dlatego wprowadzają wiele błędów związanych z niedopasowaniem nazw. Jest to szczególnie problematyczne w językach, które nie wymagają jawnego zadeklarowania zmiennych przed użyciem, ponieważ możesz wprowadzić nową pisownię, a twój kod nie zatrzyma się, by poinformować cię, że masz problemy.

Rozwiązanie tych problemów nie jest pedantyczne, nie jest też konieczne przede wszystkim przez opinie innych na temat inteligencji, umiejętności czytania itp. (Choć jest to duży efekt uboczny); chodzi o jakość pisania , łatwy do utrzymania kod .

Tak, zdecydowanie. Łatwiej zapamiętać nazwę, jeśli jest poprawna gramatycznie. Próba zapamiętania błędów w nazwie i gramatyce to zupełnie inna sprawa.

Nie wskazuj ich jako wad w formalnym przeglądzie kodu. Zamiast tego zaznacz wpis i porozmawiaj o nim PRYWATNIE. Bądź tak dyplomatyczny, jak to możliwe, po prostu „Hej, coś, co zauważyłem, i natknąłem się na ludzi, którzy NAPRAWDĘ nie patrzą na tego rodzaju rzeczy, myślą, że to sprawia, że ​​programista wygląda niedbale i niechlujnie”.

Jeśli jest to kod, który klient zobaczy, absolutnie MUSI zostać poprawiony. Czy ci się to podoba, czy nie, odzwierciedla on reputację twojej firmy.

W podanym przez ciebie przykładzie podejrzewam, że zaczął się on jako UserHasPermission, a ktoś inny powiedział mu, że lokalną praktyką jest raczej UserSlabaBlah () niż UserBlahBlah (), a on po prostu przeoczył zmianę gramatyki.

Zmień to sam.

Mamy nadzieję, że znajdujesz się w środowisku, w którym „własność” kodu nie stanowi problemu. Jeśli masz dostęp do projektu pod kontrolą źródła, po prostu wejdź i napraw go sam. Jeśli widzisz konkretnego współpracownika, który konsekwentnie popełnia ten sam rodzaj gramatyki lub błędy ortograficzne, możesz to wskazać, ale będzie to zależeć od twojego związku, tego, czy dana osoba jest rodzimym językiem angielskim, i jego ogólnej wrażliwości. Ale bez względu na to, czy zdecydujesz się to zrobić, czy nie, po prostu spokojnie i napraw. Robię to cały czas, jeśli widzę literówkę, szczególnie w sygnaturze metody lub we właściwości publicznej, po prostu to naprawiam. Czasami nie mogę się oprzeć pokusie poprawienia literówki w komentarzu, ale to tylko ja :)

Jestem programistą, którego językiem ojczystym nie jest angielski, a właściwie holenderski, i nie miałbym nic przeciwko, gdyby ktoś wskazał mi błąd gramatyczny lub ortograficzny. W ten sposób mogę ciągle doskonalić swój angielski. I z pewnością nie jest trudne poprawienie wszystkich błędów w całym kodzie źródłowym. Prosty skrypt Perla można łatwo napisać, aby przeglądać wszystkie pliki w folderze. Być może nawet można to zrobić za pomocą sed? Nie wiem

Z pewnością wskazałbym błędy gramatyczne lub ortograficzne w czyimś kodzie, ale tylko jeśli jestem absolutnie pewien, czy to prawda, co mówię.

Chyba warto tu wspomnieć, że nagłówek strony odsyłającej HTTP w protokole HTTP został błędnie zapisany jako „referer” (i musimy z tym żyć / nauczyliśmy się z nim żyć.) :)

Zgadzam się z innymi odpowiedziami, mówiąc, że kod z błędami gramatycznymi jest nie do utrzymania.

Chcę też dodać kilka rzeczy:

• Kod jest często pisany przez osoby, które nie mówią zbyt dobrze po angielsku i / lub angielski nie jest ich językiem ojczystym. Jeśli w sprawdzanym kodzie występuje błąd gramatyczny, nie oznacza to, że współpracownik popełnił ten błąd. Może to tylko kopia i wklej ze strony internetowej.
• Jeśli angielski nie jest językiem ojczystym twojego współpracownika, dobrym lub złym pomysłem może być poinformowanie go o tym błędzie. Będąc z Francji, zawsze z zadowoleniem przyjmuję uwagi na temat błędów, które popełniam w języku angielskim, ponieważ jest to jedyny sposób, aby uniknąć ich w przyszłości; z drugiej strony znam kilka osób, które czują się naprawdę zranione, jeśli powiesz im o popełnionych przez nich błędach gramatycznych.
• Jak powiedział John R. Strohm, nigdy nie rób tego publicznie. Większość ludzi będzie tym naprawdę zirytowana.

Polecam używanie IDE z wbudowanym sprawdzaniem pisowni. Idea IntelliJ wykonuje wspaniałą pracę dla programów Java. Jest wiele kłopotliwych literówek, które wychwytuje, nie tylko w nazwach funkcji, ale w np. Komunikatach wyjątków, które użytkownik widzi. Program, który generuje wiadomości pełne literówek, nie budzi zaufania.

Robię to tylko wtedy, gdy

• wpływa na korzystanie z programu
• wpływa na dokładność programu
• Wiem wyraźnie, że autor chce być poprawiony.

Na marginesie, jeśli nazwy funkcji są wystarczająco długie, aby mieć gramatykę, prawdopodobnie są one zbyt długie. W podanym przykładzie wywołałbym funkcję userHasPermission i przeniósłbym „gramatykę” do twojego kodu, mniej więcej tak:

if userHasPermission() ...

Zdarza się to również DUŻO w moim projekcie (zaludnionym przez native speakerów hebrajskich, rosyjskich lub arabskich), ale nawet na wyższym poziomie - często widzę kod, który używa niejasnej terminologii, która okazuje się być tym, co słownik utworzył jako tłumaczenie co autor miał na myśli i nie ma to nic wspólnego z tym, co mieli na myśli ...

Osobiście, gdy zdarza się to tak często i przez tak wielu członków zespołu, którzy mogliby napisać kod jeszcze przed przystąpieniem do projektu, zwykle go ignoruję, ponieważ to po prostu nie ma znaczenia.

Jeśli jednak popełniam trochę pracy w tym samym pliku, co kod lub komentarze, które zostały napisane dawno temu i mają literówki, poprawię je tylko dlatego, że nie jest to zbyt wiele pracy.

Obowiązuje złota zasada

Czyńcie innym, tak jak chcecie, aby wam to robili.

Chcę, żeby inni mieli tego rodzaju plecy, więc pomagam innym. Bycie łaskawym i wspierającym może przejść długą drogę na twoją korzyść.

Podobnie jak w przypadku wielu innych dobrych praktyk programistycznych, jedynym obiektywnym, niepolitycznym i skutecznym sposobem wdrożenia polityki dotyczącej pisowni w programach jest zautomatyzowanie jej w ramach procesu wstępnego zatwierdzenia. Automatyzacja uratuje cię od ogromnych skarg, nawet jeśli będziesz musiał napisać własne narzędzie do tego celu.

Jest to niewielki błąd w kodzie, ale jest błędem. Traktuj to jak każdy inny błąd, jaki znajdziesz. Moja polityka zawsze zakłada, że ​​moi współpracownicy są kompetentni i traktują ich w ten sposób, dopóki nie udowodnią inaczej.

Jeśli jest to pojedynczy błąd, mógłbym to naprawić i sprawdzić. Jeśli jest to wzorzec, mogę zacząć prosić współpracownika o sprawdzenie poprawek. Poinformuj ich, że uważasz, że są dobrym programistą, ale że jest to coś, co warto poprawić. Nie sądzę, żebym kiedykolwiek zrobił coś wielkiego na temat czegoś takiego.

Tak długo, jak nie traktujesz tego jako poważnego problemu, powinno być łatwo postawić tego współpracownika w sytuacji, w której można go poprawić bez narażania ego na ryzyko.

userPermission () może? -

Ostatnio natknąłem się na globalny problem braku wyników wyszukiwania, ponieważ nazwa klasy została przeliterowana. Bardzo niejasny błąd do wykrycia.

Oczywiście, zaznacz to, ale nie marnuj czasu na sprawdzanie błędów ortograficznych. Za pomocą narzędzia zautomatyzuj to w swoim CI. Na .net fxCop może to zrobić ...

Zależy to w dużej mierze od tego, jakie są błędy, jak często i jak bardzo są one złe, oraz od tego, czy to rzeczywiście bona fide błąd, czy też nie, jak byś to powiedział.

Ja osobiście nie mogę tego znieść, gdy jakiś idiota przeciąga 5-minutową recenzję kodu na pół godziny, ponieważ chce, aby wszystko przemianowano na sposób, w jaki to zrobi, i wszystkie komentarze zostały przeredagowane tylko dlatego, że lubi wsadzać wiosło. Wiersz logowania oznacza to, że „Ładowanie obiektów danych” nie musi być zmieniane na „Komponent modułu ładującego obiekty danych będzie teraz ładować odpowiednie obiekty danych z komponentu przechowywania obiektów danych”.

/ rant :)