How to make a code review

If peer review of your code is new to you, you should read on.

No code should be put in production without a peer review.

When reviewing code, you are typically looking at a comparison between the original version and the new version. Meaning that the changes are highlighted.

On GitHub the difference can be presented like this.

Example of a code change

The example comes from an unexpected error in one of my automated tests.

What you should be looking for

As you get more and more experience with writing good AL code, your intuition will improve. What it means is that you have to listen to your gut feeling when looking at the code. If your gut is telling you that something is off, dive deeper into the code. You should avoid saying, “Well, it is probably OK.”

If you have a doubt about what is going on, ask your colleague to explain it to you. When you are writing your code, it is also important that you ask yourself if your code is easy to read and how you will explain it.

Task dependent observations

When you are given a task, you would like to have a good description what you have to do. Sometimes you get a good description of the problem or feature, but sometimes you only get a one-liner and you have to investigate yourself. In general, I recommend that you leave a description for the person who is going to make the code review. Otherwise, it can be difficult to make a good code review.

Ask yourself:

  • Does the change correspond to the description in the User Story or Bug task?
  • Do you understand the change? Does it make sense?

Task independent observations

So the code does what it is supposed to do. So we can stop our review. Right? No!

Even without understanding why the code was changed, you can make observations. These are the same when you are looking at the initial code, where the entire code is the change.

  • Is the code easy to read and understand?
  • Can you explain the code to a colleague?
  • Is the code following the standard Microsoft coding guidelines?
  • Is the code following your own guidelines?
  • There might be some best practices in your company that your colleagues would like you to follow.

Clean AL Code Initiative

Why is this important?

It is quite exceptional if you can write your code perfect the first time and never touch it again.

The reality is that we change our code over and over again. Not just ourselves, but most of the time we are changing someone else’s s code or they are building on top of our code.

The reasons for keeping your code nice and crisp are

  • Respect for your colleagues.
  • Respect for your customers and your users.
  • It is simply good business. Bugs are a waste of time and money for everyone.
  • Because you are professional and you are proud of your craft.

Get in Touch

You got this far and you are still hooked on the idea of code review. I can help your team getting stated. I have a lot of experience and will continue this great habit.

If you are a Business Central or Navision customer, I can help you check the quality of the solutions your partner has delivered to you.

I would love to hear from you and help you on a journey to writing better code. Finn