After all these chapters – all these patterns, principles, and so on..there are still a few things that should be taken into account when writing code.

Maybe these are among the most important ones, because they are very common – and they are not related to a specific programming language, nor on design principles, but on how you write the code.

There are a few things you need to consider:

Naming methods / variables

This is the most important part of being a programmer – naming things. Improper naming reduces readability, and in the end, productivity also. If you’re using variable names such as a, b, c – trust me, your team will hate you.

Dependencies

Using excessive dependencies is problematic. Not only they mean slower compile times, but it’s more work added on the other programmers when trying to read the code. Use libraries or headers when you need them, not just for the sake of it.

Documentation

We should always strive to write properly documented code. This involves adding comments when necessary, but documentation can also be done through code refactoring, unit tests, by using uniform syntax, and proper naming.

Formatting

Inconsistent formatting can also greatly affect readability. Select a convention and use it throughout the project.

This refers to the naming (someVariable, some_variable, SomeVariable, etc), to the indentation (tabs vs spaces and the length of the spaces), positioning of the braces (on same line, on next line), using spaces or not in the function argument list, and so on.

Error handling

Always expect nothing from other people’s code. This is available for yours as well. Errors can occur, from an API error, from a timeout, from a type mismatch, from an empty pointer, from an exception, etc.

Always validate the input you receive.
Always assert the output you provide.
Always treat error cases.

Most of the developers will want to return a general result code saying that an error has occurred, because it’s a lot less work and simplifies the code much more than returning and handling specific errors. If you care about the code, you should return a specific code for each possible error, and also explain what the error means and what the user should do about it, if there’s anything they can do. Having specific errors also allows you to localize the error message and why it occurred.

Do not leave silent errors.

You should not let untreated cases, as they will most likely lead to unexpected behavior. If something is out of scope for now, leave a comment, raise an exception, whatever it may be, just make sure that there's a way to remember that the technical debt is there and it needs to be fixed / implemented later.

Good practices / Do’s

Bad practices / Don’ts