7 Tips to Improve your Code
The main issue when we are coding something is trying to test it as a whole thing. That’s not completely wrong, but it’s worth dividing the problem in more atomic and isolated tasks to complete them in an easier way, delegate some of those tasks and even find dependencies to complete your code instead of develop it from scratch.
In the last years I was learning the best way to write code avoiding the typical problems related to code difficult to understand, difficult to follow, hard to trace, hard to fix and, of course, impossible to maintain.
To test better you need to tidy up better your code. The unit testing and even the whole process of testing, whatever it is, it will be hard and difficult to do if your code has some of the following problems:
More than one responsibility
We’re talking here about the modules or classes. The packages, applications or whatever high level system of organization your language or platform has it’s discusses more in advance.
The class or module you are developing should have only one responsibility. This means the class have to do only one thing or things related to this thing, but no more… and no less. And it’s important remark “and no less”. If you fragment the responsibility in several classes or modules you can get ravioli code too fast.
For example, if you are developing a system where the users can publish posts and make comments for those posts, the correct separation is: user, post and comment. Add a comment should be in the comment part and not in the post part, because if you do that, you are putting the responsibility of adding comments to the post. And you are removing that responsibility from comment.
Avoid the interdependencies
An interdependency is created when a module needs the functions of a second one module and the second one is needing functionalities of the first one.
The dependencies should be always vertical. In case we need functionalities which are not clear if they belongs to a module or another, maybe it’s a good idea create a weak-module containing this new feature and keep it below in the dependency hierarchy.
For example, if we want to create threads for our comments linked to a post, we can create the new module or class named thread instead of adding new responsibility or fragment that responsibility between several modules.
Avoid too fragmentation between packages
The packages can contain more than only one class and obviously could have more than one responsibility. The main function of those packages is tidy the code in organizational units.
Each package should have its own contract for calls outside of the package and the documentation should cover all the possible usages.
In our example, we can put comment, post, user and thread in the same package named blog. If we need to add more features like “likes” or “recommendations” we can add a new module/class inside of the package. No problem. This new feature can have new functions/methods to be called from outside and its own part in the documentation.
If we create a new package for every feature it could increase the difficulty to test our code, document it and link concepts clearly.
Respect the contract
Even if you need to access to something outside of the contract, don’t do it! Use some feature don’t documented and outside of the general contract creates an internal dependency and do harder the refactoring work.
If you are writing tests and you realize there are no possibility to access to information you need to check the internal state, or what happened with the execution of your code, maybe you need more features or functions for your contract. Don’t try to break the contract, because if you do that, the following changes in your code always give you errors and your tests could be illegible.
No “utils” module, be more specific!
In the code the most of the people create always a utils module or class, or even package, to put there the functions or methods which they think don’t fit well in any of the other modules/classes or even other packages.
That’s completely wrong!
If you find there are no enough functions for date handling you can create your own “date” module and in the same way with whatever other kind of functions/methods.
Be careful with mocks and stubs
It’s normal to use mocks or stubs when we want to test only one module. The rest of the modules could be mocked to ensure always they are returning the same values. But if the other modules could be in use for the test with only setting them up, it’s worthy to do it instead of mocked them.
In this way we will using the most of the real code and some fail should be detected faster.
In the same way, never mock functions/methods of the module/class to be tested!
Don’t abuse of the try..catch structures
Maybe in some languages the defensive programming could sounds like a good idea, but it isn’t actually. The most difficult fails to find and solve are those that is not showing a trace or the error itself. You can only see a misbehaving and that’s difficult to trace and solve.
I think those are the most representative issues I found and I always try to fix to avoid waste a lot of time writing, testing and releasing code. Maybe I miss other important tips if you think there are more to keep in mind, please comment them and share with all of use.
