Cleaning Dust Mop
Pixabay at Pexels

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Martin Golding

You’ll find these tips to be independent of most programming languages. These rules are invaluable for both beginners and experienced programmers. If you endeavor to follow them, you won’t have to fear the psychopath.

Writing clean code makes the code easier to understand going forward and is essential for creating a successful maintainable product.

We are authors and artists. The computer does not care for art, it cares that the code compiles. Your fellow developers, however, do.

To be able to write clean code you must take the hardest step: start. As time goes by and your skillset improves, it becomes easier. Writing clean code is all about readability, so even the smallest things like changing your habits for naming variables make the most significant difference. It’s not about writing the least code. It’s not about writing “clever” code. It’s about easily readable, self-documenting code.

…code is clean if it can be understood easily — by everyone on the team. With understandability comes readability, changeability, extensibility, and maintainability.

Robert C. Martin, “Clean Code: A Handbook of Agile Software Craftsmanship”

General rules for writing clean code

  • Follow standard conventions. You can find guides for almost any language on GitHub.
  • Simpler (not clever or so minimal nobody knows what it does) is always better. Reduce complexity as much as possible.
  • Always find the root cause. Always look for the root cause of a problem.
  • Be consistent. If you do something a certain way, do all similar things in the same way.
  • Use explanatory variables.
  • Prefer dedicated value objects to primitive types.
  • Avoid logical dependency. Don’t write methods that work correctly, depending on something else in the same class.
  • Avoid negative conditionals.

Names

Use intention revealing names. Choosing proper names takes time but saves more than it takes. The name of a variable, function, or class should answer all the big questions. It should tell you why it exists, what it does, and how it’s used. If a name requires a comment, then the name does not reveal its intent.

Essential Rules for Names:

  • Choose descriptive and unambiguous names.
  • Make a meaningful distinction.
  • Use pronounceable names.
  • Use searchable names.

Functions

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. It implies that the blocks within if statements, else statements, while statements should be one line long. Probably that line should be a function call. Not only does this keep the enclosing function small, but it also adds documentary value because the function called within the block can have a nicely descriptive name.

Essential Rules for Functions:

  • Small.
  • Do one thing.
  • Use descriptive names.
  • Prefer fewer arguments (no more than three of them).
  • Have no side effects (Functions must only do what the name suggests and nothing else).
  • Don’t use flag arguments. Instead, split the method into several independent methods that are from the client without the flag.

Comments

Ideally, comments are not required at all. If your code needs commenting, you are doing something wrong. Our code should explain everything. Modern programming languages are English, like through which we can easily justify our point. Correct naming can prevent comments.

Essential Rules for Comments:

  • Use as an explanation of intent.
  • Use as clarification of code.
  • Use as a warning of consequences.
  • Always try to explain yourself in code.
  • Don’t be redundant.
  • Don’t use closing brace comments.
  • Don’t comment out code. Just remove.

Objects and data structures

Objects hide their data behind abstractions and expose functions that operate on that data. Data structure present their data and have no essential functions.

Essential Rules for Objects and Data Structures:

  • Hide internal structure.
  • Prefer data structures.
  • Avoid hybrids structures (half object and half data).
  • A small number of instance variables.
  • The base class should know nothing about their derivatives.
  • Better to have many functions than to pass some code into a function to select a behavior.
  • Prefer non-static methods to static methods.

It may not be possible to apply all of these rules in your daily code in an instant. But as a result, it will bring great satisfaction from your work and sincere gratitude from people who will read the clean code that you wrote.