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


34

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ć?


15
Poszczególne przypadki ... komentarze są drogą dla osobowości deweloperów. Tak jak masz do czynienia z N typami osobowości, musisz także radzić sobie z N rodzajami komentarzy, które wykrwawiają osobowość programistów. Jak radzisz sobie z danym deweloperem, używając wulgaryzmów, kiedy wchodzisz w interakcje z nimi za pośrednictwem wiadomości błyskawicznych, poczty e-mail i ustnie?
Aaron McIver

10
Musiałem powiedzieć niektórym twórcom Jr., aby nie zamieszczali wulgaryzmów w komentarzach. IMHO to bardzo nieprofesjonalne. Jeśli nie przeklinałbyś przed współpracownikami lub klientami, po co przeklinać w komentarzach / kodzie? A jeśli przysięgniesz przed współpracownikami i klientami ... masz o wiele bardziej wyluzowane środowisko pracy niż ja. :)
Tyanna

4
@Tyanna: W moim ostatnim miejscu pracy byliśmy nawet trochę rasistami! Jeśli możesz to tak nazwać. Myślę, że poprawność polityczna jest okropna wśród współpracowników, którzy spotykają się każdego dnia. Czy bałbyś się opowiadać rasistowskiemu żartowi komuś, kogo widzisz przez 10 godzin dziennie? Z drugiej strony mieszkam w Boliwii - myślę, że Stany Zjednoczone mają o wiele bardziej pozywaną - tę, pozywającą - mentalność i dlatego nikt nie chce stawać na palcach.

4
@Anna Lear: Nigdy o oskarżeniu w Danii za opowiadanie pikantnego dowcipu. Jednak USA ... Wszystko zależy od tego, w jakiej atmosferze pracujesz. USA mają większy wpływ na drony HR, które monitorują każdą drobiazg.

10
Po prostu zrób grep f.ckna kodzie źródłowym jądra Linux. Jeśli jest dla nich wystarczająco dobry, jest dla mnie wystarczająco dobry. Ale nigdy nie umieszczaj niczego obraźliwego w miejscach, w których istnieje najmniejsza szansa, że ​​klienci to zauważą. Zrobiłem to raz i na szczęście udało nam się pobrać aktualizację w ostatniej chwili, ale nie było to zabawne. (Cóż, właściwie to było potem).
biziclop

Odpowiedzi:


41

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.


1
Dodam, że wulgaryzmy w twoim systemie śledzenia defektów również nie powinny być zachęcane. Będąc w stanie poprosić zgłaszającego o zredagowanie komentarza w celu usunięcia wulgaryzmów, mogę powiedzieć, że nie jest to przyjemne stanowisko dla przełożonego / kierownika zespołu / menedżera. Zwłaszcza, gdy odmawiają.
szybko_nie

@ quickly_now, jak sobie poradziłeś z tą sytuacją?

Zapytałem ponownie Kiedy osoba ponownie odmówiła, sam zredagowałem komentarze, aby je zdezynfekować. Nie sądziłem, że warto przejść przez proces doradztwa / dyscypliny (krok nr 1 prowadzący do zwolnienia), ale zgłosiłem także mojemu szefowi, co znalazłem i co zrobiłem. Wszyscy zgodziliśmy się, że nie pójdzie dalej, chyba że się powtórzy (i nie powtórzyło się). Nie śmieszne. [Powinienem dodać, że wulgarne komentarze zgłosił mi inny zainteresowany pracownik. To sprawiło, że mój problem został rozwiązany. Czasami stanowiska seniorów nie są warte dodatkowych $ !!!]
szybko_now.

„ale potem obraził się, gdy niektóre głupie linie tagów można uznać za obraźliwe”. Musiałbyś być BARDZO głęboko zaniepokojonym człowiekiem, aby obrazić go obraz smoka, ponieważ jesteś walijczykiem.
Miles Rout

24

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


1
+1 za to, że nie sprzedaje kodu źródłowego z ładunkami eksplozji. Kod powinien zostać dokładnie sprawdzony pod kątem takich komentarzy przed dostarczeniem.
FrustratedWithFormsDesigner

2
Niegrzeczne komentarze zdecydowanie nie są dobrym pomysłem, jeśli jesteś programistą HTML. :)
biziclop,

@biziclop, co jest niefortunne, ponieważ HTML jest tak frustrujący jak to tylko możliwe. Sprawdź @ link Jinx na temat wulgaryzmów w źródle. wygląda na to, że Javascript jest zawiązany po raz pierwszy (nie jestem pewien, czy obejmuje to przypadkowe pomniejszone przeklinanie javascript)
Peter Turner

Nasz prosty filtr treści działający na Jenkins miał z tym problem: void pushItem (...
sal

17

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.


1
+1 za wskazanie najbardziej niebezpiecznego aspektu tego BEZROFESJONALNEGO zachowania. Pracowałem w zespołach ds. Należytej staranności, które sprawdzały kod źródłowy firm, dla których F500, dla którego pracowałem, miał kupić. Szukaliśmy tego rodzaju rzeczy z powodów, o których wspomniałeś, i sprawiło to różnicę, kto otrzymał ciągłe zatrudnienie, a kto nie, kiedy połączenie zostało zakończone. W szczególności duża firma (głębokie kieszenie) nie kupuje małej firmy w celu odziedziczenia pozwów dotyczących prześladowania / wrogiego środowiska pracy, więc przestępcy zostają rozwiązani / zwolnieni po zakończeniu zakupu.
kloucks

5
KILL_CHILD to tylko absurdalny przykład. I chciałbym zobaczyć cytat na temat „Bezpośrednich komentarzy takich jak to decydujących czynników w prawdziwych sprawach sądowych”. (Nie mówię tego tylko jako STFU ... Naprawdę chciałbym przeczytać cytat.)
Wolfger


1
„Oznacza to, że nazwy zmiennych i funkcji nie powinny zawierać podburzających terminów, takich jak KILL_CHILD”. To jest najgłupsza rzecz, jaką kiedykolwiek czytałem, i powinieneś się wstydzić nawet sugerowania, że ​​KILL_CHILD to zła nazwa funkcji.
Miles Rout

9

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


Oto rzecz: nie „ssę” rzeczy.
gnasher729,

7

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/


1
Myślę, że jest to bardziej zależne od sektora - w warunkach wysokiego ciśnienia, takich jak finanse, przekleństwa są powszechne.
JBRWilkinson

jest również wysoce zależne od tego, co uważasz za „wulgaryzmy”. Podobnie jak w artykule, połączone „lol” i „rofl” zostały wybrane jako wulgaryzmy, kiedy myślę, że większość z nas nie klasyfikuje ich jako takich.
jwenting

Nie chodzi o komputer - chodzi o odpowiednie użycie języka (możesz być całkowicie nie komputerem i nadal decydować się nie używać wulgaryzmów - możesz być głęboko obraźliwy i niegrzeczny i nadal nie używać wulgaryzmów). Należy o tym pomyśleć w kategoriach nieuzasadniania przestępstwa - niepotrzebnego, ponieważ prawie wszystko jest dla kogoś obraźliwe - ale większość z nas wie, gdzie jest linia i ogólnie przysięgam, że słowa są po złej stronie. Powściągliwość w tej dziedzinie jest przydatny - jeśli nie przysięgać dużo lub często wtedy, kiedy ludzie zwracać uwagę ...
Murph

6

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.


3
+1, ciekawe, nie myślałem o użyciu wzorców wyglądających na przekleństwa, aby śledzić frustrację przy użyciu określonych funkcji / bibliotek.
FrustratedWithFormsDesigner


5

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.


Kluczem jest tutaj „w niektórych sytuacjach” - tj. Tam, gdzie jest to właściwe i dopuszczalne. Myślę, że uzasadnione jest sugerowanie, że komentarze (kod lub zatwierdzenie) nie są naprawdę akceptowalnymi miejscami i dlatego nie są odpowiednie.
Murph

5

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


2
Nie mogę się zgodzić z twoją sugestią automatycznego filtra wulgaryzmów. Po pierwsze, ryzykujesz napotkanie problemu Scunthorpe, a po drugie, jak mówi Stephen C., wulgaryzmy są prawdopodobnie objawem innego problemu, a zakazanie go magicznie go nie naprawi.
Scott

2
+1 Dla filtru wulgaryzmów, ale ważne jest, aby unikać „pomyłki pomyłki” ( thedailywtf.com/Articles/The-Clbuttic-Mistake-.aspx )
rjzii

filtry wulgaryzmów nie działają. Mają tendencję do blokowania rzeczy niewinnych i przepuszczania złych rzeczy. Są również łatwe do obejścia.
jwenting

cd. Moderuję forum fotografii przyrodniczej. Gdy administratorzy zdecydują się zainstalować filtr wulgaryzmów, wszelkie dyskusje na temat bobrów, zwierząt domowych, ptaków, ptaków itp. Były cenzurowane. Przed ponownym usunięciem użytkownicy zaczęli opracowywać sposoby na obejście filtra. Jeśli nie możesz mówić o swojej podróży do strzelania do bobrów (ups, 3 złe słowa w jednym krótkim zdaniu), mówisz na przykład o swoim tr.ip do sh.oo.t be.ave.rs, a filtr bądź zbyt stu.pi.d (inne słowo, które zostało zakazane), aby je złapać.
jwenting

Dla mnie argument unikania filtrów wulgaryzmów „ponieważ wiele z nich to bzdury” ma tyle samo sensu, co unikanie filtrów antyspamowych, środków odkażających SQL itp. Istnieją przyzwoite opcje stron trzecich. Jeśli używasz po prostu wyrażeń regularnych, jesteś SOL.
Uri

3

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


Zabawne. Bezproduktywne, ale zabawne.
Paul Nathan

@Paul: Ha! Przepraszam, tak - niezbyt produktywne, ale niedorzeczne było zobaczenie tego dnia podczas przeglądania kodu.
Nodey The Node Guy

2

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.


Przepraszamy, co to jest „oprogramowanie biblijne”? (tutaj nie pochodzi z angielskiego).
Gawron

2
Biblia zapisuje doktrynę chrześcijańską. Oprogramowanie biblijne to oprogramowanie, którego chrześcijanie mogą używać do krzyżowego sprawdzania tekstu w różnych tłumaczeniach, sprawdzania wypowiedzi uczonych na temat określonego fragmentu i ogólnie studiowania tekstu. Jedno z pism mówi o „Nie pozwól, by z twoich ust wydostała się zepsuta komunikacja”, co jest staroangielskie, ponieważ nie przeklinaj ani nie mów o rzeczach, które burzą ludzi. Jestem pewien, że istnieją inne zastosowania religijne, w których przeklinanie byłoby równie niepożądane.
Berin Loritsch

3
Czy chrześcijanie rozkładają pliki wykonywalne, aby szukać przekleństw w źródle?

Emm, komentarze się nie kompilują, żeby nawet nie działały;)
JinX

5
Więc jeśli piszę oprogramowanie biblijne, powinienem cenzurować wszystkie nieprzyzwoite rzeczy w Biblii?
Wooble,

1

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


3
Zabij ten sumb za pomocą ognia i magnesu!

1

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.


1

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.


0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.