Należy go delikatnie odradzać
.. nie możesz wiedzieć, kto zobaczy kod źródłowy przez cały okres jego istnienia.
Chociaż częścią frustracji jest szczególnie skomplikowany lub stary fragment kodu i chcesz o tym zabrzmieć, umieszczanie w kodzie źródłowym / rants / sztuki ASCII / złych dowcipów / obraźliwych uwag jest nieprofesjonalne i zły pomysł z mojego doświadczenia. Czasami inżynier piszący komentarze nie zdaje sobie sprawy z ewentualnych skutków, jakie mogą mieć jego komentarze - oto tylko niektóre z problemów, które widzę:
- Duża liczba przekleństw w kodzie udostępniona publicznie jako kod typu open source / sample.
- Żarty w złym guście powodują głęboką obrazę niektórych członków zespołu, co powoduje trybunał przemysłowy.
- Odrzucone uwagi, które w rzeczywistości były rasistowskie / seksistowskie / związane z płcią, powodowały zwolnienie ludzi.
Podczas gdy wszyscy potrzebujemy pewnych źródeł frustracji / zabawy / japing, kod źródłowy nie jest miejscem do tego, IMO. Nie umieszczałbyś przekleństw / żartów / obraźliwych komentarzy w umowie, stronach pomocy, planach lub innym profesjonalnym dokumencie, nawet jeśli dokumenty te mogą być czytane nawet rzadziej niż kod źródłowy.
Jeśli liderzy zespołów będą się tym zajmować, będzie to bardzo denerwujące, więc mówię „delikatnie zniechęcony” za pomocą cichego słowa z problematycznymi inżynierami i zapewniłem odpowiednie mechanizmy odpowietrzania, aby uwolnić parę, czy to Facebook, komunikatory internetowe , hokej na powietrzu lub worek treningowy.
Nie ma wątpliwości, że komentarze są kompilowane albo - co z JavaScriptem, czy innym dynamicznym kodem po stronie klienta?
Oto niektóre z moich rzeczywistych doświadczeń, które ukształtowały moją opinię:
Podczas pracy w firmie Microsoft zauważyłem, że jeden inżynier oprogramowania nie znał poprawnej pisowni słowa „nie mógł” - brakowało mu liter o, li id - i zasypał dużą część swojego kodu długimi wyjaśnieniami, w jaki sposób nie mógł zmusić X do pracy, ponieważ osoba Y powodowała problem Z. Jego kod był świetny; jego pisownia nie była tak dobra. Wystarczy powiedzieć, że każdy kolejny recenzent tego kodu (np. Ja) był zaniepokojony, widząc dużą liczbę losowych przekleństw w kodzie. Część tego kodu została następnie wyświetlona partnerom (autorom sterowników). Wyobraź sobie ich horror na widok przekleństw. Ranty idealnie powinny być kierowane do kierownika projektu w formie ustnej (w takim przypadku osoba Y może zostać wciągnięta do dyskusji) lub być może zatwierdzać wiadomości, ale nie w źródle.
W jednej firmie osoba mówiąca w języku obcym dołączyła do zespołu anglojęzycznego. Pisał komentarze w swoim języku, myśląc, że nikt inny nie może ich przeczytać. To było w porządku, dopóki Babelfish / Google Translate nie wydali opcji „na angielski” dla swojego języka, w którym to momencie reszta zespołu przetłumaczyła kilka komentarzy i była przerażona obrzydliwymi i często obraźliwymi komentarzami, które facet robił na temat firmy , jego zespół i współpracownik. Niewygodne .
W innej firmie jeden facet był naprawdę zajęty sztuką ASCII i umieścił wszelkiego rodzaju sztukę w swoim kodzie źródłowym, nie zauważony (a może pobłogosławiony) przez recenzentów kodu. Po pewnym czasie zamieszkał na smokach, z jakiegoś powodu, zwykle z jakimś rodzajem linii. Później do zespołu dołączyła walijka. Narodowym godłem Walii jest czerwony smok, więc nowy facet początkowo cieszył się ze zdjęć, ale potem obraził się, gdy niektóre głupie tagi można uznać za obraźliwe. Tak, wymagana jest mediacja lidera zespołu, ale to nie powinno się zdarzyć.
Nazwy / szczegóły zostały usunięte, aby chronić niewinnych.