1. Lekcje pisania? Nie całkiem.
Pisanie kodu źródłowego różni się wystarczająco od pisania książki.
Podczas gdy obaj dążą do tych samych celów: są tak jednoznaczni, jak to możliwe i są łatwi do zrozumienia, robią to w zupełnie inny sposób, a rzeczy, których pisarz powinien się nauczyć, nie są tym samym, co rzeczy, których powinien nauczyć się programista.
Przykład 1: liczby mówione
Liczby mowy są cenne podczas pisania powieści, poezji itp., Ponieważ zwiększają ekspresję pisania.
Kiedy ostatni raz widziałeś oksymoron lub litotes w kodzie źródłowym ? Czy pomogłoby to mieć je, czy raczej byłoby wyjątkowo szkodliwe dla każdego programisty, który będzie musiał później zachować taki kod źródłowy?
Przykład 2: słownictwo
Bogate słownictwo jest bardzo cenione w literaturze. Na przykład słownictwo Williama Szekspira wynosi od dwudziestu tysięcy do dwudziestu pięciu tysięcy słów. Bogatsze słownictwo sprawia, że czytanie powieści lub wiersza jest bardziej interesujące.
Kiedy piszesz kod źródłowy, oczekujesz, że zostanie on odczytany przez osoby, które nie mówią zbyt dobrze po angielsku . Wykazanie, jak dobrze znasz angielski, byłoby bardzo szkodliwe dla twojego kodu. Jeśli znasz fantazyjne słowo, które oznacza dokładnie to, czego potrzebujesz, ale wiesz, że wiele osób nie zna znaczenia tego słowa, powinieneś raczej znaleźć mniej wyrazisty synonim lub zestaw słów, które wyjaśniają znaczenie. Słownictwo składające się z kilku tysięcy słów jest często w dużej mierze wystarczające dla danego projektu.
Zwróć uwagę na ważny aspekt: chociaż Tłumacz Google może być bardzo pomocny dla osób, które nie są językiem ojczystym, istnieją dwa problemy z dowolnym tłumaczem:
Para języków niekoniecznie musi mieć dopasowanie 1: 1 między słowami. Niektóre słowa nie mają żadnego tłumaczenia na inne języki lub wiele słów może zostać przetłumaczonych na jedno słowo w języku obcym. Na przykład w języku rosyjskim istnieje ogromna liczba słów, które dotyczą konkretnych stanów śniegu i zimna, a tłumaczenie ich na francuski lub hiszpański jest zwykle niemożliwe bez utraty ich specyfiki.
Słowo czasami ma wiele znaczeń, a znaczenie wywodzi się z kontekstu. Tłumacz Google, mimo swojej wysokiej jakości, zwykle nie jest w stanie wskazać znaczenia w żadnej, z wyjątkiem najbardziej podstawowych sytuacji.
Przykład 3: wyrażenia
Wyrażenia również wzbogacają prozę. Autor oczekuje, że czytelnik będzie miał pewną ogólną kulturę i wykorzystuje tę okazję, aby tekst był bardziej wyrazisty.
Podobnie jak w poprzednim przykładzie, takie wyrażenia mogą być bardzo problematyczne, gdy czytają je osoby, które nie są native speakerem. Ale jeśli zwykle można przełożyć ogólne słownictwo, wyrażenia są znacznie bardziej problematyczne.
Na przykład angielski nie jest moim pierwszym językiem i na co dzień spotykam wyrażenia, w tym tutaj na StackExchange, których nie znam. Próbuję odgadnąć ich znaczenie, a czasem mam rację. Ale czasami się mylę, a Google wyrażenia te nie pomagają.
Użytkownik w swoim komentarzu przypomniał mi przykład, który sprawił, że cierpiałem przez długi czas, gdy dopiero zaczynałem programować: igła PHP i stóg siana . Nie byłem świadomy odpowiadającej mi wypowiedzi, więc za każdym razem, gdy czytałem dokumentację, zastanawiałem się, o co w tym wszystkim chodzi. Nie trzeba dodawać, że C # sequence.Contains(element)lub doskonałe Pythony element in sequencesą znacznie lepszą alternatywą. Cóż, przynajmniej programiści, którzy nie znają hebrajskiego, również musieli cierpieć na PHP , ale to inna historia.
Przykład 4: odniesienia kulturowe
Referencje kulturowe. W literaturze kuszące jest włączanie elementów z danej kultury, co także sprawia, że książka jest bogatsza, a czasem ciekawsza do czytania.
Kod jest jednak adresowany do programistów z całego świata. Dlatego to, co jest oczywistym odniesieniem dla włoskiego programisty, może nie być tak oczywiste dla rosyjskiego, a to, co wie każdy indyjski chłopiec lub dziewczynka, niekoniecznie musi być znane amerykańskiemu programistowi.
Ten sam użytkownik, który mówił o igle i stogu siana, podał także doskonały przykład takiego odniesienia kulturowego: Graala. Kto nie wie, co to jest Graal? Mam na myśli, że to „Graal” po francusku, „Grial” po hiszpańsku i… „Kutsal Kâse” po turecku, ale nadal. Ile jednak amerykańskich lub europejskich deweloperów zna średniowieczną historię Chin lub Indii? Dlaczego ktokolwiek miałby zakładać, że każdy programista z Chin i Indii musi znać odniesienie do Świętego Graala?
2. Lekcje pisania ekspresyjnego kodu źródłowego? Pewnie.
Każdy programista powinien nauczyć się pisać ekspresyjny kod źródłowy.
Każdy programista powinien wyjaśnić, dlaczego komentarz w:
int j = i + 1; // Creating i and adding 1 to it.
jest złe, pomijając fakt, że jest całkowicie błędne.
Każdy programista powinien być w stanie zrozumieć podstawowe refaktoryzowanie i sposób, w jaki pomaga uczynić kod źródłowy bardziej wyrazistym.
Każdy programista powinien pamiętać, że 20% czasu spędza się na tworzeniu kodu, a 80% na jego utrzymywaniu. W przypadku niektórych projektów jest to około 5% - 95%.
itp.
Zasadniczo programowanie jest zbliżone do dokumentacji technicznej. Czy osoba, która pisze specyfikację dla śruby, musi brać lekcje pisania? Nie całkiem. To samo dotyczy programistów. Każdy powinien pisać bez popełniania błędów ortograficznych w każdym słowie, a każdy powinien mieć możliwość wyraźnego przekazania swoich pomysłów. Poza tym nie jestem pewien, w jaki sposób lekcje pisania byłyby bardziej przydatne niż, powiedzmy, kurs informatyki, bezpieczeństwa IT czy cokolwiek innego.
Ekspresyjności kodu źródłowego można nauczyć się innymi sposobami. superM wspomniał o jednym z nich w swojej odpowiedzi : czytaniu dobrego kodu. Mogę wymienić kilka innych:
Czytanie książek takich jak Beautiful Code lub Code Complete,
Poproś bardziej doświadczonego programistę o sprawdzenie kodu,
Zrozumienie wzorców oraz tego, jak i kiedy ich używać.