Our team is about to start on production, and it wasn’t a bad idea to start to learn how to write code that doesn’t suck. Our code is horrible, most of the time, but that’s okay, because now we know why its bad and how we can fix it.
A medium article by Christiaan Verwijs goes over why our code is bad, its simple, its code smells. In essence it talks about bad practices in code that can lead to long time problems. It outlines some common problems that we will be addressing in our code base.
First we will make sure that our code will not have a God Class, or a class that does everything. It should be separated up into chucks and have a specific purpose in mid. Next we are going to make classes suck less by making sure that we clear out all of the nested statements and make it clean with added functions.
However to make sure we can fix code smells we make sure to to really analyze our code to make sure that classes are serving their purposes, code is sorted into functions and that we need to prepared for the fact most code smells start from the begging of the project rather from the end of it.
Another article by Codacy goes over how to make your code more clean. Some practices that my team are going to be encouraged to use include making sure that numbers are constants, follow pre determined naming conventions to make sure that the function is clear in it purpose along with coding conventions that insure only enough information is given in comments to prevent clutter.
In short we are going to try and make our code readable so that in the short amount of time we have on our project it is going to be as clean and as manageable as possible so that we don’t have to worry about technical debt in a project that will be only roughly 9 months of total work from start to finish.
Sources:
https://medium.com/the-liberators/on-technical-debt-and-code-smells-ae8de66f0f8b