Last week I stumbled upon code that I could not let go unrefactored. The developer who wrote it already got to hear this rant, but I thought I’d repeat it just so my nice readers won’t make the same mistakes.
A while ago, I added support for Areas to the AddFeatureFolders Nuget maintained by Scott Allen and I wrote about what I build. Now I’ve improved how the Nuget finds features in areas that reside in sub folders. So check out the newest version of the Nuget package to take advantage of deeper feature folder support for areas.
To get information about an object, I mostly overload the
ToString method to display information in the local debug or the popup window. Then I found out that there is another way.
In May of this year, I wrote an article on how to get JetBrains Rider to generate SpecFlow files. The biggest problem I still had back then was that I couldn’t generate the step definitions. I finally found a workaround so I don’t need to use Visual Studio anymore.
While optimising a query, I noticed that a many-to-many relationship still used a class in between. There is a more optimised way to configure many-to-many relationships in Entity Framework.
In the last post about what I learned in NDepend, I’ll talk about a pragmatic approach to deciding where to refactor code. The combined views of Queries and Rules Explorer, the Queries and Rules Editor and the Metrics view. On their own, they are not that helpful, but combined they contained a trove of data.
The graph is a good way to understand the structure of smaller projects, but gets messy in larger projects. That’s why I compare the matrix of a big project against the matrix of the smaller project.
Since some time, I’ve been wanting to use the NDepend tool to analyse the code base I’m currently working on. Then the opportunity presented itself for me to test out NDepend and see how it can help me understand my current code base better.