[visual studio 2012 / C#]Compile warnings onderdrukken

[Verwijderd]

Ik ben bezig met een code review / debug sessie van een programma geschreven door een van mijn collegae. Een compile van scratch geeft me ongeveer 200 waarschuwingen, de meeste met betrekking tot ongebruikte variabelen. Aangezien ik door de bomen het bos niet meer zie wil ik de meeste onderdrukken.

code:

warning CS0169: The field 'SPA.scheduleTest.daysToPopulate' is never used
warning CS0219: The variable 'scheduleHasAGap' is assigned but its value is never used

Gebruik van #pragma warning disable 169, 219 in het begin van een code file onderdrukt nummer 169 maar niet nummer 219. Ik heb verschillende combinaties geprobeerd (omwisselen, alleen 219), maar ik ben niet in staat 219 te onderdrukken.

Waarom?

Bedankt WimS

PS
In die 200 waarschuwing zitten er 7 die op incorrecte code duiden (CS1718 ); iets in de geest van

code:

if(a > b || a <= a)

[Woy]

Waarom de warnings onderdrukken, en niet gewoon oplossen? Dat lijkt me immers het doel van een code review.

Het voorbeeld wat je aanhaalt zal immers altijd true opleveren, dus gewoon de if verwijderen!

[ Voor 31% gewijzigd door Woy op 27-06-2013 13:03 ]

[thof]

Niet supressen/verbergen, maar gewoon oplossen is de beste manier. Vele malen belangrijker en beter voor de (code)kwaliteit van het product. Indien er bij ons een code analysis warning optreed bij het compileren, dan wordt de build keurig rood. Tenzij supressed, maar dat mag alleen met toelichting en goede reden (wordt gechecked by codereview).

[BoAC]

Ik heb meegemaakt dat een warning was onderdrukt waardoor je je helemaal suf debugged
Terwijl als de warning netjes was opgelost ik mijn tijd niet kwijt was.

[Olaf van der Spek]

Woy schreef op donderdag 27 juni 2013 @ 13:02:
Het voorbeeld wat je aanhaalt zal immers altijd true opleveren, dus gewoon de if verwijderen!

Je maakt een grapje, toch?

[Woy]

Olaf van der Spek schreef op donderdag 27 juni 2013 @ 14:48:
[...]

Je maakt een grapje, toch?

a <= a is altijd true, dus ongeacht wat a > b oplevert zal de expressie altijd naar true evalueren. ( Natuurlijk zal je eerst moeten kijken wat de bedoeling was in die context )

[ Voor 13% gewijzigd door Woy op 27-06-2013 15:02 ]

[ThomasG]

Dit soort dingen zijn de reden dat ik de compiler altijd waarschuwingen als error laat behandelen.

[R4gnax]

Woy schreef op donderdag 27 juni 2013 @ 14:55:
[...]

a <= a is altijd true, dus ongeacht wat a > b oplevert zal de expressie altijd naar true evalueren. ( Natuurlijk zal je eerst moeten kijken wat de bedoeling was in die context )

[pedant]En operator overloading?[/pedant]

[Olaf van der Spek]

En NaN

[ Voor 90% gewijzigd door Olaf van der Spek op 27-06-2013 19:42 ]

[Woy]

R4gnax schreef op donderdag 27 juni 2013 @ 19:04:
[...]


[pedant]En operator overloading?[/pedant]

Semantisch verkeerde operator overloading dan

Olaf van der Spek schreef op donderdag 27 juni 2013 @ 19:42:
En NaN

True, maar dan nog kan er beter IsNaN gebruikt worden zodat ook duidelijk is dat dat de bedoeling is In deze context zou ik er persoonlijk van uit gaan dat het altijd true oplevert. Dus mijn review comentaar zou ook zijn dat het statement overbodig is. Als daar uit komt dat het bedoeld is voor een of andere edge case ( NaN, Operator overloading ), zou mijn reactie zijn dat de code dan niet duidelijk genoeg is.

[ Voor 17% gewijzigd door Woy op 28-06-2013 12:00 ]

[Olaf van der Spek]

Woy schreef op vrijdag 28 juni 2013 @ 11:58:
Dus mijn review comentaar zou ook zijn dat het statement overbodig is.

Is het niet waarschijnlijker dat de conditie fout is? Dat bedoelde ik in eerste instantie.

[Verwijderd]

Bedankt voor de antwoorden. Helaas niet wat ik zocht De vraag was waarom ik error 219 niet kan onderdrukken? En ja, ik ben bezig ze op te lossen. Maar dat gaat langzaam.

Ik kan met deze waarschuwingen (169 en 219) leven op dit moment zodat ik me kan concentreren op het testen en het verwijderen van echte bugs (zoals het gegeven if statement).

[Woy]

Olaf van der Spek schreef op vrijdag 28 juni 2013 @ 14:35:
[...]

Is het niet waarschijnlijker dat de conditie fout is? Dat bedoelde ik in eerste instantie.

Dat zou best de uitkomst kunnen zijn als je het review commentaar bespreekt, daarom poste ik ook het volgende

Woy schreef op donderdag 27 juni 2013 @ 14:55:
[...]

a <= a is altijd true, dus ongeacht wat a > b oplevert zal de expressie altijd naar true evalueren. ( Natuurlijk zal je eerst moeten kijken wat de bedoeling was in die context )

Verwijderd schreef op zaterdag 29 juni 2013 @ 06:59:
Bedankt voor de antwoorden. Helaas niet wat ik zocht De vraag was waarom ik error 219 niet kan onderdrukken? En ja, ik ben bezig ze op te lossen. Maar dat gaat langzaam.

Ik kan met deze waarschuwingen (169 en 219) leven op dit moment zodat ik me kan concentreren op het testen en het verwijderen van echte bugs (zoals het gegeven if statement).

En hoe houden deze warnings dat tegen? Gewoon een kwestie van de warnings juist sorteren zodat je het overzicht niet verliest. Het onderdrukken zorgt er alleen maar voor dat je ze later waarschijnlijk helemaal niet meer oplost.

[Verwijderd]

Woy, dat ben ik niet met je eens. Een pragma in het begin kan later eenvoudig verwijderd worden. Maar dat is gewoon een andere benadering. En ten overvloede: het gaat in principe alleen om 'unused' variables tijdens een test / debug / review.

[__fred__]

180 unused variabelen verwijderen is een half uurtje werk, ik zou ze gewoon netjes opschonen. Een ongebruikte variabele maakt je code onduidelijker, dus waarom een pragma. Gewoon sorteren en een voor een wegwerken. Warnings rond laten slingeren bij commit vult bij ons op kantoor de pot om leuke dingen van te doen.