Once upon a time it was declared that an Assert statement should have constraints given as AreEqual and AreNotEqual. Further it was declared that it should be written in the opposite way of how a developer will think, that is with the expected value first and the actual value last. Why this was made so, is still unclear.

And then we end up with tons of code like:

Assert.AreEqual(“Zulu”, zulu.Name); Assert.AreEqual(“Z - Zulu”, zulu.Description); Assert.AreEqual(FlagType.Signal, zulu.Sort); Assert.AreEqual(0.7, zulu.AspectRatio);

If you have projects created under Visual Studio 2010 (SP1), and mixed C++ and C# projects in the solution, and you are using other configurations than Debug/Release x86 you may hit a very strange situation when you run the Static Code Analysis, either alone, or as part of the build.

You may get into a situation which seems like things go in circles.  One error points to a place where it simply points back to the first one.  This is in fact, two kind of errors causing this behavior.

Find the video HERE.

Updated June 28th 2012:  Marcel has blogged about this too.

Adam Cogan did a great Web TV interview with Marcel de Vries and myself on the topics of architecture and code quality.  It was real fun participating in this session.  Although we know each other from the MVP ALM community,  Marcel, Adam and I haven’t worked together before. It was very interesting to see how we agreed on so many terms, and how alike we where thinking.  The basics of ensuring you have a good architecture and how you could document it is one thing.  Also, the same agreement on the importance of having a high quality code base, and how we used the Visual Studio 2012 tools, and some others (NDepend for example)  to measure and ensure that the code quality was where it should be.  As the tools, methods and thinking popped up during the interview it was a lot of “Hey !  I do that too!”. 

Introduction

Recently I have been involved in some projects to improve the software quality of their code base.  These code bases have been rather large, and in some cases consisting of both managed code, C# and C++, and Native code in C++. The reasons for improving the code base comes from a realization of the relationship between non-optimal coding practices and runtime incidents.  Runtime incidents can be anything from exceptions, out of memory conditions to functionality simply not working at all – some times with no apparent reason or messages appearing.

I like Code Metrics.  They give a certain "objective" evaluation of a piece of code.  You can use it for yourself just to make it pinpoint potential trouble areas, or just some code where you were a bit sloppy - happens from time to time......  And when you're going to do a peer review, it's much better to point to some numbers instead of  the "This code sucks....."-thing.   So when it finally arrived inside Visual Studio I was delighted. 

I like Code Metrics.  They give a certain "objective" evaluation of a piece of code.  You can use it for yourself just to make it pinpoint potential trouble areas, or just some code where you were a bit sloppy - happens from time to time......  And when you're going to do a peer review, it's much better to point to some numbers instead of  the "This code sucks....."-thing.   So when it finally arrived inside Visual Studio I was delighted.