„Traktuj wszystkie ostrzeżenia jako błędy z wyjątkiem…” w programie Visual Studio

124

W programie Visual Studio mogę wybrać opcję „Traktuj ostrzeżenia jako błędy”, aby zapobiec kompilacji mojego kodu, jeśli są jakieś ostrzeżenia. Nasz zespół korzysta z tej opcji, ale są dwa ostrzeżenia, które chcielibyśmy zachować jako ostrzeżenia.

Istnieje opcja pomijania ostrzeżeń, ale chcemy, aby były one wyświetlane jako ostrzeżenia, więc to nie zadziała.

Wydaje się, że jedynym sposobem uzyskania pożądanego zachowania jest wprowadzenie listy wszystkich numerów ostrzeżeń C # w polu tekstowym „Specyficzne ostrzeżenia”, z wyjątkiem dwóch, które chcemy traktować jako ostrzeżenia.

Oprócz bólu głowy związanego z konserwacją, największą wadą tego podejścia jest to, że kilka ostrzeżeń nie ma liczb, więc nie można do nich odwoływać się bezpośrednio. Na przykład „Nie można rozwiązać tego odwołania. Nie można zlokalizować zestawu 'Dane ....'”

Czy ktoś zna lepszy sposób na zrobienie tego?


Wyjaśnienie tym, którzy nie widzą od razu, dlaczego jest to przydatne. Pomyśl, jak działa większość ostrzeżeń. Mówią ci, że coś jest trochę nie tak w kodzie, który właśnie napisałeś. Naprawienie ich zajmuje około 10 sekund, a to sprawia, że ​​baza kodu jest czystsza.

Ostrzeżenie „Przestarzałe” bardzo różni się od tego. Czasami naprawienie tego oznacza po prostu użycie nowej sygnatury metody. Ale jeśli cała klasa jest przestarzała, a używasz jej rozproszonego w setkach tysięcy linii kodu, naprawa może zająć tygodnie lub dłużej. Nie chcesz, aby kompilacja była zepsuta przez tak długi czas, ale na pewno chcesz zobaczyć ostrzeżenie o tym. To nie jest tylko hipotetyczny przypadek - to nam się przydarzyło.

Dosłowne ostrzeżenia „#warning” są również unikalne. Często chcę to sprawdzić, ale nie chcę zepsuć kompilacji.

Neil
źródło
Czy możesz wstawić spacje do swojej dużej listy liczb? Wypchnął owijanie linii.
Ray
O rany, nienawidzę skomplikowanych zasad, które są wymyślane przez ludzi, często po to, by uspokoić ego jakiejś konkretnej osoby.
Jon Limjap,
21
Rozumiem jego punkt widzenia na temat przestarzałego ostrzeżenia, to nie jest arbitralne.
Ed S.
Z mojego doświadczenia wynika, że ​​zezwolenie na choćby jedno ostrzeżenie w twojej kompilacji jest jak dodanie pierwszego async / await. Wkrótce będzie ich dziesiątki. Pamiętam, że we wszystkich konfiguracjach programista może zobaczyć mniej niż 10 ostrzeżeń w oknie Lista błędów w VS. Mogę się założyć, że skoro masz więcej niż 5 ostrzeżeń, zdecydowana większość deweloperów w zespole nie będzie w stanie dostrzec nowego - w Twoim ustawieniu oznacza to, że nie zauważą ostrzeżenia, że ​​metoda jest przestarzała, co przeczy cały cel ma to ostrzeżenie :) Jakie jest twoje doświadczenie z tym Neilem?
tymtam,
@mayu, to jest zagadka. Wiele razy widziałem ostrzeżenia, które były ignorowane przez długi czas. Ale w końcu albo pokażesz ostrzeżenie, albo nic nie pokażesz. Jeśli wyświetlasz ostrzeżenie, przynajmniej jest szansa, że ​​ktoś dowie się z niego czegoś pożytecznego. Jeśli traktujesz większość ostrzeżeń jako błędy, tym nielicznym, które pozostały, można poświęcić więcej uwagi.
Neil

Odpowiedzi:

155

Możesz dodać WarningsNotAsErrors-tag w pliku projektu.

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

Uwaga: 612i 618to zarówno ostrzeżenia o przestarzały, nie wiem różnicę ale projekt pracuję nad donosi Przestarzałe z ostrzeżeniem 618.

SvenL
źródło
24
Różnica między 612 a 618 to komentarz ObsoleteAttribute. ObsoleteAttribute bez komentarza generuje błąd 612, a jeden z komentarzem generuje 618.
Marco Spatz
@MarcoSpatz Dokładnie. Wtedy możemy traktować [Obsolete]członków, w przypadku których messagejest, nulljako błędy, podczas gdy pozwalamy tym, dla których messagejest ustawione, tylko ostrzeżenia. Jeśli errorparametr jest ustawiony na truew ObsoleteAttribute, zamiast tego generowany jest CS0619. Wydaje się, że to nie działa, jeśli tak messagejest null(ale kto by to zrobił [Obsolete(null, true)]?).
Jeppe Stig Nielsen
Aby uzyskać F #, użyj --warnaserror-:618,1030w polu kompilacja-> inne flagi. Ta opcja projektu nie została jeszcze zaimplementowana dla projektów F #. github.com/Microsoft/visualfsharp/issues/3395
Asik
2
Warto wiedzieć, że istnieje „WarningsNotAsErrors”. Powinien być dostępny w ustawieniach projektu bez ręcznej edycji pliku. Dzięki.
AFract
1
Microsoft naprawdę to schrzanił (a 11 lat później nie naprawił tego!). Zmieniają się ustawienia projektu <NoWarn>, które w większości przypadków są gorsze i nie udało się umieścić <WarningsNotAsErrors>w interfejsie użytkownika. Sława.
user2864740
13

/ warnaserror / warnaserror-: 618


źródło
1
Dziękuję za wkład. Mimo że nie rozwiązują problemu IDE, są to jak dotąd najbardziej pomocne komentarze.
Neil
2
Gdzie to dodajesz?
checho
@checho, te przełączniki zostaną dodane w wierszu poleceń podczas wywoływania msbuild. Dla naszych celów górna odpowiedź jest bardziej pomocna, ponieważ możemy wstawić ją do projektu zamiast modyfikować sposób, w jaki nazywamy msbuild.
Neil
Nie działa z MSBuild 15.9.21 + g9802d43bc3: MSBUILD : error MSB1001: Unknown switch. Switch: /warnaserror-:618
Paul B.
3

a dokładniej w twoim przypadku:

/ warnaserror / warnaserror-: 612,1030,1701,1702

powinno to traktować wszystkie ostrzeżenia jako błędy, z wyjątkiem tych na liście oddzielonej przecinkami


źródło
1

Dlaczego chcesz nadal widzieć ostrzeżenia, których nie traktujesz jako błędów? Nie wiem, dlaczego jest to pożądane - albo je naprawisz, albo nie.

Czy zadziałałyby dwa różne pliki kompilacji / rozwiązania - czy skrypt kopiujący jeden, a następnie odpowiednio zmodyfikowany poziom ostrzeżeń / ostrzeżeń. Wygląda na to, że być może chcesz, aby niektóre wykonania kompilatora krzyczały, ale inne chcesz kontynuować.

Dlatego różne przełączniki kompilatora wydają się dobrym rozwiązaniem. Można to zrobić z różnymi celami - jeden oznaczony jako debug lub release, a drugi odpowiednio oznaczony ostrzeżeniami.

Tim
źródło
7
Większość ostrzeżeń pojawia się z powodu prostej pomyłki w moim kodzie (np. Zadeklarowałem zmienną, której nie używam). Przestarzałe ostrzeżenie często występuje z powodu zmiany w kodzie innej osoby. Naprawienie tego może zająć tygodnie rozwoju. #warning to ostrzeżenie, które chcę umieścić w kodzie (prawdopodobnie jest to długoterminowa poprawka).
Neil
4
Innymi słowy, są ostrzeżenia, że ​​nie chcę zepsuć mojej kompilacji. Jeśli #warning zepsuje kompilację, to nigdy nie uda mi się jej zarejestrować. Jeśli Obsolete zepsuje kompilację, inny zespół, na którym polegamy, może nieświadomie zepsuć kompilację naszego zespołu, po prostu dodając przestarzały atrybut.
Neil
@Neil Zgadzam się z niektórymi z twoich argumentów, ale usunięcie zmiennej, której nie używasz, nie zajmuje dużo czasu I na pewno chcesz wiedzieć, że inny zespół zrobił coś przestarzałego.
tymtam
@mayu, dziękuję za komentarz. Zgadzam się z var, którego nie używasz. Dlatego chciałbym, żeby kompilator potraktował to jako błąd. Zgadzam się również, że chcesz wiedzieć, kiedy coś jest przestarzałe. Ale jeśli refaktoryzacja czegoś przestarzałego w Twoim kodzie zajmuje zbyt dużo czasu, możesz wybrać 1) Potraktuj to ostrzeżenie jako ostrzeżenie 2) Pozwól swojej kompilacji pozostać zepsutą przez długi czas 3) Inne rozwiązanie, takie jak wyłączenie ostrzeżeń jako błędów. W przypadku większości ostrzeżeń jako błędów lista ostrzeżeń prawdopodobnie pozostanie krótka, więc istnieje większe prawdopodobieństwo, że zauważysz, kiedy się pojawią. Jakie jest Twoje preferowane rozwiązanie?
Neil
1
@mayu, inny zespół (czy to w tej samej firmie, czy poza nią) może zgodnie z prawem chcieć zakomunikować, że klasa, metoda lub inny składnik są wycofywane przez pewien czas. Dodanie atrybutu to dobry sposób na zasygnalizowanie tego konsumentom biblioteki. Nie uważam tego za kłopotliwe. W rzeczywistości dodanie atrybutu tak wcześnie, jak to możliwe, jest dobrym sposobem upewnienia się, że inni są świadomi przyszłych zmian.
Neil
1

Używam traktuj ostrzeżenia jako błędy.

W rzadkich przypadkach, gdy pojawia się jakieś akceptowalne ostrzeżenie (np. Odwołuje się do przestarzałego elementu członkowskiego lub brakuje dokumentacji na temat klas serializacji XML), należy je jawnie wyłączyć za pomocą #pragma disable (i opcjonalnie można podać przyczynę braku czystego kodu jako komentarz).

Obecność tej dyrektywy pozwala również dowiedzieć się, kto przyjął to ostrzeżenie o naruszeniu (poprzez działanie „winy” kontroli wersji) w przypadku pojawienia się pytań.

Rinat Abdullin
źródło
3
Używam tego również, chociaż nie rozwiązuje to problemów wymienionych w moim opisie. Chcę, aby niektóre ostrzeżenia były traktowane jako ostrzeżenia, a nie ukryte.
Neil
0

Dlaczego nie zastosować reguły mówiącej: „Ktokolwiek sprawdza kod z jakimkolwiek ostrzeżeniem w środku innym niż 612, 1030, 1701 lub 1702, musi podejść do tablicy i napisać sto razy:„ Nie sprawdzę ponownie kodu z niedozwolonymi ostrzeżeniami. „”

erikkallen
źródło
9
Powodzenia w egzekwowaniu tego ... Traktowanie ostrzeżeń jako błędów jest bardzo ważnym krokiem w celu zwiększenia ogólnej jakości kodu i zmusi programistów do faktycznego naprawienia kodu! Cała automatyzacja gradobicia, praca fizyczna to taki XX wiek: ish!
Andreas Magnusson
@AndreasMagnusson Gdyby tylko brak ostrzeżeń faktycznie zapewnił jakość kodu ..
user2864740
2
@ user2864740: Zgoda, nie ma srebrnych kul. Ale zbyt powszechnym błędem jest odrzucanie czegoś użytecznego, zakładając, że nie jest to srebrna kula.
Andreas Magnusson
-4

Wydaje mi się, że głównym problemem jest tak naprawdę połączenie twojego traktowania ostrzeżeń jako błędów, kiedy wyraźnie ich nie ma, oraz twojej widocznej polityki zezwalania na meldowanie się, które to naruszają. Jak mówisz, chcesz móc kontynuować pracę pomimo ostrzeżenia. Wspomniałeś tylko o kilku ostrzeżeniach, które chcesz móc zignorować, ale co by było, gdyby ktoś inny z zespołu spowodował inne ostrzeżenia, których naprawienie zajęłoby Ci równie dużo czasu? Czy nie chciałbyś też móc to zignorować?

Logicznym rozwiązaniem byłoby albo 1) zablokowanie sprawdzania, jeśli kod się nie kompiluje (co oznacza, że ​​ci, którzy utworzyli ostrzeżenia, będą musieli je naprawić, ponieważ w efekcie zepsuli kompilację) lub 2) traktują ostrzeżenia jako ostrzeżenia. Utwórz dwie konfiguracje kompilacji, jedną, która traktuje ostrzeżenia jako błędy, które mogą być uruchamiane regularnie, aby zapewnić, że kod nie zawiera ostrzeżeń, i drugą, która traktuje je tylko jako ostrzeżenia i pozwala pracować, nawet jeśli ktoś wprowadził ostrzeżenie.

jalf
źródło
1
Korzystając z wybranej odpowiedzi, łatwo jest dodać do listy ostrzeżeń traktowanych jako ostrzeżenia. To działa znacznie lepiej niż którekolwiek z proponowanych rozwiązań. Ostrzeżenia oczywiście nie są błędami, ale traktowanie większości ostrzeżeń jako błędów oznacza, że ​​kod nigdy nie zostanie sprawdzony z tymi ostrzeżeniami.
Neil