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.
Checking in Code Changes
Before I check in any code changes or additions to source, I do the three steps below.
Run StyleCop
First, I run StyleCop (free from Microsoft) to make sure standards are adhered to. It 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.
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 will fix it 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 where I worked I estimated it could save them over three million dollars per year.
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 it 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.
Additions to This Workflow
Before I consider a feature done, I also do the following.
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.
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 this tool.
- 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.