Static Analysis with NDepend

Static Analysis has interested me for nearly as long as I’ve been coding, so when I was offered to try out NDepend I got really excited. I already rely on the warnings the compiler can give and code analysis rules for my projects and a tool such as NDepend seems like the next logical step. I was not disappointed.

I think that the code analysis rules offered by Visual Studio are powerful and helps improve code quality, but they have a user experience that’s more punishing than encouraging. Code Analysis rules are evaluated after the code is written and after it has passed the compilation – which means when you are sort of done. Then it comes and tells you that you’re not done. That’s demoralising. There’s also no hint of how many rules you did in fact dit pass. The NDepend analysis is different. It is run from the NDepend Dashboard and it shows not just rules violations, but it can also show that your code is good.

Code Coverage on GitHub PRs with Coveralls.IO

2016-06-05 18_01_53-KentorIT_authservices _ Coveralls - Test Coverage History & StatisticsWith Coveralls.IO it’s possible to get code coverage on all pull requests submitted. For Kentor.AuthServices I’ve set up AppVeyor builds that uses Coveralls.Net to upload coverage numbers to Coveralls.IO.

Why Coveralls.IO?

When I set up the code coverage I already had AppVeyor builds running. I wanted something that worked together with AppVeyor. I tried out a few options and quickly found out that I also wanted something that used the Visual Studio Code Coverage engine. The project had 100.00% coverage in Visual Studio when I started and when I tried another coverage engine it showed some lines as skipped. I wanted consistency with the Visual Studio Code Coverage, which coveralls could give me.

The Continuous Improvement Mindset

Following Hakuna Matata or always striving for perfection are two very different ways of living your life. In the short term Hakuna Matata (which means “No Worries”) looks tempting, but there’s also happiness to be found in the strive for perfection through a continuous improvement mindset.

Image courtesy of Wikimedia

Image courtesy of Wikimedia Commons

Earlier this year I went on a skiing vacation for a week. Looking at the people in the slopes, there were many different styles of skiing. Some were good, some were bad. Some looked concentrated, some looked happy. But I think that everyone enjoyed being there. During the week I thought about different mindsets for skiing (mindsets that are also applicable to programming, don’t worry – this post is about programming and not only skiing).

I think that by just watching the people skiing, they can be grouped into four categories that reveal their mindset. Are they living by Hakuna Matata or are they continuous improvers that always want to learn? Those different mindsets are important when you form a software development team.

Do you Care About Your Code?

A true master craftsman of any profession takes pride in doing a great work. A masterpiece is recognized by the combination of a great total impression and worked out details. Most programmers tend to think that their latest code is a masterpiece. I even went as far as starting this blog, to show off all the masterpieces of code I write ;-).

The sad truth is that looking thoroughly at some code it’s often far from the carefully worked out details of a true master piece. Let’s look at an example of how code can look and try to get it right (according to my definition of right).

public class Car
{
        [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Naming", "CA1709:IdentifiersShouldBeCasedCorrectly", MessageId = "reg")]
        public string regNo { get; set; }
    public string Brand { get; set; }
 
    /// <summary>
    /// Drive the car
    /// </summary>
    /// <param name="speed">Speed to drive at</param>
    public void Drive()
    {
        Debug.WriteLine("Driving car!");
    }
 
    public void DragRace(DragStrip strip)
    {
        while (!strip.AtEnd)
        {
            try
            {
                Drive();
            }
            catch (Exception) { }
        }
    }
}

This is not real code from a project (if it was, I would need stress therapy), but I’ve seen all of these examples in live code. If I found this during code review, there would be a number of things I would point out.

Software Development is a Job – Coding is a Passion

I'm Anders Abel, a systems architect and developer working for Kentor in Stockholm, Sweden.

profile for Anders Abel at Stack Overflow, Q&A for professional and enthusiast programmers

Code for most posts is available on my GitHub account.

Popular Posts

Archives

Series

Powered by WordPress with the Passion for Coding theme.