Better code in 4 clicks

Code Reviews, FxCop, StyleCop, Resharper, NDepend, Continuous Integration, TDD. All that and many more tools and techniques are used to create better code. But often we forget, or don’t know about, basic ways that will help us deliever better code. Today I’ll show you how to achieve this in 4 clicks.

All the aforementioned tools and techniques are worth using but there is one tool that you already have and probably don’t use. And you can configure it right away.

From my experience in projects that are developed for many years, sometimes by many teams and sometimes even by different companies I know how typicall build log looks like. Many many screens of unreadable text that nobody would like to have to read. But sometimes you need to. For example when your CI server is e-mailing you that build failed. Bad luck you pushed changes on Friday at 4:50PM. Now read and analyze the log.

As is often the case most of the garbage in build log are warnings. Tens and even hundreds is a norm. And I’ve seen build logs with more then 1000 warnings! What’s even worse those warnings are in test projects. Code that’s supposed to help us create better production code generates compile warnings itself!?

Now someone might say that warnings are no big deal. If they were they would be reported as errors by compiler, right? Wrong. Even though compiler is showing warning it doesn’t mean it’s not a bug. It’s just that sometimes compiler can’t say if it is. That’s why it warns you. Example? „Unreachable code detected”. Bad if, wrong early return and method returns too early and is not doing it’s job.”I don’t understand, the code is there”. But it doesn’t execute. Let’s assume only 1% of those warnings are bugs waiting to crop up on production. How much is 1% of 1000 warnings? And there is very easy way to avoid this. If you want to know how I’ve recorded this movie for you. Enjoy 😉


Now instead of this build log.


we can have this,


or even better like this.


Just go to Tools –> Options –> Projects and Solutions –> Build and Run and set MSBuild build output to Quiet.


But what if we are determined to do better in future but some warnings „have to stay for now”? Or if it’s not our fault that framework developers marked method as [Obsolete]. Then you can wrap code with #pragma warning directive.

public void UsesObsoleteMethod()
    var withObsolete = new FrameworkClass();
    #pragma warning disable 618
    #pragma warning restore 618

You can also „mute” warnings globally for project. If you look again at the „movie” above there is „Suppress warnings” option. There you can enter warnings that „have to stay for now”. In my opinion using #pragma warning is better because it makes it easier to find all warning generating code with simple Ctrl+Shift+F.

I encourage you to configure every new project to treat all warnings as errors. I wish it was default. It’s a lot easier to not introduce warnings than eliminate them later. But what if you already have projects with dozens of warnings? In my experience it’s very hard to eliminate them. There’s always something more important. But one thing you can do is configure your CI server to break build when number of warnings grows. And hope that the existing ones are not really bugs.


Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:


Komentujesz korzystając z konta Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s