Dynamically assemble and match players
Dynamically assemble and match players
Connect cross-platform accounts & identity management
Grow and commercialize your game
Build a vibrant community
Track player progression and game state across platforms
Track, engage, and retain players
Make informed decisions
Writer: Rahmat Kurniawan
Editor: Monic Andyani
What a software engineer does in a nutshell is that we create applications and/or products with a lot of features within. When our products are used by many clients, most of the time they would request several changes that are tailored to what they need. The changes could be in the form of a customization of the features that are already present or even a request to add new features. This can prove to be a challenge, especially when we have more than two clients, requesting different customization.
Our product consists of several applications, therefore every customization means another effort to move or tweak certain applications or features which we call context switching. In this case, every engineer is required to understand the code of all applications and/or projects. It seems impossible at first, however, the solution for it is one coding fundamental that's often overlooked, which is writing a clean code.
Take a look at the following code, is this code clear enough for you to understand?
There are several questions that might pop-up in your head as you read them. What does the pay function is purchasing? Whiskey Tango Foxtrot does const u and i mean? These questions require several scroll-up so we can understand the meaning — which is time-consuming. This will be frustrating if you are on the receiving end of the context switching. This means that by merely finishing your task faster is not worth the technical debt that will bother us in the future.
Luckily, AccelByte has implemented the habit of writing clean code from the start. This is one of the core cultural tenants for the engineering teams since implementing a clean-code approach will significantly improve our productivity as an engineer.
From the nightmarish example above, I have rewritten them into a better, cleaner, and much easier to understand code.
Now with this code, it is known that this function will work for paying in-game items, in which the function requires two parameters namely userId and itemId. For the function itself, we now understand that there is an instruction to make an order and to pay for the order. Now, this code is efficient, much more understandable and sparks joy.
We all know the fundamentals of a clean code — it should be easy to understand plus easy to modify or change. But why should you care? Well, your code is the prime representation of your programming skill and your train of thought — keep this in mind because your code will be read by other engineers in your team. Here are reasons why you should write a clean code:
There are two mantras that you need to internalize so that you will soon be able to write clean code with ease. They are the DRY mantra and KISS mantra — let me break them down on the following section:
We also need to keep our methods small, each method should never be more than 50 lines! One way to do this is by assigning one method to only solve one small problem instead of many use cases. When you realize you have a lot of conditions in the method, break them into smaller methods. This will make your code easier to read and maintain and also you can find bugs a lot faster.
Use Braces for all control structures (such as: if, else, for, etc). The first statement of a non-empty block must begin on its own line. Use the following link as a reference.
There's a braces condition that can be ignored
- Ternaries operation (source)
- ‘If' statement without ‘else' statement
B. Column limit
A line of code should be less than 80–120 characters to make it easier to read, but there are some conditions that can't follow this rule like long URL and specific commands.
D. Block Indentation
Breathe in, breathe out. Congratulations! Now we have reached the end of the page, keep in mind that writing a clean code will not only benefit yourself but also your team as a whole. A code is a representation of your skill and your train of thoughts — start writing cleaner from now, eventually, it will be a habit that will increase your productivity in the future.
Reach out to the AccelByte team to learn more.