jak dowiedzieć się, czy błędy ortograficzne w kodzie źródłowym są poważnym problemem, czy nie? [Zamknięte]

W naszej bazie kodów znajduję bardzo niepokojącą liczbę błędów ortograficznych, z których odtworzę bardzo krótki, ale reprezentatywny przykład:

ArgumnetCount
Timeount
Gor message from queue 

Niestety nie jest to w żaden sposób ograniczone do jednej osoby. W naszym zespole jest wielu obcokrajowców mówiących po angielsku, ale mogę również wskazać najgorsze błędy ortograficzne naszego architekta oprogramowania, który jest Amerykaninem, urodził się i wychował.

Można je również znaleźć w wiadomościach e-mail, prezentacjach, dokumentach i wszelkich innych pisemnych informacjach, które posiadamy w firmie zajmującej się tworzeniem oprogramowania.

Chciałbym wiedzieć, jak sprawdzić, czy jest to poważny problem, czy nie?

_{Zawsze napotykałem te błędy ortograficzne z troską, ale moja osobista, oficjalna polityka głosi, że nie otrzymujemy zapłaty za prawidłowe pisanie, jesteśmy wynagradzani za wykonanie zadań, więc w firmie nigdy tak naprawdę nikogo nie krytykowałem. Ale poruszyłem ten problem z kilkoma moimi bliskimi przyjaciółmi i nigdy nie rozwiązałem go na dobre.}

Błędy ortograficzne mogą oznaczać jedną z dwóch rzeczy:

• Osoba, która je tworzy, nie jest biegła w języku angielskim i nie zajmuje czasu na zrekompensowanie tego za pomocą odpowiednich narzędzi (słowniki, sprawdzanie pisowni itp.)
• Osoba, która je tworzy, biegle włada językiem angielskim, ale w ogóle nie dba o pisownię.

Albo jest to dość zły znak, ponieważ oznacza, że ​​dana osoba nie ma czytelności, łatwości konserwacji i elegancji wysoko na liście priorytetów; jeśli przyczyną jest brak biegłości w języku angielskim, oznacza to również, że dana osoba nie ma dwóch podstawowych umiejętności - pisemnej komunikacji w języku angielskim i ogólnego wyczucia języków (jeśli nie potrafisz jasno wyrazić swoich myśli w języku angielskim, możliwe, że możesz ” dobrze je wyrażaj również w języku programowania).

Ale dlaczego dokładnie błędy pisowni są złe, a wszystkie inne są równe? W końcu kod działa, a kompilatorowi wcale nie zależy na tym, jak nazywasz swoje identyfikatory, o ile nie naruszają reguł składniowych. Powodem jest to, że piszemy kod nie tylko dla komputerów, ale także przede wszystkim dla ludzi. Gdyby tak nie było, nadal korzystalibyśmy z asemblera. Kod źródłowy jest zapisywany jeden raz, ale czytany setki razy w trakcie jego cyklu życia. Błędy ortograficzne utrudniają czytanie i rozumienie kodu źródłowego - łagodne błędy powodują, że czytelnik się potyka na ułamek sekundy, wiele z nich może powodować znaczne opóźnienia; naprawdę złe błędy mogą całkowicie uniemożliwić odczytanie kodu źródłowego. Jest jeszcze jeden problem, który polega na tym, że większość kodu, który piszesz, będzie odnosić się do innego kodu, a ten kod najczęściej jest pisany przez kogoś innego. Jeśli źle wpiszesz swoje identyfikatory, ktoś inny będzie musiał zapamiętać (lub spojrzeć w górę) nie tylko, jak się nazywa, ale także jak dokładnie jest napisane. To wymaga czasu i przerywa przebieg programowania; a ponieważ większość kodu jest dotykana podczas konserwacji więcej niż jeden raz, każdy błąd pisowni powoduje wiele zakłóceń.

Zastanów się, jak czas programisty równa się wynagrodzeniu i wydatkom, myślę, że powinno to być wystarczająco łatwe, aby to zrobić; w końcu przerwanie przepływu i powrót do niego może potrwać do 15 minut. W ten sposób poważny błąd pisowni może z łatwością kosztować kilkaset dolarów w dalszym rozwoju i utrzymaniu (ale są to koszty pośrednie, niewidoczne bezpośrednio w szacunkach i ocenach, więc często są ignorowane przez kierownictwo).

Właściwie wątpię, czy „Time Time” to kwestia bycia native speakerem. Ludzie robią mnóstwo literówek w swoim pierwszym języku. Nie zakwalifikowałbym tych konkretnych przykładów jako „Engrish”.

Powiedziawszy to, rozumiem, że nie chodzi o te konkretne przykłady. Zasadniczo się z tobą zgadzam. Natknąłem się na rzeczywiste problemy spowodowane przez tego rodzaju rzeczy („jeśli nie ma kolumny o nazwie załączniki, utwórz załączniki”).

Bycie programistą polega na precyzji i ostrożności w pisowni, przecinkach, średnikach i kropkach, które przez większość czasu są obojętne na język ludzki.

Gdy po raz pierwszy tracisz czas na szukanie Timeoutzmiennej, żeby się dowiedzieć, że została napisana Timeount, poznasz inny powód, dla którego pisownia jest ważna.

Jeśli ten problem Ci przeszkadza, większość IDE zezwala teraz na sprawdzanie pisowni w komentarzach, dzięki czemu dyslektycy mogą przynajmniej wyglądać, jakby umieli pisać. To na pewno mi pomaga! Dlatego trywialna „poprawka” ma dobrą pisownię.

Błędy ortograficzne w nazwach i metodach klas publicznych są po prostu nieprofesjonalne. Kosztują czas i pieniądze. Są bolesne w statycznie typowanych językach, takich jak Java, gdzie IDE może tworzyć menu nazw klas i metod. Nie można ich tolerować w dynamicznie pisanych językach.

Jeszcze gorzej są błędy ortograficzne w nazwach tabel baz danych i nazw kolumn.

Z mojego doświadczenia wynika, że ​​poprawna pisownia jest tylko nieznacznie związana z biegłą znajomością języka angielskiego przez programistę. Widziałem rodzimych użytkowników języka angielskiego tworzących kod z zasadniczo losową pisownią i podziałami wyrazów, a także widziałem osoby, które nie są rodzimymi użytkownikami języka angielskiego, które starają się tworzyć poprawną pisownię. Ale poprawna pisownia jest ściśle związana z ogólną jakością kodu. Zdolni programiści, bez względu na ich znajomość języka angielskiego, dbają o jakość swojej pracy i są ostrożni w nazywaniu.

W kodzie źródłowym, wewnętrznych prezentacjach i dokumentach itp. Małe literówki, które nie zmieniają znaczenia ani nie utrudniają zrozumienia, nie stanowią problemu. Po prostu napraw je w źródle, jeśli uważasz, że są irytujące.

Również, szczególnie w komentarzach, substancja jest ważniejsza niż forma. Tutaj nie ma angielskiego:

Ciąg s = „Wikipedia”; / * Przypisuje wartość „Wikipedia” do zmiennej s. * /

Faktem jest, że niektórzy ludzie są naturalnie ostrożniejszymi pisarzami niż inni (czy to z powodu wykształcenia, czy z powodu postawy, czy też inteligencji czy cokolwiek innego, nie ma to znaczenia). Ile wysiłku poświęcić na naprawę, to jest pytanie o wartość biznesową: czy zarabiasz więcej na poprawianiu literówek, niż na wysiłku na ich naprawianiu? W przypadku rzeczy wewnętrznych odpowiedź zazwyczaj brzmi „nie”. Twoi klienci nie będą narzekać na literówki w komentarzach do kodu źródłowego (chyba że robisz open source).

Celowe błędne pisanie i nieodpowiednie komentarze są nieprofesjonalne i należy ich unikać, ale należy skupić się na rzeczach, które mają znaczenie (tj. Generować wartość biznesową, jeśli pracujesz dla firmy).

Rzeczy publicznie widoczne muszą oczywiście zostać dokładnie sprawdzone.

Problemem nie jest tutaj sama engrish, ale brak jasności komentarzy. Doskonały angielski nie jest konieczny, jasny angielski jest. To proste, aby uruchomić coś przez Google, aby wykryć oczywiste błędy.

Na przykład na pierwszy rzut oka nie jest jasne, czy Gor message from queueoznacza „otrzymał wiadomość z kolejki” lub „komunikat GOR z kolejki”. Musisz przeczytać kod, aby zrozumieć znaczenie komentarza (pokonując w ten sposób obiekt komentarza).

Powinieneś poprosić o wdrożenie recenzji kodu w swojej firmie. Następnie możesz „krytykować” ludzi w konstruktywny sposób, podczas gdy oni robią to samo wobec ciebie.

Powinno być oczywiste, że kompilator nie przejmuje się pisownią, o ile używasz tej samej pisowni, np. Podczas odwoływania się do zmiennej. Powstaje zatem pytanie, czy błędy ortograficzne mają negatywny wpływ na zdolność członków zespołu do utrzymania kodu.

Jedyny sposób, w jaki mogę to zrobić, to porozmawiać z ludźmi zajmującymi się konserwacją, a możesz zacząć od pytania, czy ktokolwiek miałby trudności z przestrzeganiem kodu zawierającego błędy ortograficzne.

Nie sądzę, że istnieje sposób na całkowite usunięcie subiektywności z tego problemu, ale aby go zmniejszyć, możesz (ręcznie lub za pomocą skryptu) zeskanować źródło, aby uzyskać szacunkową liczbę błędów ortograficznych dla określonego modułu kodu i sprawdzić, czy konserwacja na modułach z większą liczbą błędów ortograficznych zajęło średnio więcej czasu niż moduły z mniejszą liczbą błędów ortograficznych.

Oczywiście nie wszystkie moduły są sobie równe, więc możesz pomyśleć o ważeniu wyników za pomocą różnych wskaźników, takich jak cykliczna złożoność modułu.

Z mojego doświadczenia wynika, że ​​takie podstawowe błędy ortograficzne są niepokojące i mogą wskazywać na głębsze problemy. Każdy projekt, nad którym pracowałem z takimi „trywialnymi” błędami, miał poważne problemy z projektowaniem, które jakoś przeszły przez proces przeglądu tylko po to, aby pojawiać się podczas opracowywania, a nie wtedy, gdy chcesz dowiedzieć się, że tak ważna funkcjonalność jest naprawdę potrzebna nie ma.

Jeszcze raz sprawdzę specyfikacje systemu (jeśli istnieją) i zbadam ogólny projekt; Nie zdziwiłbym się, gdybyś znalazł jakieś dziury.

To właściwie dwa oddzielne, ale powiązane ze sobą problemy. To zależy od tego, gdzie są błędy ortograficzne:

1) W kodzie źródłowym. Jeśli masz taki identyfikator ArgumnetCount, może to powodować prawdziwe problemy, gdy ktoś przyjdzie i użyje poprawnej pisowni. Więc powinieneś naprawić te błędy, gdy tylko jest to możliwe. Jeśli chcesz zachować kompatybilność wsteczną API, możesz zrobić coś takiego:

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2) W tekście czytelnym dla człowieka (e-maile, dokumentacja, komentarze do kodu). Prawidłowe pisanie jest ważne, ale powiedziałbym, że ma niższy priorytet, ponieważ oprogramowanie parsujące w twojej głowie jest o wiele bardziej wybaczające. Jeśli zobaczysz tekst z kilkoma błędami, nadal jest on czytelny, nie przejmuj się - to nie twój problem. Ale jeśli ktoś wyśle ​​ci jakieś nonsensowne bzdury i spodziewa się, że użyjesz tego nonsensu jako schematu aplikacji internetowej dla wielu użytkowników, powinieneś wysłać autorowi uprzejmą notatkę z prośbą o wyjaśnienie (coś w rodzaju: „Anonimowy kretyn, jak to zrobić oczekujesz, że zrozumiem to gówno? ”)

Prawidłowo napisany angielski jest koniecznością w kodzie. Mam też dużą bazę kodową pełną bełkotu i to koszmar do utrzymania.

Nie pozwól, aby wymknęło się to spod kontroli. Staraj się uświadomić wszystkim, że opiekunowie kodu nie są czytelnikami umysłu.

To jest wielostronny problem kulturowy.

Mówiąc z niemieckiego punktu widzenia: zauważamy, że nasz własny język staje się coraz bardziej pod wpływem angielskich terminów. Dotyczy to firm krajowych, które mają angielskie hasła lub reklamy. Niektóre osoby, zwłaszcza na stanowiskach kierowniczych, najwyraźniej nie potrafią wypowiedzieć tylko jednego zdania po niemiecku. Ich mowa jest pełna gwarnych słów i niezrozumiałego slangu zarządzania. Mówimy, że takie osoby mówią „po angielsku”.

Biorąc pod uwagę ten stan rzeczy i angielski jako „lingua franca”, szczególnie w branży oprogramowania, nieuniknione jest, że na język angielski wpływa ogromna liczba osób, które nie znają tego języka. Ale dla rodzimych użytkowników języka angielskiego jest to wciąż lepsze niż konieczność nauki języka chińskiego, aby wziąć udział w branży SW.

Czy to kolor czy kolor? Jak myślisz, czyja wersja języka angielskiego jest poprawna? Jedna poprawna pisownia to inna wymówka, by rozpocząć wojnę, którą można wygrać.

Jeśli chcesz rozpocząć wojnę, wybierz bitwy ostrożnie i wygraj je. W twoim przypadku nie martw się o komentarze, mniej martw się o elementy wewnętrzne i skup się (prawie) wyłącznie na interfejsach API

Mam maksymę: uporządkowany kod niekoniecznie oznacza uporządkowany umysł, ale awers jest z pewnością prawdziwy: nieporządny kod, nieporządny umysł.

Programiści, którzy nie poświęcają czasu na prawidłowe nazywanie zmiennych i pisownię komentarzy, prawie na pewno nie poświęcają czasu na robienie czegokolwiek innego poprawnie. To, czy programista jest rodzimym językiem angielskim, nie jest prawdziwym problemem, ponieważ problemy z jego angielskim można (i należy) rozwiązać podczas przeglądu.

Tak, to poważny problem dla produktu, zespołu i poszczególnych osób.

• Dla produktu: korekta może wprowadzić wady, które są wykrywane wyłącznie przez klientów
• Dla zespołu: zespół spędza czas na poprawianiu niechlujnego kodowania, a nie na tworzeniu wartości
• Dla osób fizycznych: zła pisownia sprawia, że ​​wyglądasz głupio i obniża twoją pozycję zawodową wśród rówieśników.