The today article is a bit more technical as the previous ones. I think all the programmers have some experience with bad code quality. The first rule of “shity code” is that it was always done by someone else, but not by yourself… At least that’s what I’m always hearing. So I don’t know where are the guys, who are writing the bad code, but once I would be glad to drink a beer with them. The second rule is: the code quality of the project you are working on is always the worst code you have ever seen.

First of all there are a lot of books about how to write nice code. The Bible of this topic is the book “Clean code” from Robert C Martin. But it’s only mentioning how to write a nice code from scratch and not mentioning how to deal with an already existing bad code.

One solution is for sure to refactor the code base, in a lot of situation is means rewriting in fact. But at most of the projects there’s no time or budget for that, so your manager will say a clear “No”.

That means you need to live together with the bad code: stupid naming, monster functions, shared variables, super classes which are responsible for thousands of things and stupid comments. Let’s see how to survive in such an environment.

If you need to understand what the code is doing the best way to do is to go through the code first and after that try to debug it. It is complicated and time-consuming, but that’s the best what you can do in such a situation.

But how to deal with code extensions? If someone needs to add some small functionality or change the current one quite often I see the following solution: “this code is already a big chaos, so let’s just put some new lines to the existing functions or comment out some of them and we are done”. This is the worst what you can do. You are simple encreasing the chaos and the code will be always just worse and worse. First of all: never comment out any line of code, if you don’t need simple delete it. On the other hand: if you need to add something new to such a code always try to add it as seperated as possible: try to create your own class or function which is well designed, has a clear interface, clear responsibility and good code quality. And now the only thing what you need to do is to call your new functionality from the old code. You are not decreasing the quality of the existing code and you are doing your work with a good quality.

If you are more motivated you can separate some part of the old code as well every time when you are adding new functionality. That means you are not only separating your new code the a new class, but you are also separating some code from the class where you are calling your class. And at separation you can do some small corrections as well: better naming etc.

With this method sometimes you need to code a bit more, you need to think a bit more, but your code will be always just better and better instead of being worse and worse.

In my view dealing with code quality is something what is there during the project lifetime: from the very first design plan until the last bugfix.

Do you have different experiences?

See you next week!

RelaxedProgrammer