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"?
Anyone who has written unit tests have been fighting with object creations. Some times it is so difficult to create objects used in tests. Test data builders come to rescue! With them I write better tests with less time.
Readability is key point in unit tests. One common antipattern with unit tests are setup methods, because they make unit tests more difficult to read. Here I have written how helper methods can be used instead of setup methods to make unit tests more readable.
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.
"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).
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.
"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.