If you're only going to do one thing, and one thing only, in regards to make your and your team's code cleaner, it is without a doubt (in my mind) to start review every code change that enters your programs. No, code reviews in itself do not create cleaner code, but it does promote following the paradigms your team deliberately or not have agreed to follow. And that is a considerable step towards clearer code.

How so, I hear you ask. The team, you may argue, might not have adopted the correct clean coding paradigms. Or the team might not even have thought about what clean code is or how it should be implemented. Or why?
Well, here's the thing. While there are a lot of guidelines, tech and principles to guide you in creating cleaner code that you and your time might think you know nothing about, I'd wager a buck or two, that you already do a lot of clean things.

You might already

• choose good variable, class and method names
• remove redundant code
• remove obsolete comments
• use specific code patterns for common solutions

But all the things you do, individually as team members, may differ from how other team members would do it. Quite often, team members of a team have a good grasp of how to write readable and maintainable code, but these methods aren't synchronised between team members.
Or there may be new team members that haven't yet come to terms with how the code is written in your team.

Enter code reviews

When you start reviewing every code change that enters the source control, you not only review for bugs or mistakes, but the reviewer will also check for readability and maintainability issues. Does this variable name describe what it holds? Is that redundant code? Why aren't you using that generic class we have in this or that library?

A good code review is not just about finding mistakes, it's about spreading information and knowledge across the team. It's about synchronising team members, so they know what principles, guidelines and patterns to follow.
It's about jelling the team together, making it more effective and productive.

So, how to get started reviewing code

A couple of common concerns about reviewing code

• We don't have any code reviewing tools, and we need to evaluate which to acquire
• Should all code be reviewed even if only a typo of a label is fixed

There are many very nice tools on the market to help you do code reviews very easily. They often come with whatever source code repository platform you choose, Bitbucket, Gitlab or whatever. And it can be a handful to evaluate them and get the organization and the whole team to agree on which to use.

But here's a (not so secret) secret. You don't need a tool to review code. You have an IDE, don't you? It may be Visual Studio, Eclipse or just notepad. Tap a colleague on the shoulder and ask him or her to come over to your work station and go through to code together. That's a code review. And not only is it a code review, but it's also a session of pair programming.

And yes, all code should be reviewed. Even just a typo. It shouldn't and mustn't be up to the programmer to determine what scope of changes should be reviewed or not. Every single change to the code must be reviewed to enter the code base.
But won't that result in a gigantic load of code reviews? If every single change must be reviewed? Well, no. Small changes to the code are very fast to review, probably just a few minutes of work. Larger ones, of course, are harder to review. A suggestion for reviewing larger code changes is to do them as a pair programming session.

Read more articles like this on my blog https://codingcleaner.com