The first draft of this article was about the code-style. I wanted to show you why it is important and why we should care about it. But the longer I thought, the stronger conviction I gained, that the code-style – whatever it means – is only a way to achieve a much more important goal.

I’m a big advocate of well-quality code. Besides good architecture, I pay attention to style – consistent spacing and indentation, coherent naming convention and other rules that make the code visually better. But how to convince someone, who never took care of style before, that is it a good thing?

Repositories are a special example of a class. They usually have a lot of methods designed to retrieve data from the database or the other storage. To mark this operation in the name of the method, we can use one of the common words: find, get, search. Are all them mean the same? In this article, I would like to show you a practical difference between getById and findById methods.

I didn’t always work in a larger team. At the beginning of my journey as a computer programmer, I was the only one person in a project. It meant that I had had a free-hand (or semi-free-hand) to choose how I could write a code and which solutions I could use. From day to day I could perform a little revolution in the codebase. No consequences and no problems because the only user of the code was me.

Although this situation might look as the best case for a programmer, it doesn’t. Especially for the junior programmer. You have no opportunity to learn from someone else. You can’t validate your ideas and thoughts with others. Ultimately your only friends and co-workers are Google and Mr. StackOverflow.

After some time, I got a new job and I started to work as a part of the team. As a new person in the company, I had tons of ideas and tools that we could use in a project to make our work better, more pleasant and easier. It was relatively easy to introduce new features into the codebase. On the other hand, it was almost impossible to remove the old ones. Why?

Because we didn’t have the code deprecation strategy.

When I started my journey as a computer programmer, I had written my code in various way. In most cases, I translated requirements into specific conditions and statements, but I hadn’t taken too much care of readability or quality of my code. “It works, that’s it” – and the code base grew and grew in time. Thousands of written methods later, I had discovered that a lot of these little pieces of logic could look better if I reverse some condition within them. Unconsciously, I’ve started following the rule which I had later called the “fail fast” rule, and subsequently “return early”.

I realized I hadn’t had the one preferred way to check conditions within the single method. Sometimes I let execution if the expression was true. Another time I had waited for the false result to show the error message before the main part of the code was executing. In my head, I discovered various styles of checking conditions.

Loop is the basic construction in each programming language. All repeatable operations are being done using loops. I think you know how the basic loops like while, do and for work and when you should use one of them. But are you sure? Maybe should you use array functions?

How many of your operations in a loop rely on building objects based on the value? Or selecting only a few items from the array using a predicate? Maybe you use array values to calculate something? Whatever you do, read why you should replacing basic loops by array operations.