There appears to be no force on earth capable of stopping some people writing bad code. I strongly suspect that in the event of nuclear holocaust the only things to survive will be cockroaches and terrible programmers, which seems unfair on the cockroaches. But this doom and gloom shouldn't stop you from using Visual Studio to at least put some minor speedbumps in their way. Given that we're all one global armageddon from being terrible programmers ourselves making use of these facilities in your development projects is a good idea.

I really hate code that produced compiler warnings. Compiler warnings are produced by only the most obvious issues with your code and are only a single step up from errors that prevent your code compiling at all. So the presence of compiler warnings implies you only care enough about your code to get it to compile, but you're not interested enough in it's maintainability to take anything but the minimal effort demanded by the limits of the compiler syntax. This is not exactly what I'd consider a professional attitude.

Visual Studio provides an option that treats compiler warnings as errors. This catches these problems as they're introduced. I turn this on in all projects and for all configurations as a matter of course. I do make exceptions for code generation where it's generally not practical. This allows warnings to be fixed as they're introduced but is unable to solve the problem of developers who use compiler directives to disable them. This is where development practices and project management are required to eliminate poor practice.

Existing codebases that contain complier warnings are harder to deal with. My general practice is to fix the warnings in the files I am working with, as well as making targetted fixes elsewhere. When a project gets close to zero warnings I make a push to resolve the last few then set it to treat warnings as errors to prevent backsliding. This kind of approach doesn't require you to stop making progress and can significantly reduce the incidence of compiler warnings (I've seen drops from over 1100 to under 100 in a few months with this approach).

Visual Studio may also be configured to extract XML comments from your code. When combined with treat warnings as errors this will cause the build to break if you miss a comment on an externally visible type or if your comment blocks are badly formed. As I also believe in using XML comments everywhere (on which I plan to post in more detail in the future) this option is also something I turn on whenever possible.