Skip to main content

Warnings as Errors

One thing that annoyed me when starting at Codeweavers was the amounts of warnings that would occur during a build of any of our projects. Seeing the build progress only to spew out a screenful of text was something that did not sit right with me. I was not the only one who felt this was wrong, but as there was so many warnings in some cases, it was easier just to pretend they were not there. After all everything was working fine.

The broken window theory is very much in action here. During our last standards review we decided that there should ideally be zero warnings per project. It is worth mentioning that most of our warnings were just that, warnings about something that was not really a major issue. Warnings such as unused variables and so on fall into this area.

On the other hand, while 90% of our warnings were ignorable, there were a handful which were rather important. Examples such as referencing different versions of required .dlls. Warnings like this are extremely helpful. It would be wrong for these to be hidden among a block of less serious issues. Warnings such as these once visible, can save hours of painful debugging.

Some of our projects had a fair few warnings - in the region of fifty plus. In order to begin tackling these larger projects we started slowly. If in a single day I would have removed a batch of warnings, this was a step in the right direction. After a week or so all our projects were void of warnings.

The next step was to make sure we do not go back to having larger projects with warnings galore. To prevent this I enabled "Treat warnings as errors" within Visual Studio. This is per project setting and can be found under the "Build" tab. Do note that you must enable this for "All Configurations" otherwise any settings you change will only apply to Debug/Release builds.

I like this feature of Visual Studio immensely. Having the compilier do as much work as possible - in this case check for warnings is similar to a tip found in Working Effectively with Legacy Code. Here the concept of "leaning on the compiler" is introduced. In other words you introduce an error in order to show you the usages of a piece of code - this is stark contrast to manually searching for the code in question.

The end result of this process is now during a build, if any warnings occur, the build will fail. The build will report where the warning is, along with why there is a problem. While this is great in theory it can cause some slight pain when developing, as you may comment out some code to experiment only to find the build failing due to unused variables. Despite this treating warnings as errors has been a great help. Recently we have solved some pretty serious issues with regards third party dependencies all thanks to treating warnings as errors.

The idea of allowing the computer to do as much work as possible applies to all languages. For your compiler/interpreter etc... there will be an option to apply warnings. This is not a specific language feature.


Popular posts from this blog

Constant Object Anti Pattern

Most constants are used to remove magic numbers or variables that lack context. A classic example would be code littered with the number 7. What does this refer to exactly? If this was replaced with DaysInWeek or similar, much clarity is provided. You can determine that code performing offsets would be adding days, rather than a mysterious number seven.Sadly a common pattern which uses constants is the use of a single constant file or object. The beauty of constants is clarity, and the obvious fact such variables are fixed. When a constant container is used, constants are simply lumped together. These can grow in size and often become a dumping ground for all values within the application.A disadvantage of this pattern is the actual value is hidden. While a friendly variable name is great, there will come a time where you will want to know the actual value. This forces you to navigate, if only to peek at the value within the constant object. A solution is to simple perform a refactor …

Three Steps to Code Quality via TDD

Common complaints and problems that I've both encountered and hear other developers raise when it comes to the practice of Test Driven Development are: Impossible to refactor without all the tests breakingMinor changes require hours of changes to test codeTest setup is huge, slow to write and difficult to understandThe use of test doubles (mocks, stubs and fakes is confusing)Over the next three posts I will demonstrate three easy steps that can resolve the problems above. In turn this will allow developers to gain one of the benefits that TDD promises - the ability to refactor your code mercifully in order to improve code quality.StepsStop Making Everything PublicLimit the Amount of Dependencies you Use A Unit is Not Always a Method or ClassCode quality is a tricky subject and highly subjective, however if you follow the three guidelines above you should have the ability to radically change implementation details and therefore improve code quality when needed.

DRY vs DAMP in Tests

In the previous post I mentioned that duplication in tests is not always bad. Sometimes duplication becomes a problem. Tests can become large or virtually identically excluding a few lines. Changes to these tests can take a while and increase the maintenance overhead. At this point, DRY violations need to be resolved.SolutionsTest HelpersA common solution is to extract common functionality into setup methods or other helper utilities. While this will remove and reduce duplication this can make tests a bit harder to read as the test is now split amongst unrelated components. There is a limit to how useful such extractions can help as each test may need to do something slightly differently.DAMP - Descriptive and Meaningful PhrasesDescriptive and Meaningful Phrases is the alter ego of DRY. DAMP tests often use the builder pattern to construct the System Under Test. This allows calls to be chained in a fluent API style, similar to the Page Object Pattern. Internally the implementation wil…