Ostrzeżenia kompilatora

Wiele kompilatorów ma komunikaty ostrzegawcze ostrzegające programistów o potencjalnych błędach w czasie wykonywania, błędach logicznych i wydajnościowych. W większości przypadków szybko je naprawiasz, ale co z nieusuwalnymi ostrzeżeniami?

Jak radzisz sobie z nieusuwalnymi ostrzeżeniami? Czy przepisujesz fragment kodu, czy przepisujesz go w „długi, bezhackowy sposób”, czy wyłączasz ostrzeżenia razem? Jaka powinna być najlepsza praktyka?

Co jeśli edytujesz kod innej osoby, a jego kod zawiera ostrzeżenia?

Oto dobry przykład: jQuery ma wiele ostrzeżeń JavaScript po wykryciu przeglądarki klasy Mozilla, dlaczego programiści jQ ich nie naprawiają? Jeśli przyczynisz się do jQuery, czy zamierzasz je naprawić?

Niektóre ostrzeżenia są zwykle bezpieczne do zignorowania, ale jeśli to zrobisz, z czasem będą się rozmnażać, aż nadejdzie ten dzień, gdy będzie ich tak wiele, że przegapisz jedno ostrzeżenie, które naprawdę ma znaczenie, ponieważ jest ukryte w hałasie.

Natychmiast napraw ostrzeżenia (które mogą obejmować wyłączenie poszczególnych reguł, jeśli uważasz, że nigdy nie ma to znaczenia dla twojego kontekstu).

Moim zdaniem powinieneś być wobec siebie surowy. Kompilator został napisany przez całkowitą liczbę ekspertów w tym języku. Jeśli zgłaszają, że coś jest nieco nieprzyjemne (pomyśl zapach kodu), kod powinien zostać sprawdzony.

Całkowicie możliwe jest pisanie kodu, który kompiluje się bez błędów i bez ostrzeżeń.

Kiedy pisałem w C i C ++, włączałem najściślejsze ustawienia, jakie mogłem, ponieważ chciałem wiedzieć, kiedy coś nie ma sensu dla kompilatora. Gdy skończyłem rzutowanie i sprawdzanie zwracanych wartości, byłbym szczęśliwy, ponieważ kod był tak poprawny, jak tylko mogłem.

Od czasu do czasu otrzymywałem kod od kogoś, kto wyrzucałby ostrzeżenia. Sprawdzenie źródła wykazało, że ignorowali rzeczy, które były dobrą praktyką programistyczną w C, przez co ich kod był kruchy.

Sądzę więc, że istnieją dobre powody, aby włączyć ścisłość i poświęcić czas na naprawę. Postępowanie inaczej jest niechlujne. Gdybym miał współpracownika, który wyłączył ostrzeżenia, spędziłbym z nimi trochę czasu ORAZ kierownik wyjaśniający, dlaczego to naprawdę źle.

Naprawiłbym każde ostrzeżenie. Jeśli je zignorujesz i pozwolisz im się kumulować, możesz przegapić coś ważnego.

Zasadniczo powinieneś dążyć do wyciszenia kompilatora, aby nowe ostrzeżenia pokazywały więcej. Ostrzeżenia te mogą wskazywać na subtelne błędy i należy się z nimi odpowiednio obchodzić.

Jeśli chodzi o ustalanie kodu innych ludzi, zależy to w dużej mierze zarówno od kultury pracy, jak i aktualnego stanu kodu. Nie można tak po prostu zmienić kodu, jeśli uruchamia on pełny cykl ponownego testowania, tak jak w przypadku kodu późno w fazie testowej lub w fazie produkcyjnej.

Zapytaj swojego szefa i działaj odpowiednio.

Za każdym razem, gdy zobaczysz ostrzeżenie kompilatora, musisz zatrzymać się i pomyśleć o tym, czy naprawdę jest to problem czekający na wysadzenie ci w twarz na stronie klienta, czy coś, co możesz zignorować. Co gorsza, rzeczy, które DZISIAJ możesz zignorować, mogą wybuchnąć w witrynie klienta za kilka lat, po pozornie niezwiązanej zmianie kodu Somewhere Else.

Napraw ostrzeżenia. Kropka. Chodzi o to lub udokumentowanie każdego z nich, z tyloma stronami wyjaśnień, ile potrzeba, aby udowodnić, że nie stanowi to ryzyka, wraz z podpisanym zamówieniem sprzedaży na ulubioną dziewczynę (lub skrytkę porno), jeśli okaże się, że BYŁO ryzykiem.

Zasadniczo chcesz, aby Twoja kompilacja była wolna od ostrzeżeń. Ostrzeżenia istnieją z jakiegoś powodu i często wskazują na bardzo realne problemy. Jeśli przyzwyczaisz się ignorować ostrzeżenia kompilatora, w końcu twoja kompilacja będzie ich miała mnóstwo, a przegapisz jedno ostrzeżenie spowodowane katastroficznym problemem, który będzie kosztował Twoją firmę. Z drugiej strony, jeśli Twój program zwykle kompiluje się bez ostrzeżeń, każde nowe ostrzeżenie jest natychmiast zauważane i można je szybko rozwiązać.

To powiedziawszy, czasami kompilatory mogą mieć ostrzeżenia, które nie mają większego sensu i których nie można łatwo naprawić. Tę sytuację spotykam codziennie w pracy z TI CodeComposer, który jest środowiskiem programistycznym dla DSP TI. Mam kod C ++, który kompiluje się bez ostrzeżeń w programie Visual Studio, ale powoduje dziwne ostrzeżenia w CodeComposer, po prostu dlatego, że obsługa standardowego C ++ przez TI może być lepsza. Na szczęście CodeComposer pozwala indywidualnie wyłączać określone ostrzeżenia, co musimy zrobić, gdy nie ma sposobu, aby naprawić kod, który generuje ostrzeżenie.

W moim przypadku ostrzeżenia pochodzą z narzędzia PyLint i mogę wyłączyć ostrzeżenie w określonej linii, dodając specjalny tekst w komentarzach.

W większości przypadków tego nie robię. W większości przypadków zmieniam kod, aby zastosować się do sugestii PyLint, ponieważ PyLint jest zwykle poprawny. Jednak w nielubianych konstrukcjach, które są na ogół złym pomysłem, ale które mają sens w określonym kontekście. Na przykład narzeka, jeśli złapię wszystkie możliwe wyjątki. Zwykle jest to poprawne, to byłby zły pomysł. Jednak w niektórych przypadkach chcę wychwycić wszystkie wyjątki, takie jak przesłanie sobie raportu o błędach ze szczegółami.

Więc: prawie we wszystkich przypadkach pozbywaj się hacków. Gdy hack jest naprawdę uzasadniony, dodaj komentarz informujący PyLint, że wszystko jest w porządku.

Niektóre korzyści wynikające ze ścisłości nie zostały jasno określone w innych odpowiedziach:

1. Po naprawieniu wszystkich łatwych do naprawienia ostrzeżeń, pozostałe znaczące / istotne ostrzeżenia są bardziej prawdopodobne.
2. Jeśli odpowiednie ostrzeżenia zostaną znalezione i rozpatrzone na czas (przed wydaniem), można uniknąć błędów, co prowadzi do większej satysfakcji użytkownika końcowego
3. Rozwiązanie ostrzeżenia zwykle prowadzi do łatwiejszego w utrzymaniu i prostszego kodu (np. Eliminuje warunki, które zawsze są prawdziwe)
4. Gdy liczba ostrzeżeń jest bliska 0, łatwo jest zgodzić się na zasadę zerowych ostrzeżeń w zespole, którą bardzo łatwo zautomatyzować w systemie CI.
5. Podczas rozwiązywania ostrzeżeń kompilatora zrozumienie kodu programu pogłębia się, co może prowadzić do przydatnych informacji na temat implementacji (np. Odkryć inne błędy lub uzyskać pomysły, jak dalej rozwijać kod)
6. Kompilacja staje się szybsza, a codzienna wydajność rośnie: IDE / kompilator ma mniej problemów do zarządzania i raportowania, dzięki czemu kompilacja jest szybsza (dotyczy to tylko tysięcy ostrzeżeń).

Istnieją pewne różnice językowe w niektórych rodzajach ostrzeżeń. Uważam, że ważne jest, aby przemyśleć i przedyskutować ten temat, a następnie wyłączyć niektóre indywidualne ostrzeżenia, jeśli wydają się całkowicie bezużyteczne, aby można było osiągnąć surowość. Zostało to osiągnięte w kilku zespołach w mojej karierze. Więcej o moich doświadczeniach na ten temat

Ostrzeżenia i błędy to komunikaty używane przez kompilator do informowania programisty „coś, co napisałeś, nie ma sensu” - różnica między nimi polega na tym, że kompilator z ostrzeżeniem zgadnie, jakie są intencje programisty, podczas gdy z błędem kompilator nie może nawet zgadywać.

Błędy kompilatora zostaną naprawione (nie zamierzam mówić o naprawieniu ), ale zbyt często programiści (nawet doświadczeni) ignorują ostrzeżenia. Problem z ignorowaniem ostrzeżeń polega na tym, że czasami kompilator zgaduje źle a jeśli masz ponad 1000 komunikatów ostrzegawczych, łatwo przeoczyć komunikat ostrzegawczy, który wskazuje, że kompilator źle zgaduje.

Z socjologicznego punktu widzenia programy, które mają wiele komunikatów ostrzegawczych, to Broken Windows .