Callstack developers periodically dive into projects with other teams. If you have a project set up, all you need is to dive into coding and add new features. Wonderful, isn’t it? Nevertheless, sometimes it does not happen to be so enjoyable, and here is why.
First of all, developers read more code than they write. The project may look very nice from the user side, but the same still cannot be said about its codebase. Like a cross-stitch, you see an awesome front side, looking on the back you have no clue what it should be.
This article will provide you with a set of 12 (in total) rules and approaches, which will make your code as marvelous as the result you are getting from it. The rules are divided into three aspects of coding:
and I hope that they will occur helpful in your professional coding path as they were in mine.
Let's start our journey into a beautiful codebase! 🚀
This line does not take much effort to read, isn't it? Butwhatyoucansayaboutthatone?
Long names, deep statements, unclear structures are the developers’ nightmares. Seeing the code for the first time should not take much effort to be understandable. If it takes, it has a serious problem with readability and it should be fixed. Let's see how we can make our code more readable:
Stick to one code structure
Different developers prefer different structure patterns. First of all, decide which one works best for you and your team members. Having several variations of structure in the project will create misunderstandings. This rule should be applied not only to the code but also to the folder structure.
Separate code into blocks
It is easier to eat pizza piece by piece, rather than all at once. The same is with the code blocks - split them into smaller chunks, instead of having a large bundle.
Remember about naming
Code cannot tell its reviewer what you've had on your mind while creating it. Naming speaks for itself. Do not make people waste time looking for the context between lines and files. Simple and straightforward naming is the key.
Avoid deep nesting
The deeper you make the code - the harder it becomes to follow. Deep nesting makes you go back and forth to find missed pieces. It is a good exercise for your eyes, but a bad habit in coding.
Use tools to format the code
Thankfully, you don't need to format code manually. It takes you a few steps to get readable code - choose your favorite editor (we recommend using Prettier) and set up config. The tool will make formatting faster and easier.
Do you remember working on your project and coming back to it in a while with a 'What I was trying to do here’? Every developer had such a facepalm moment.
One of the main reasons for that is the problem with the code consistency and how we had grown in programming. The same can happen to the new project members if the team has not decided on the code structure and rules. You start researching and code debugging, which takes your development time. To avoid this, follow these rules:
Code should look like it was written by a single person
If you or your team do not have a style guide - create it, if you do - follow it. Simple as that.
The code will probably live longer in a project than you will work on it. Teams are constantly changing. Therefore, do not create challenges for future development, take care of codebase style, and follow the rules.
Don't Repeat Yourself (DRY)
The same piece of code should not be repeated - programming was not created for that.
Separate duplicated code into unique parts. The idea is to reuse things just by calling them, not copying and pasting all over and over again. Same as humanity nowadays, we are on the way to get rid of plastic bags in favor of reusable ones.
Check if new things fit the whole picture
Keep track of just added pieces. We know that the implementation of new functionalities to the existing environment can be difficult, but do not forget about making things not only work properly but also look suitably together.
You cannot assume that your code works perfectly without testing it. Tests make work undoubtedly easy. Testable code says that you are on the right way!
Each function should have a single purpose
Let's say you want to get all users from the database. And you want to thank them for being registered longer than a year by giving a new golden status. We do not have any queries for such a case, so we will implement it manually.
We mixed get and post in one method, which makes it significantly hard to test. To prevent such complexities, they should be separated:
Do not mutate
Mutation is the process of changing the original data. With mutation, you are updating an object, which is used in other places. As a consequence, you are left with an unpredictable code. If you will cut an apple in pieces, you would not be able to put it back together, it won't be the same anymore. The process with data mutation goes similarly. To escape it - use unique values for separate tasks.
Avoid side effects
I assume that everybody knows what are side effects. In coding, for example, side effects are methods, which return different output for single input or whose output depends on the global state. They make code complex and harder to test. You can isolate them from the rest of the code to prevent misleading.
Follow the Test-Driven Development (TDD) approach
What your implementation process looks like - you start with code writing, do some tests on it, and update tests till the light is green. But what if the problem is not with the test, but with the code itself?
Test-Driven Development (TDD) is the development workflow, which goes in another order:
- Start with simple code
- Write a test on this small piece
- Make test fail
- Refactor the code
- Make test pass
By following this approach, you can obtain all possible cases on how your code works. That would be a lie saying that I am using TDD in daily work, but I am a big fan of those who do. Nevertheless, you should try it to feel the difference. And who knows, maybe this process will be much suitable for you!
Considering all the rules might be a challenge, but they can become your new good habits. We love to make things simpler, do the same with the code. Humans also read our code, not only computers!
Speaking of which, you can always ask a more experienced developer to review your code - it's good to have an expert take a look at your work. A professional code review is much more than just a bug check.