Czy ignorujecie warningi w pracy?

W swoich osobistych projektach staram się nie mieć ani jednego warninga bo często pomagają w wykryciu niechcianych błędów typu przypisanie zamiast porównania, porównania referencji zamiast wartości czy tym podobnych.

Ale kolejna praca, kolejny projekt i znowu tysiące(!) warningów podczas kompilacji
Prawdziwe ostrzeżenia toną w setkach mało ważnych bo ktoś na przykład zamiast zakomentować kod pozostawił "dead code" po returnie, zostawił na przyszłość zmienne których nie używa, albo zignorował jakiś pomocniczy atrybut.
Poprawa ich wszystkich zajęłaby całe dnie i już nie można na nich w ogóle polegać więc się na nie już nawet nie zwraca uwagi

Czy u was w pracy też tak jest? Czy poświęcacie czas na ich usuwanie? Czy dostajecie OPR gdy jakiś zostawicie?

Powinni znaleźć kogoś kto przez kilka dni by oczyścił kod z tego całego syfu.

@abcefadfa generalnie jeśli nie ma na to pozwolenia / capacity to poprawiasz tylko to z czym pracujesz. Tzn jeśli akurat dopisuje coś do istniejącej klasy to od razu wskakuje refaktor, ale w osobnym commicie, żeby potem było wiadomo co było zmianą funkcjonalną a co tylko kosmetyką.

Nie ignoruje warnów. Chyba że kod nie mój i nie płacą za analizę/poprawę - to zostaje mi tylko upewnić się że mój kod nie powoduje więcej warnów i dodaje toto. Za to jak jest audyt jakości kodu, to dopierdzielam się nawet o niezachowanie standardów kodowania/whitespace ;)

Treats warning as errors (build na CI sie nie uda), discardowanie review, które zawiera np. dead code skutecznie eliminuje takie praktytki.

U mnie w pracy miałem styczność z kilkoma projektami w których sypało nie tylko warningami, a errorami, ale jeżeli ich liczba nie przekraczała x(x wynosiło 21 w jednym i 215 w drugim) to "wszytko było ok".
Dodam, że projekty wielkie i odziedziczone po innej firmie/innych firmach.
Jeżeli liczba błędów przekraczała x to znaczyło, że gdzieś jest błąd który już nie jest ok.

Co do warningów to jakby był czas to bardzo chętnie bym wyeliminował, ale czasu nigdy nie ma.

autor napisał(a)

Treats warning as errors

Niektóre warningi zwłaszcza pod Visual Studio są tak bzdurne, że bardziej opłaca się je wyłączyć za pomocą #pragma warning albo odpowiednim #define'em niż przerabiać kod tak, by kompilator przestał się czepiać dobrego kodu... ;-)

W dobrze zarządzanych projektach, gdzie ceni się porządek i jakość kodu, po prostu jest włączona flaga w kompilatorze by traktować ostrzeżenia jak błędy.
Niestety nie zawsze się tak da. Przykładowo mam teraz projekt, w którym zmieniłem SDK na nowsze i mam od groma warningów, że coś jest deprecated i po prostu nie ma czasu tego naprawiać.

Traktowanie warningów jako błędy, albo co gorsza włączanie narzędzi "wspomagających utrzymanie jakości kodu", które wymuszają np. co najwyżej jedną linijkę komentarza //, co najwyżej jedną linijkę odstępu między metodami/instrukcjami w metodzie, minimalnie trzy słowa komentarza dla każdego parametru każdej metody, to prosta droga do zabicia produktywności programisty.

Prawdziwe ostrzeżenia toną w setkach mało ważnych bo ktoś na przykład zamiast zakomentować kod pozostawił "dead code" po returnie

Zakomentarzowanie również jest mało profesjonalne. Martwy kod najlepiej usuwać w ogóle, bo od tego jest kontrola wersji, żeby pamiętała stary kod...

W ostatnim projekcie lint pluł warningami jak szalony. Zainstalowaliśmy plugin do Jenkinsa, który wylistował wszystkie warningi. Mieliśmy chwilę czasu i zbiliśmy wszystkie warningi do zera. ;-)

Niemniej jednak, przyznam, że gdyby nie było na to czasu i nikt nie wykazałby inicjatywy, to pewnie warningi dalej by wisiały.

U nas nie ma mowy o warningach. Wliczając w to m.in. cppchecka i valgrinda oraz tysiące testów, wszystko musi być sprawdzone przed commitem. Chociaż na szczęście nie ma wśród nich narzędzi "wspomagających utrzymanie jakości kodu" - tj. sprawdzania komentarzy, odstępów...

To zalezy. W nowym kodzie pilnuje sie zeby warningow nie bylo, w legacy troche jest chocby ze wzgledu na zmiany Javy po drodze (jak sie trafiaja jakies zmiany w okolicy to sie poprawia po trochu na biezaco) w narzedziach nie ma sie co przejmowac. Z tym ze ogolnie nie ma mowy zeby zostawiac np. unrechable code.

W firmie PGS Software ignoruje się nie tylko warningi, ale i errory.

xD

Spejson napisał(a):

W firmie PGS Software ignoruje się nie tylko warningi, ale i errory.

xD

cicho bo jeszcze nas wywalą.

Piszesz kod aż nagle 10 ostrzeżeń, myślisz jeśli działa to tak zostawię.
Wysyłasz kod do klienta aplikację wraz z kodem. Jego programista chce wprowadzić drobne zmiany a tu patrzy 10 ostrzeżeń, zanim je poprawi mija dzień a nie napisał jeszcze zmian.

Pomyśl jak ty byś dostał taki kod i szef kazał by ci usunąć ostrzeżenia (lub przełożony)

W wiekszych firmach klient nie dostaje zrodel.

WhiteLightning napisał(a):

W wiekszych firmach klient nie dostaje zrodel.

Minister cyfryzacji dał zalecenie, aby firmy wygrywające przetargi dostarczały program wraz ze źródłami

WhiteLightning napisał(a):

W wiekszych firmach klient nie dostaje zrodel.

Ciekawe, a gdzie tak jest? Nigdy nie słyszałem o tym, aby kiedykolwiek klient nie chciał źródeł. Często nawet zdarza się wymaganie, aby korzystać z systemu kontroli wersji klienta.

@WhiteLightning, jak jestes microsoftem albo oraclem względnie dostarczasz produkt "pudelkowany" to tak. Jak robisz soft "na miarę" to dostarczasz kod źródłowy, bo tak naprawdę to on jest produktem

A co powiecie o firmach robiacych systemy mission albo life critical?

Jak do KIRu (dla elixira) kupowaliśmy soft COBOL-Java to było przykazane, że razem ze źródłami ma przybyć.