My Workflow Before I Submit Code Changes

Code Shark - Sticker - 2020@0.5xFor many years when speaking at conferences, I have shared my workflow on what I do before I submit code changes to source control. This article will explain it more in detail. I share this workflow because it makes sure that I rarely get bug tickets from quality assurance and hopefully it will for you too.

Checking in Code Changes

Before I check in any code changes or additions to the source, I do the steps below.

1. Run StyleCop

First I run StyleCop (free from Microsoft) to make sure standards are adhered to, make sure you document your code, and more. Actually, before I run StyleCop, I run GhostDoc (free & paid versions from since it makes it easy to add proper XML comments to my code and proper headers to each file.

2. Run CodeIt.Right

CodeIt.Right from is a static code analysis add-in to Visual Studio. It follows the same rules as FxCop/ Analyze. The best part of CodeIt.Right is that it not only finds violations but 90% or more of them it will fix for you, properly, using good coding standards and patterns. It can save your company tens of thousands of dollars per year and more. At one company I worked at I estimated it could save them over three million dollars per year.

3. Run Analyze in Visual Studio

To make sure CodeIt.Right found all the violations, I run Analyze in Visual Studio. If it finds anything then I fix them and start these steps over. If you do not have Analyze in your version of Visual Studio, you can run FxCop on the compiled assemblies.

4. Run Unit Tests

Next, run the unit tests for the project/ solution. No unit tests? STOP NOW and start writing them! How can you push code if you are unsure it even works? Just because the projects build, doesn’t mean everything is okay. Teams should strive for at least 75% code coverage.

Additions to This Workflow

Before I consider a feature done, I also do the following.

5. Run .NET Memory Profiler

Next, I run .NET Memory Profiler from SciTech Software. .NET Memory Profiler is a powerful tool for finding memory leaks and optimizing the memory usage in programs written in C#, VB.NET, or any other .NET Language. With the help of the profiling guides, the automatic memory analyzer, and specialized trackers, you can make sure that your program has no memory or resource leaks, and that the memory usage is as optimal as possible. I run this on the application preferably on a dev server or performance testing server else I run it on my local machine. This is the only way to make sure there are not any virtual memory leaks in the application.

6. More Testing

If you are lucky enough to have performance or UI tests for your project, then run them too.

Odds and Ends

To help me in my workflow, I use and recommend the following.

  • CodeRush from DevExpress: Refactoring tool that also makes it easy to find defects and runs unit tests in half the time and lots more.

Also, make sure that in all of your project properties to select “Enable Code Analysis on Build” in the Code Analysis tab (this currently does not work for .NET Core or Standard projects). This is the ruleset that I usually select.

  • Microsoft Managed Recommended Rules for DLL assemblies.
  • Microsoft All Rules for applications including ASP.NET.

This will ensure that analysis will be done on every build. This is very important since it is much cheaper to fix bugs when writing the code as opposed to the user finding it later.