This is the first code review where I showcase some real-world code example and
nitpick suggest improvements in it. If you want to learn more about this new format, check out this post. You can also request a review yourself. To do that, use the form on this page.
When I started this blog, I had one idea in mind: create some sort of repository of programming principles and practices so that I myself and other people would have an easier time navigating around them. That’s a nice goal to aim for but I noticed that when it comes to the actual process of writing code, having such a repository is often not enough.
This is a continuation of the topic of error handling. We’ll discuss what an exceptional situation in code actually is and see some examples of it.
In this post, we’ll look at some practical examples of error handling. We will see whether it is better to use exceptions or the Result class to deal with errors.
Today’s topic is about interfaces for repositories. Should you introduce them? Or maybe it’s better to use repositories as is? Let’s see.
This post is about some bad practices in using automappers.
Today, I’d like to talk about the (sometimes subtle) difference between 4xx and 5xx response codes when programming a RESTful API. I’ll try to show when to return what code (400 or 500) and introduce a simple way to implement this logic on the server side.
This topic might seem trivial, especially if you look at all other articles that have beaten it to death already. But I would still like to make a couple of important points here. So, how long should a single method be?