_{Code review! Image taken from Unsplash}

Hey, folks!

I have now been away from the Hive network for quite some time as I have been focusing on work and applying for a Master's degree (if you would like to hear about that, let me know!). However, I feel that after coding day in and day out, I need a creative outing for myself – what better way than to write educational blog posts for you!

I have now been a full-time software developer for half a year. I still consider myself a very junior-level developer, however, I already feel that I have ideas, practices, and thoughts to share about my programming journey. Here are three tips and tricks for you to follow while coding.

The DRY principle

You might have heard of this principle before. If not, DRY stands for Don't Repeat Yourself. The name of the principle is quite self-explanatory, but here's also some pseudocode. Let's imagine that we have three HTML buttons (<button> elements) with id values, all of which need the same EventListener added to them through JavaScript.

// Get the buttons from the DOM

const button1 = document.querySelector('button#1');
const button2 = document.querySelector('button#2');
const button3 = document.querySelector('button#3');

// Add the EventListeners
button1.addEventListener('click', () => {
  console.log('Button 1 clicked!');
});

button2.addEventListener('click', () => {
  console.log('Button 2 clicked!');
});

button3.addEventListener('click', () => {
  console.log('Button 3 clicked!');
});

And that's our code done! When you click a button, the console will output which button you have clicked. This code is good, right? The answer is no.

While the code does everything correctly and as we expect it to, we have just completely forgotten about the DRY principle. Here is the pseudocode after following the principle:

let buttons = [];

[1, 2, 3].forEach(number => {
  buttons.append(document.querySelector(`button#${number}`));
})

buttons.forEach((button, index) => {
  button.addEventListener('click', () => {
    console.log(`Button ${index + 1} clicked!`);
  });
});

In my opinion, the above code looks much better: it is shorter, we haven't avoided the DRY principle and the code looks... cooler. 😎

If you want to take this even further, we could make a separate function to add the EventListener to each button:

const addButtonEventListenerById = id => {
  const button = document.getElementById(id);
  
  button.addEventListener('click', () => {
    console.log(`Button ${id} clicked!`);
  });
};

[1, 2, 3].forEach((number) => addButtonEventListenerById(number));

Even better, innit? I think it is.

_{I hope there are no errors in my code. 😬}

---

Code reviews are very important

It is quite obvious that in an IT company, you should not push code directly to the master branch (there are some exceptions). Hence the need for code reviews: you write some lines of code and another person takes a look at the code and whether it breaks the application or not. In our business, we always review other people's code – we have four developers and if one of the developers writes some code, the other three always review it.

Code reviewing is very important. Even if the change is a one-liner, it must go through the pull request and review phase. If you change one line (or just one character) of code, you might feel that it can't change anything, but if you have a very extensive application, this minor change might break something somewhere that you can't even imagine (trust me, I've been there).

Another very important point to be made is that while reviewing, you should pour your whole heart into testing every nook and cranny of the code. You should also not just browse over it, but also try to understand how, where and why the change was made. If you understand the code thoroughly, you might also find some more hidden problems with the code. As a bonus, for a junior developer, you also understand the codebase more than before.

---

_{Squeeky clean. Image taken from Unsplash}

The boy-scout principle

Another principle most of you have probably heard of before. If you haven't, the principle is very simple: always leave the code better than you found it. Why is it the boy-scout principle? Because they are taught to leave the campsite cleaner than they found it.

It is a very simple, yet very powerful principle. I have opened pull requests on GitHub that reference an issue, for which the fix (in my eyes) was to change two lines of code. However, after diving deeper into the code, I understood that while changing the two lines of code fixes the issue, the real issue lies much deeper in the application.

This meant that the pull request turned into a comprehensive refactor of a part of the application. The refactor didn't only fix the issue at hand, but also made the code stronger and more reliable.

---

Thank you for reading!

If you would like to learn about more coding best practices, I would advise you to read a book called "The Pragmatic Programmer" written by David Thomas and Andrew Hunt. It is an excellent book, which dives deep into the software developing world and it's best practices and just overall things to keep in mind to write beautiful code.

If you have any questions or wish to correct me in my thought process – feel free to let me know in the comments!