This question already has an answer here:

I come from a C# background before my existing role. I am developing a VB.NET app. The code I inherited had option strict set to off and all other directives set to 'None'. I have recently switched option strict on and corrected all the errors. It will take me about one day to correct all the warnings. I am trying to decide whether this is time well spent.

The application is mature and is working very well. What is the guidance for setting option strict to ON and correcting warnings. I assume that you should not ignore them.

However, I read online today (I think it was on here) were one questioner said he/she never bothers with warnings. Surely this is wrong?

marked as duplicate by gnat, Kate Gregory, Bart van Ingen Schenau, user40980, Ampt Jul 2 '14 at 20:14

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    What's your experience? When you fixed the warnings caused by "option strict on", did you notice anything that might be an actual issue, or was it just bad style? The rule of thumb is that warnings exist for a reason, but applicable data beats rules of thumbs. If the fixes you applied so far were just reformulations to appease the compiler, maybe these warnings are not enough reason to fix them. – user7043 Jul 1 '14 at 17:36
  • @delnan, thanks. Mostly just bad style. A few booleans' that got implicitly casted to integers, but this did not cause errors. – w0051977 Jul 1 '14 at 17:38
  • 2
    Most important question: Do you have a good coverage of your code with automated testing? Having a few compiler errors due to switching the option is not what would worry me most... the real trouble would be code that gives no compilation error but behaves differently. – SJuan76 Jul 1 '14 at 17:40
  • 1
    I have found enough defects through investigating warnings that I am a fan of as few warnings as possible. However there are some warnings that are not worth the time or the possibility of introducing a defect when making a change. So as a rule of thumb the fewer the warnings the better however anytime you make a change you also run the risk of introducing a defect. – Richard Chambers Jul 1 '14 at 18:51
  • 3
    The real problem is that having the warnings off means that any new warnings are also off. – Loren Pechtel Jul 1 '14 at 19:46

It is a subjective issue. On every new project we (myself and some colleagues I know) start, we set warnings to compile errors by default. We end up with a clean code base, easy solution. (Plus, we also enable FxCop, StyleCop issues as errors, very low cost if you do it from the beginning).

Every warning has some impact on quality, maintainability, performance, security etc. There is no easy recommendation of "fix all" or "ignore all". The primary reason that these are warnings and not errors or not reported is primarily because a decision is not easy to make in all situations.

In the code base that has already been developed, it is usually a slow process. This is what I would do:

  • I would typically evaluate the impact of a warning.
    • If it's a performance warning in a piece of code that is not going to be hit too often, I'll ignore.
    • But if I am using a method that is obsolete, it may have a security impact, or eventually, the underlying class library might eventually break me.
  • Then I would typically evaluate the cost.
    • If it's an "unused variable", I'll fix it. If it's a thousand unused variables, I'll ignore with an understanding that it'll take me a few hours to fix those, and the impact is on code readability and perhaps maintenance.
    • Other warnings can be expensive, e.g. using an obsolete method, and changing that usage requires a serious code rewrite.
  • Based on the above two metrics (which really feeds into a cost/benefit analysis), I'll fix what makes sense immediately.
  • For the rest, the rule would typically be to fix the warnings when someone touches the code base, i.e. when the code is touched, one cannot say "I can leave it in a crappy state because I found it so." :-)

This works in most cases. What works for you will depend on your experience. For every warning, you can do an evaluation, and if you need others' opinions, post on stackoverflow probably to get recommendations. I am sure many issues have already been discussed there.

  • "a decision is not easy to make in all situations". Can you provide an example where the decision is more difficult. All the errors I looked at (and the warnings I have looked at so far) had obvious corrections. +1 for a comprehensive answer. – w0051977 Jul 2 '14 at 7:15
  • When I said that, I meant whether the benefit is worth the cost or not (based on your question). I provided two examples from my past projects: 1) too many issues that can be fixed, but will just take time, may be a few days, 2) what if using an API generates warning due to using method(s) being obsolete (msdn.microsoft.com/en-us/library/x5ye6x1e.aspx) after upgrading to a newer version and it costs a few days (if not weeks) to fix? Sometimes, these are not easy decisions depending on the project milestone, resources, etc. It is easier to just stay warning clean from the beginning IMO. – Omer Iqbal Jul 2 '14 at 7:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.