Radzenie sobie z wulgaryzmami w kodzie źródłowym [zamknięte]

Jak ludzie radzą sobie z wulgaryzmami w kodzie źródłowym i komentarzach VCS. Zachować czy usunąć?

A co z soft-expletives, takimi jak WTF lub Arrgggh?

Czy jest nieprofesjonalny, obraźliwy, czy może należy go odrzucić?

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.

Jeśli sprzedajesz swój kod źródłowy (tzn. Jesteś pisarzem komponentów), prawdopodobnie nie powinien tam być.

Jeśli chodzi o rozwagę, to cokolwiek, to zależy od ciebie.

Jeśli zobaczysz, że ktoś pisze dużo WTF, być może jest to znak, że powinieneś porozmawiać z nimi o problemach, które mają.

Jeśli ktoś kieruje swoją agresję w kierunku kodu innej osoby, może on nękać tę osobę i masz do czynienia z zupełnie inną sytuacją. Być może mają uzasadnioną skargę i nie wiedzą, jak ją odpowiednio wypowiedzieć. Może to tylko palant.

Nie byłoby rozsądnie mieć jakiś filtr treści, cokolwiek pisze programista, jest ważne i mówi ci wiele o tym, jak się sprawy mają.

Pracuję dla firmy z listy Fortune 500, która projektuje, produkuje i sprzedaje produkty konsumenckie, w których wewnętrznie opracowano kod µControllers. Spory sądowe są zawsze możliwe, albo przez konsumentów, którzy chcą szybko się wzbogacić, albo przez konkurentów, którzy domagają się naruszenia. Z tego powodu piszemy nasz kod i WSZYSTKIE komentarze ze świadomością, że może (prawdopodobnie będzie) kiedyś podlegać kontroli wrogich jurorów. Oznacza to, że nazwy zmiennych i funkcji nie powinny zawierać podburzających terminów, takich jak KILL_CHILD(int process_id). Chociaż celem tej przykładowej funkcji może być równie dobrze zakończenie procesów potomnych, jak wrogie ławy przysięgłych postrzegałyby tę funkcję, gdyby dziecko powoda zostało zabite podczas używania produktu?

Komentarze w kodzie mogą być jeszcze gorsze. Chociaż przyzwoity zespół obrony prawdopodobnie poradziłby sobie z wyjaśnieniem, czym jest proces potomny (z poprzedniego przykładu) i dlaczego może być konieczne jego zakończenie, prawie niemożliwe byłoby obrona przed komentarzem w rodzaju:

// The following section of code is REALLY BAD!!!  I hope
//  it doesn't burn anybody's house down.

Takie bezpośrednie komentarze były decydującymi czynnikami w prawdziwych sprawach sądowych.

Na pokrewny temat nazwy projektów mogą być również okropne, gdy znajdują się pod mikroskopem intensywnych sporów sądowych. Czy pamiętasz zamieszanie ze strony konserwatywnych grup w połowie lat 90., kiedy źródła wiadomości technologicznych donosiły „SATAN Unleashed On The Internet” ?

<rant_mode_off>

Mając to wszystko na uwadze, w projektach osobistych możesz robić, co chcesz w swoim kodzie.

Jeśli ci to przeszkadza, a ty jesteś głównym honorem, nie rozumiem, dlaczego nie możesz wprowadzić w życie reguły w tej sprawie. W końcu jesteś liderem w tej hipotetycznej sytuacji.

Jeśli jednak ci to przeszkadza i nikomu to nie przeszkadza, być może powinieneś to zrobić.

Może nie jestem odpowiednią osobą, by o to pytać, ponieważ często używam lekkiej wulgaryzmy.

Myślę, że to zależy głównie od tego, jak PC (poprawne politycznie) jest twoje środowisko.

Jeśli koduję dla firmy w garniturach i krawatach, staram się w ogóle nie używać wulgaryzmów, ale jeśli chodzi o projekt hobbystyczny lub coś takiego, mam tendencję do swobodniejszego mówienia.

Wydaje mi się, że w USA i niektórych innych krajach ludzie są dużo bardziej komputerowi (lub utknęli) niż w Holandii, gdzie mieszkam i pracuję.

Jako dodatkowy bonus, oto niektóre statystyki wulgaryzmów w kodzie: http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language/

Jestem skłonny zgodzić się, że może to być dość nieprofesjonalne, ale od czasu do czasu wszyscy przeklinają, więc staram się nie przeciwstawiać się innym. To powiedziawszy, baza kodów ma tendencję do odzwierciedlania ogólnego profesjonalizmu grupy, więc wyjaśniająca baza kodowa może odzwierciedlać nieprofesjonalną grupę i może być konieczne spotkanie, aby „zastosować trochę polskiego” do grupy. Podobnie, jeśli pewne trendy pojawią się w kodzie, może to być wskaźnik ogólnych problemów w grupie, które należy rozwiązać (tj. Interfejs API, z którym pracujesz, ma problemy, które frustrują programistów).

Jeśli chodzi o bazę kodów, zwykle po prostu edytuję odpowiedni komentarz, aby był bezpieczny w pracy i na tym zostawiam. W zależności od języka, z którym pracujesz, jest to zawsze dobry pomysł, ponieważ nigdy nie wiesz, co może pojawić się przed klientem lub klientem.

Czy to nieprofesjonalne, obraźliwe czy coś, co należy odrzucić?

Możliwe, że wszystkie trzy ... w zależności od twojego punktu widzenia.

Ludzką naturą jest wyrażanie się w określonych sytuacjach za pomocą „kolorowego języka”. W niektórych kulturach bardziej niż w innych, a niektórzy ludzie bardziej niż inni. Ale tendencja jest uniwersalna.

Gdybym był tobą, wzruszyłbym ramionami, chyba że jesteś skłonny uczynić siebie niepopularnym wśród swoich kolegów z pracy.

Jeśli jednak komentarze do kodu źródłowego / VCS zostaną opublikowane poza organizacją, kierownictwo może chcieć przyjąć silniejszą linię, ponieważ szkodzi to, że firmy obrażają klientów.

Jednym z problemów wulgaryzmów jest to, że różni się od kultury do kultury. W Stanach Zjednoczonych niewinne rzeczy są „wypychane”, podczas gdy w innych krajach często można usłyszeć ten sam język wymieniany w dyskusjach parlamentarnych.

Wulgaryzmy w kodzie i komentarze są dość powszechne, prawdopodobnie z powodu widoku „nikt tego nie zobaczy”. Myślę, że obecnie jest to bardziej powszechne, ponieważ większość organizacji zakazuje pisanek.

Osobiście uważam, że rzeczy niezwiązane z klientem (takie jak wewnętrzne materiały zatwierdzające) nie stanowią dużego problemu.

Jednak większość dużych korporacji międzynarodowych jest prowadzona przez działy prawne i „bezpieczne miejsce pracy” i tak dalej, co oznacza, że ​​wszystko, co może być obraźliwe dla co najmniej jednej osoby, stanowi problem i potencjalną przyczynę zwolnienia. Nienawidzę tego przyznać, ale mam skłonność do ulegania przepisom tych, którzy wypłacają moją pensję.

Szybkim rozwiązaniem tego problemu jest zainstalowanie filtru wulgaryzmów w systemie kontroli źródła (jako wstępnie przesłany skrypt lub regularna kontrola).

Myślę, że jest w porządku, o ile nie wymyka się spod kontroli, jak zrzucanie tam bomb. Widziałem faceta, z którym pracuję, piszącego scenariusz między dwoma postaciami omawiającymi różne przedmioty, które reprezentują. Był komentarz wieloliniowy, który biegł przez około 30 linii tych dwóch postaci rozmawiających ze sobą.

/ * * igor: mam się publicznie maskarować? * Frankenstein: ah igor, odziedziczę po twoich najlepszych cechach ... * /

Tak było przez długi czas. Stworzył dwa obiekty o nazwie, zgadliście: Frankenstein i Igor w ramach kontroli zdrowia psychicznego. To było naprawdę bardzo kreatywne, ale strata czasu. Wolałbym raczej zobaczyć kilka WTF lub przekleństw niż scenariusz między dwoma obiektami C # ...

Zależy od kultury firmy / klienta. Na przykład, jeśli tworzysz oprogramowanie biblijne, przekleństwa w jakiejkolwiek formie są zdecydowanie niepożądane. Z drugiej strony twórcy gier mogą nie dbać tak bardzo (lub przejść do drugiej skrajności).

Zawsze myślę, że wszelkie komentarze (w kodzie lub zatwierdzeniach) powinny być pomocne . Niektóre słowa przyciągają naszą uwagę bardziej niż inne - przekleństwa, nawet delikatna odmiana, zdecydowanie są zauważane. Przydatne może być zwrócenie uwagi na coś, co jest po prostu złe, ale na razie nie można tego obejść.

To powiedziawszy, nie używam przekleństw, ale od czasu do czasu będę używać rzeczy takich jak „Doh!” lub „Hę?” co nie jest zbyt odmienne w duchu. Jeśli ci to przeszkadza, porozmawiaj o tym ze sprawcą - może on nie myśleć o tym. Jeśli powiedzą ci, abyś wybrał się na wędrówkę i czujesz się mocno z tego powodu, idź do szczebla kierownika. Jeśli nie otrzymasz wsparcia od menedżera, musisz nauczyć się z nim żyć lub iść gdzie indziej.

Nie jestem do końca pewien, co jeszcze powinieneś powiedzieć o kodzie:

tocommit = (n + (COMMITSIZE/PAGESIZE) - 1) & ~(COMMITSIZE/PAGESIZE - 1);

Ten kod został pobrany z prawdziwej, bardzo kruchej bazy kodu, którą ostatnio próbowałem zoptymalizować. (Kod jest open source, więc nie ujawniam tutaj żadnych tajemnic pracodawców.)

Jak powiedzieli inni, zależy to od miejsca pracy i tego, kto zobaczy kod źródłowy.

Gdybym sprzedawał kod źródłowy, miałbym drugie repozytorium tylko wydanych wersji i nie pozwalałem na komentowanie poza opisem tego, co zapewnia każda nowa wersja. To, co robię na co dzień i wszystkie moje błędy są między mną a moim zespołem, a nie moimi klientami.

Obecnie mój serwer kompilacji zgłasza komentarze OMG, WTF, kludge, mess i TODO jako miarę pozostałych porządków, aby to zrobić teraz, ponieważ są one częścią tego procesu.

Jeśli widzisz wulgaryzmy w oprogramowaniu open source i chcesz się go pozbyć, przygotuj się na możliwość odparcia. Nie pisz po prostu trzywierszowego raportu o błędach i oczekuj, że zostanie zaakceptowany. Napisz mini-esej wyjaśniający, dlaczego wulgaryzmy i dyskryminujący język są złe, i uprzedzaj obalenia.

Myślę, że to kwestia osobistych preferencji. Te rzeczy tak naprawdę mi nie przeszkadzają, więc pewnie bym to zostawił. Może nawet podpowie mi, gdzie w obszarze kodu znajdują się problematyczne obszary.

Czy oni przeszkadza Ci ? Z faktu, że zadajesz to pytanie, zgaduję, że tak. W takim przypadku usuń je lub uporządkuj w bardziej odpowiednie komentarze na temat tego, co jest nie tak.