My Workflow Before I Submit Code Changes

For 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 source, I do the three steps below.

1. Run StyleCop

First I run StyleCop (free from Microsoft) to make sure standards are adhered to, makes sure you document your code and more. Actually, before I run StyleCop, I run GhostDoc (free & paid versions from Submain) 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 Submain 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.

Then I submit my code to source control. This is my minimum workflow I do every time and this keeps QA from bugging me and gives me more time to work on features. Of course, I also run unit tests before I start this process.

Unfortunately, Analyze is broken in .NET Core. I’m not aware of when it will be fixed.

Additions to This Workflow

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

4. 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.

5. 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 projects 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 rule set 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.

What is your workflow? Please add a comment below.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s