What is clean code? Well, in simple terms, clean is basically code that can be easily understood and modified.

Why clean code? You need clean code because code is meant to be read by humans not by machines, the cleaner it is the easier it will be understood. You’ll be building systems that are not static and will be expanded/changed when new requirements arise, and because the code will have bugs and they need to be fixed. There is also another very important reason, when someone else (or maybe even yourself after a few months) needs to use or change the code it will be easier for them to be productive if they can understand your code quicker.

There are a few tricks you can use, no matter your level of experience, you can use right away to make your code cleaner: Small functions and Good naming (in variables, functions and classes). Although there are more, my experience has shown me that those two alone will have the bigger impact for lowest effort, because for the most part it’s not a matter of skill/knowledge, is just a matter of caring.

Small Functions

As you know, the best way to solve a problem is to split it into smaller pieces. This is exactly what this trick is all about. A big function is harder to debug, change and test than a set of smaller ones. An additional benefit of this is the ability to reuse code. So, all you need to do is to make sure a function will only do one thing and do it well.

The key benefits are:

• Improved code readability: if the functions are small, it will easier to browse through the code, and will take less cognitive effort to understand what it does.
• Code reuse: when the functions are small and only one thing there will be a bigger chance for it’s reuse.
• Easier testing and debugging: smaller code blocks are obviously easier to test using unit tests. At the same time, they are also easier to debug.
• Easier refactoring: when your code is doing only one thing and it easier to move the code around because it will have less dependencies and, using the IDE tools, it is very easy to rename it, for example.
• Easier to name properly: having a small concise function will make it much easier to name it accurately!

Tip: if you consider use “and” or “or” in you function name to convey its meaning you are probably doing too much in a single function. Consider breaking it.

Good Naming

Having things named right is hard! The golden rule is to have the name clearly describe its meaning. However, you should take the additional effort because will pay-off big time throughout the development life cycle. When you see a reference of a variable, function or class, you can infer what it is and/or what it does without having to investigate its details.

The key benefits are:

• Improved code readability: When a variable, a function or a class are well named the code will become much easier to understand because you can infer they’re meaning or purpose without the need to investigate the details.
• Improved team performance: when the team uses the same name conventions, you’ll feel right at home changing another person’s code.
• Improved maintainability: When you use names from relatable to the domain, you can count not only on the technical team, but also on the business teams because they will be able to relate and understand questions you might have.

There are a few rules of thumb when it comes to naming things:

• Naming protocol: you can find names that make sense to you, but you must consider how much sense they will make to others. In most cases it is a safe bet to use names that most programmers can understand (e.g., “iterator”) or domain specific names.
• Respect language standards: You must respect language standards like casing. For example, in java all functions and variables names should be in Camel Case, and classes and interfaces in Pascal Case.
• Searchable names: it is a good practice to make you names easily searchable. For example, searching for a single or double-letter names will yield much more results than you wish. Another example is using a well named constant instead of number (e.g. PAGE_SIZE=10 instead of just “10”).
• Pronounceable names: it will make it easier to remember and to discuss you team members, when, for example asking questions.
• Don’t add the type to the name in variables: That is just noise. Most times, the tooling will warn if you mess up with the types, and if you need to change the type you will also have to rename the variable in every single place to avoid disinformation.
• Classes should be named using nouns or noun phrases: A class names should not be a verb because a class is a thing.
• Functions should be named using verbs or verb phrases: A function does things, it is not a thing.

Conclusion

Although this is a very simple set of rules, I keep seeing bad code being written by junior and senior developers alike. Just start using them right away and this for sure will make your future self much happier!

As professional developers we need to be responsible for our code, having it work is not enough! A good professional takes care of its code and must make sure what he/she releases is the best they can do, not only for themselves, but also and foremost to be used by others.

There are quite a few more techniques to make you code clean. Robert C. Martin has two books dedicated to this subject (Clean Code and Clean Architecture), these books are quite complete, and provide an in depth set of techniques to build and design clean code. I urge you to read them!

References

Martin, R. C. (n.d.). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. Retrieved 8 13, 2019

1export const getStaticProps = async () => {
2  const strapiData = await apollo
3    .query({ 
4      query: getArticlesPage,
5    })
6    .then((res) => res.data || {})
7    .catch(err => console.log(err))
8
9  const { pages, articles } = strapiData;
10  return {
11    props: {
12      page: pages[0] || {},
13      articles,
14    },
15  };
16};

PAGE_SIZE=10