I am the author and maintainer of ModelsBuilder, an essential tool for the Umbraco CMS. If you use it regularly, or any of my other Open Source tools, you may want to consider my GitHub Sponsorship Program and help ensure that the tools you depend on are maintained in a sustainable way. Thanks!

FIXME!

Posted on March 16, 2021 in hacks , dotnet

When working on code, I sometime can get deep in "the zone", a creative state where ideas keep flowing and I start refactoring things all around the code base, making quick and dirty changes here and there just to be able to go where I know I want to go. This is accumulating technical debt, and as with any debt, I believe that it can be a good thing, as long as it lets me achieve my goal and there is a reliable plan to repay that debt eventually.

Part of that process requires that that debt can be made highly visible. I love to drop "FIXME comments" in my code for that purpose.

public void MyMethod()
{
    // get a value and use it
    // FIXME this may throw and then we should handle it
    var s = GetSomething();
    
    UseTheValue(s);
}

ReSharper is nice enough to color these comments, and tag them in the scrollbar.

Shot1

ReSharper also provides a useful To-to explorer which provides an overview of all these comments, with a way to easily navigate to each of them.

Shot2

However... dealing with these FIXMEs remain a proactive and somewhat tedious task, and it is quite easy to forget about it, especially if one is prone to procrastination... leading to inevitable debt accumulation.

Show me FIXMEs

I am trying to address this situation via Roslyn Code Analysis. I have created a Comments Build Analyzer (available on NuGet with source code on GitHub) which detects FIXME comments, and creates corresponding warnings that show in the Error List pane.

Shot3

At the moment, FIXME comment are reported with code ZB1001 and FIXME! (note the bang) comments are reported with code ZB1002. All you have to do is install the NuGet package in your project.

Combine this with .editorconfig files, and it becomes even more (painful?) useful. It is possible to use configuration-dependent .editorconfig files by registering them in the .csproj file.

<ItemGroup Condition="'$(Configuration)'=='Debug'">
    <EditorConfigFiles Include="debug.editorconfig" Link=".editorconfig"/>
</ItemGroup>

<ItemGroup Condition="'$(Configuration)'=='Release'">
      <EditorConfigFiles Include="release.editorconfig" Link=".editorconfig"/>
</ItemGroup>

Now, if debug.editorconfig contains:

dotnet_diagnostic.ZB1002.severity = warning # FIXME!

While release.editorconfig contains:

dotnet_diagnostic.ZB1002.severity = error # FIXME!

The FIXME! comments will raise warnings in the Debug build (so they will not prevent you from developing and building and testing, as #error statements would), and will raise errors in the Release build—and thus fail it.

The end result being that, with a properly configured CI, the build would break in case you ever leak a FIXME! comment. I still need to use it for some time and evaluate whether this is really useful,or just fancy, but so far it makes me feel safer.

comments powered by Disqus