This is my list of little tools and helpers that I install on all my devices. It was inspired by Scott Hanselman's Ultimate Developer and Power Users Tool List and some tools may overlap. Nevertheless, there are plenty of differences and I'm sure that you will find one or more gems that simplify your developer life. If you know a tool that is missing and is a must-have, please leave a comment with a link to that tool.
Git diff does its best to figure out if it can show you the differences in a file. However, sometimes this does not work - even when the file you are interested in is a text file. We use the UCS 2 character set for DbUp and Git believes that those are binary files. The resulting output is therefore rather useless:
SonarQube gives us a good and honest overview on the quality of our code. It's most likely not as good as we hoped for and much work will be needed to get it to an acceptable level. But where do we start? And what can we do when we have many projects?
If you follow along with the last few posts on SonarQube, you will now have a working installation that continuously monitors the quality of your code. Today we link Visual Studio to SonarQube using SonarLint.
Running SonarQube manually is a sure way to not running it at all. Sometimes you forget it, other times you know that it's not going to give an "adequate" report and so you better wait a bit with the next run – the only problem is that this next run never happens. If you want to take SonarQube seriously, you must integrate it into your build. This post shows you how you can use SonarQube with your Visual Studio Team Services (short VSTS) builds.
Our first steps with SonarQube could be done without much thought on security, reliability and how we can protect it. If you want to use SonarQube beyond your pet projects, you should start making some changes to your installation.
There are a few rules in SonarQube I find a bit special. I understand their reasoning but believe that the resulting errors aren’t correct or helpful. Should you reach the same conclusion you can follow along to create your own custom set of rules.
Lines of Code (short LOC) are an often used metric to compare projects by their size. All you need to do is to count the lines of source code to figure out if project A is bigger than project B. However, that is only true when they use the same programming language. Only then can you do the same work in a line of code. If you compare Ruby with C or Assembler your LOC metric may differ by many orders of magnitude to get the same things done.
The SonarQube scanner is a simple way to start gathering data on your project. However, the scanner doesn’t know much about project structures and conventions for programming languages. Those things are all included in the build integration, which will be the topic of a later post.
With SonarQube in place and the first project run through the scanner, we are now ready for the interesting part: Analysing our project.