Czy ignorujecie warningi w pracy?

2

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?

0

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

0

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

0

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

3

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

0

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.

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

1

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

2

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.

2

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

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0