Code Modularity

Where is the problem?

In the world of programming, developers often start writing code according to "regulations" or informal code-writing rules. They leave comments, write down what each function does, and usually what is the purpose of the whole script. But as the project moves forward, in order to achieve the goals and solve the task as soon as possible, instead of long-term time savings, we often opt for short-term success. The written script very quickly turns from beautiful code into something that everyone avoids, and finding bugs in that messy pile becomes a big challenge.

Dry?

Just like everything else, the technique of writing modular code also got an acronym, DRY, meaning "don't repeat yourself". This means that code written once to solve a problem should never be written again. But in reality, we often take the easy way out (temporarily) by copying and slightly modifying the same code for a similar problem. It also has its acronym, WET, which stands for “write everything twice” or “we enjoy typing”, or the most accurate description of such code, “waste everyone's time”.

What is code modularity?

In short, code modularity is a technique of writing code that can be very easily taken out of one project and implemented into another project with little or no code modifications. Some will recognize it as an ordinary library, and they are right. That's exactly what a library is, modular code. Code that does not depend on other code or is loosely coupled to other code. Although it is possible to download a library and use it, on large-scale projects, the code again gets tangled after a while and this slows down the whole project. Thus, the technique of writing modular code becomes a very appealing idea. Although it requires more thinking and technical knowledge, it significantly speeds up further development, as well as code debugging when a problem arises.

Project evolution

A project usually starts with one person or a small team working on a prototype project.

As the prototype grows and begins to take shape, so do the number of lines of code and people working on the project.

Soon, another team appears to take care of another large part of the project or it is a completely different project.

And this is where the modularity of the code has the biggest impact - the code that the first team wrote, the second team can just take and simply implement into their project and use it. A simple example is Bootstrap in the web world where millions of developers just download bootstrap and use a few tags to design buttons and page layouts, saving hours and hours of work.

Example

One of my hobbies is game development. The vast majority of games have some sort of health system. Even if we've never played a game, we've all probably come across some kind of implementation at some point in our lives, such as 3 attempts to throw a ball at a carnival where the goal is to knock down all cups with 3 balls. For a long time, I used the technique of copying the code and modifying it to work for the current project, and without much thought, I continued working on other parts of the game. As the project grew, various things started to use some form of "health bar" and suddenly I had 5 implementations of health, and by modifying one implementation you usually modify others as well, which leads to a lot of opportunities for error. I decided to create my library for implementing health in games, for the Unity engine only.

The health bar is completely separate and doesn't care about the rest of the code and the game. The health bar has it's own bar that shows the % of your health and has various animation options. The game does not know what is happening in the library and the library does not know what is happening in the game. The library only requires to be initialized with the maximum value.

After that, anytime in the game when the health value changes, it is enough to call the function with the new health value.

Conclusion

Although I spent more time creating a library than on simple health implementations, every time I need to implement a health system in the game, I can simply download my library and use the entire system with two functions. If I discover a problem with the health display or animation, I know exactly where the problem is. It is either in the call of the above two functions or somewhere in the library, and there is no need to search the entire code.