Clean code core principles

Have you ever faced the problem when your project becomes bigger and bigger, and it’s harder to maintain it, change/add features?

I want to share with you some principles that help me to write a more scalable and maintainable code in React Native. This article more for junior developers rather than for seniors, but I think that sometimes we forget the basic principles, so it can help you to refresh concepts of clean code. So here are the 4 main principles, that help me a lot:

1. Explanatory namings
2. Use comments as little as possible
3. Single responsibility functions
4. Replace ‘magic values’ with naming constants

For each of that principle, I will get more details below.

Explanatory namings

Have you ever seen variables like disabled, active, open in someone’s code? How much time did you spend to figure out the goal of this variable and the reason why it exists?. Do not hesitate to spend time on an explanation of the namings of your variables/functions/files. Names in Software development are determined by 90% of the readability of the whole code! And the most important is that all the developers forget to keep them up to date. For example:

// Dirty
const flag = true
// Clean
const isModalVisible = true

For boolean variables, it’s better to name them starting with “is” or “should”.

// Dirty
const token = 'xxxxx'
// Clean
const firebaseNotificationToken = 'xxxxx'

I highly recommend using longer, but more descriptive names.

// Dirty
const navigate = () => {
navigation.navigate('SettingsScreen');
};
// Clean
const navigateToSettingsScreen = () => {
navigation.navigate('SettingsScreen');
};

In the second example when we will just use the function ‘navigate, it will be really hard to understand what’s going on. At the same time if we are using the second function we won’t need to check function realization. It saves time!

Use comments as little as possible

They say, “Good code is the code that doesn’t need commenting”.In most cases commenting used to explain bad/unreadable code, so in most cases, it will be better to rewrite code to be more understandable.

The second point why a lot of comments is not a good idea is that they become obsolete fast. Why? Because when developer updates code, he usually forgets to update comments. This can confuse those who see this code for the first time or will see it later. If you’re 1000% sure you won’t forget to update your comment after updating part of code, then writing comments is a good case ;)

The third case will be about the commented out parts of the codebase. That code in most cases is with old variables’ names and outdated logic. When you see commented code in a project, don’t hesitate to delete it, because:
a) a version control system remembers it, and you’ll be able to restore it;
b) code will become cleaner
c) your project doesn’t need it.

PS: I don’t mean to skip writing comments at all, sometimes we need to write them for sure. The main idea is to ask yourself before starting to write a comment “Can I make this code easier to understand and more readable?” Such a question will help you to not only avoid unneeded comments but also to improve your code styling as you’ll try to write cleaner and more clear.

Single responsibility functions

There might be a temptation from time to time to put everything that is possible in one function. It may happen for different reasons: deadlines, not experienced enough developers, rush on a project, BUT, believe me, it will be better to separate code in as many small functions as possible. It will help you a lot in the future. For example:

import api from './api';
// Dirty
const sendData = async (data) => {
try {
await api.sendData(data);
navigation.navigate('SettingsScreen');
} catch (error) {
console.error(error);
}
};
// Clean
const navigateToSettingsScreen = () => {
navigation.navigate('SettingsScreen');
};
const sendData =async (data)  => {
try {
await api.sendData(data);
} catch (error) {
console.error(error);
}
};
const sendDataAndNavigateToSettingsScreen = () => {
sendData(data);
navigateToSettingsScreen();
}

If the developer sees code above for the first time and uses the function ‘sendData’ and he won’t even expect the fact that besides sending data to the backend it will navigate to the settings screen. Such side-effects can cause bugs in the future, so it’s better to prevent such situations and don’t waste a lot of time debugging a problem. In other words, “Keep it simple, stupid” (KISS).

Replace ‘magic values’ with naming constants

The rule is very simple, but sometimes developers forget about it. All we know that a project without rush in some moments is not a project 😅, developers forget about future maintenance and changing features. As a result, some ‘magic values’ appear in code and you need to find them then across the whole project, which is, I’m sure you will agree, not the most enjoyable thing in your life. So please waste a few more minutes and put all your magic values into a separate constants file.

// Dirty
// header.js
const styles = StyleSheet.create({
headerContainer: {
height: 56,
},
});
// SecondHeader.js
const styles = StyleSheet.create({
headerContainer: {
height: 56,
},
});
// Clean
// consants.js
const customHeaderHeight = 56;
// header.js
const styles = StyleSheet.create({
headerContainer: {
height: customHeaderHeight,
},
});
// SecondHeader.js
const styles = StyleSheet.create({
headerContainer: {
height: customHeaderHeight,
},
});

As a conclusion:

Writing clean code is the core skill for each developer, so take your time and don’t hesitate to spend a bit more to write better and cleaner code. If you want to receive more insides on the theme of cleaner code, I highly recommend you “Clean Code” by Robert Martin.

Thank you for reading. If you have some questions/improvements reach me in comments or Linkedin.

Author: Kirill Kohan