C# Code Coverage with Azure DevOps

I wrote this how-to blog post for myself to sort out how to get code coverage for C# in Azure DevOps' build pipelines. There are many blog posts about this but this one guides how to get reports even if there are many unit test projects in Visual Studio solution.

“Refactor Early, Refactor Often”

Refactoring is a key factor to get high code quality. Too often we end up in a situation when refactoring is already too difficult. By refactoring constantly we can avoid that trap and keep our code clean.

Write Good Code From the First Commit

Did you know that most of the smelly/bad code is written when code files are created, not gradually upon code updates? I didn't but I found research about it and wrote this blog post. Is it because we think "we will fix this later"?

Comments Lie!

Ron Jeffries has said "code never lies, comments sometimes do". What makes comments sometimes lie? Usually the reason is that we don't keep them up to date. In this blog post I have written about few commenting anti-patterns and how to avoid lying comments.

Let Someone Walkthrough Your Unfinished Code

"Make it a practice to present and discuss each implementation at one-third completion", wrote Adam Tornhill in his excellent Software Desing X-Rays book. Since reading that book I've been thinking about it, and I wrote why I strongly agree with it. Practically it improves code quality (which I value really high).

The Conclusion of The SOLID Principles Series (SOLID 6/6)

I wanted to recap this series about SOLID principles. In my opinion SOLID can be summarized with two things: "Code against interfaces, not implementations" and "write small classes/interfaces". If we follow those two things, our code would be close to SOLID.

Dependency Inversion Principle (SOLID 5/6)

"Program to an interface, not an implementation" is a famous quote by Gang of Four. Even if it is not the definition of the dependency inversion principle, it is really close to it. Another related quote is by Robert C. Martin: "depend on abstractions, not on concretions". While writing this blog post I concretely learned what these quotes practically mean.

Interface Segregation Principle (SOLID 4/6)

Interface segregation principle (ISP) says that clients should not be forced to depend upon interfaces that they do not use. Practically that means that we should have rather small interfaces with just few (or even one) methods than fat interfaces with many methods. In this blog post I will explain what ISP is and what relationship it has with Liskov substitution and single responsibility principles.

Liskov Substitution Principle (SOLID 3/6)

You can't get any idea of what Liskov substitution principle (LSP) is from its name. And its definition is hard to understand. But when you dig into it you'll find that it is quite important and not that difficult principle. It has a relationship with open/closed principle and contract by design. LSP guarantees that every object of subclasses behaves just like superclass. In this blog post I will explain what LSP is and how it helps to make better code.

Open/Closed Principle (SOLID 2/6)

"Software entities should be open for extension, but closed for modification" is the definition of open/closed principle. I learned a lot while writing this blog post. For example I learned what relationship does open/closed principle have with strategy pattern. I will explain also it beside I explain what is the open/closed principle.
This is the 2/5 blog post from SOLID serie. It was worth to write!