Become a Cleaner Coder Quickly

DZone 's Guide to

Become a Cleaner Coder Quickly

No one likes gross code.

· Agile Zone ·
Free Resource

What is the clean code? Well, in simple terms, clean is a 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 meter 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 a bigger impact on the lowest effort because for the most part, it’s not a matter of skill/knowledge, it is just a matter of caring.

Make your code this clean!

Make your code this clean!
You may also like: Why Clean Code Matters

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 its reuse.
  • Easier testing and debugging: smaller code blocks are 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 fewer dependencies and, using the IDE tools, it is very easy to rename it, for example.
  • An additional benefit is that having a small concise function will make it much easier to name it accurately!

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 it 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 your names easily searchable. For example, searching for a single or double-letter name will yield much more results than you wish. Another example is using a well-named constant instead of number (e.g. “PAGE_SIZE” instead of just “10”).
  • Pronounceable names: it will make it easier to remember and to discuss with your 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: class names should not be a verb because a class is a thing not do a thing.
  • Functions should be named using verbs or verb phrases: a function does things, it is not a thing.
    • Tip: if you consider the use of “And” or “Or” in your function name to convey its meaning you are probably doing too much in a single function. Consider breaking it.


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 your 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!


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

Further Reading

Should I Still Be a Programmer After 40?

The Importance of Comments for Maintainable Code

clean code, functions, junior developers, naming, tips and tricks

Published at DZone with permission of João Carias . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}