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

15

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.

Andrei G.
źródło
4
Zagłosowano do zamknięcia jako nie na temat. Nie jest to związane z programowaniem, ale z dowolną domeną, w której ludzie piszą, od komentarzy na YouTube po zawartość stron internetowych. Niektórzy ludzie po prostu nie dbają o swoje pisanie i sprawdzanie pisowni. Z przyjemnością tworzą swoją dużą witrynę internetową e-commerce, która ma trzy błędy we własnym tytule, napisane dużą czcionką na stronie głównej. I niestety większość użytkowników tej witryny e-commerce też by się tym nie przejmowała.
Arseni Mourzenko
5
@MainMa: pisanie w języku programowania wystarczająco różni się od pisania w języku ludzkim. Pisząc dla komentarzy na YouTube, jest całkowicie oczywiste, że piszesz dla ludzkich czytelników, ale w przypadku kodu źródłowego powszechne jest to, że dopóki kompiluje się i działa, wszystko jest w porządku.
tdammers
2
@tdammers: kiedy piszesz kod źródłowy lub pytanie na Stack Exchange, książkę, komentarz na YouTube lub treść strony głównej Twojej witryny e-commerce, w każdym przypadku robisz to dla osób, które czytają to. Programowanie nie jest inne, a twój kompilator nie dba o to, czy nazwiesz swoją zmienną ArgumentCountczy ArgumnetCount.
Arseni Mourzenko
16
Głosowanie w celu ponownego otwarcia. Komentarze w kodzie bardzo różnią się od komentarzy w innych mediach i muszą przekazywać złożone informacje w zwięzły sposób. Nie zgadzam się, że wszystkie są takie same
Tom Squires

Odpowiedzi:

19

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).

tdammers
źródło
5
Chciałbym dodać, że błędy ortograficzne mogą spowodować trudne do debugowania problemów gdzie thisVaraiblei thisVariablewyglądzie prawie takie same i są „technicznie” poprawne.
Spencer Rathbun
6
+1, ale stwierdzenie: „jeśli nie potrafisz jasno wyrazić swoich myśli w języku angielskim, istnieje duże prawdopodobieństwo, że nie potrafisz dobrze wyrazić ich w języku programowania”, to kompletny nonsens!
Martin Ba
2
@Martin: Nie znalazłem jeszcze światowej klasy programisty o okropnym stylu pisania. Wszyscy najlepsi programiści, których znam, potrafią także pisać zwięzły, jasno sformułowany angielski; niektóre z nich (Knuth, Dijkstra) są nawet nieco znane ze swojego stylu pisania.
tdammers
5
@tdammers: Jeśli są anglojęzycznymi użytkownikami, zgodziłbym się. Ale jeśli masz inny język ojczysty, możesz mieć dość okropną znajomość języka angielskiego i nadal być dobrym programistą. To miałem na myśli z nonsensem. Zgadzam się, że dobrzy programiści potrafią również dobrze pisać - w jakimkolwiek naturalnym języku, w którym są biegli. (Trochę angielski oczywiście pomaga znaleźć drogę w sieci, ale w żadnym wypadku nie musisz być biegły lub dobry pisarz lub znasz gramatykę lub styl po angielsku :-)
Martin Ba
5
Zwróć uwagę, że Dijkstra nie jest ojczystym językiem ...
tdammers
9

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.

Konrad Morawski
źródło
9

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.

Eric King
źródło
7

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ę.

Sardathrion - przeciw nadużyciom SE
źródło
2
Jeśli oddaliście głos, czy moglibyście poświęcić trochę czasu na wyjaśnienie, dlaczego mogę poprawić moją odpowiedź?
Sardathrion - przeciwko nadużyciom SE
6
Nie głosowałem, ale tak naprawdę nie odpowiadasz na jego pytanie. Poradzisz, jak uniknąć błędów ortograficznych. To jest całkowicie poprawny komentarz, ale nie o to poprosił OP.
Konrad Morawski
6

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.

Kevin Cline
źródło
5

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.

Joonas Pulakka
źródło
2
Powiedz mi, że celowo wpisałeś „porblem”. :)
pdr
2
Oczywiście, że tak. Jeśli uznasz to za irytujące, możesz to naprawić;)
Joonas Pulakka
2
O nie. Uważam to za oburzająco zabawne.
pdr
6
„Niektórzy ludzie są bardziej ostrożnymi pisarzami ...” Tak, a ci sami ludzie są bardziej uważnymi programistami. Nie spotkałem jeszcze dobrego programisty, który nie był również ostrożny w komunikacji pisemnej.
kevin cline
4

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.

Tom Squires
źródło
2

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.

Mike Partridge
źródło
Mike, rozbieżność odpowiedzi i pytanie jest ostatnią masową edycją . Do wersji 3 tytuł pytania brzmiał: Co sądzisz o dodawaniu kodu źródłowego? i tekst był w dużej mierze zgodny z tym
komnata
To ma sens @gnat; Usunąłem dodatkowy akapit z mojej odpowiedzi.
Mike Partridge
2

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.

John Bode
źródło
1

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? ”)

Mike Baranczak
źródło
-1

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.

linkerro
źródło
1
„Staraj się edukować wszystkich” - tak zrobiłem, a teraz źle napisali / źle napisali różne rzeczy, aby mnie wkurzyć. Uwielbiam to ...
MetalMikester
5
@MetalMikester: być może czas poszukać bardziej profesjonalnego sklepu.
kevin cline
-1

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.

Ingo
źródło
-1

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

mattnz
źródło
-3

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.
Christopher Williams
źródło
4
wydaje się, że nie oferuje to nic istotnego w stosunku do punktów przedstawionych i wyjaśnionych w poprzednich 14 odpowiedziach. Nie warto obijać 3-letniego pytania takimi treściami
komara