For the past 2 years, I’ve been blogging quite regularly about different subjects, but the past 3 weeks, I haven’t found any inspiration nor time to get something on… digital paper.
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.