Mention Ninja Code - Who are they that make many people "fearful"?


The Issue

In your opinion, what factors make a piece of code good? Concise code, easy to understand, thorough comments, standard syntax, adherence to code style, readability, easy maintenance... There are countless criteria for defining "good" code, and ironically, achieving all of them at once is a challenging, if not impossible, task.

For instance, you can shorten the code to make it look neater, but it might complicate future maintenance because concise syntax often sacrifices code transparency. You can provide detailed comments, but it may confuse readers, as excessive comments can clutter information.

For me, "good" code is something that's hard to quantify. It depends on the specific case, and the code being written must meet one of the criteria mentioned above.

I've heard about various methods to improve coding skills and make code "good," such as following "best practices," using standardized variable names, creating "pure functions," minimizing side-effects... All of these have been applied during my coding journey. However, not all of them can be applied anywhere, anytime. It depends on the real-world situation. For example, if there's a feature that needs to be implemented quickly with a tight deadline, you can't afford to be meticulous, and some sacrifices may be necessary.

Today, I stumbled upon an article titled "Ninja Code." At first, I didn't understand whether the author was praising or criticizing those who follow the "Ninja" style. I got curious and decided to delve deeper into this concept.

"Like Ninjas, their code is perfectly concealed," is one of the comments when talking about Ninja Code. This phrase implies that those who follow the Ninja style write code that only they can understand.

So, let's take a look at what "Ninja Code" typically involves. After reading this article, you can decide whether you agree with them or not.

Ninjas Who Prefer "Conciseness"

Making code as short as possible showcases your intelligence. Yes, if you can express complex logic within a certain code limit, it undoubtedly demonstrates advanced thinking. But hold on for a moment and try to imagine the reader's emotions afterward. It's like they're trying to decipher your thoughts instead of figuring out what they should do. This process takes time in proportion to complexity, and sometimes, if the intention is unclear, it might lead to a complete rewrite. Yes, I mean that we spend too much time just trying to understand such code.

Take a look at this code snippet below. Do you know what it's doing?

i = i ? i < 0 ? Math.max(0, len + i) : i : 0;

It will probably take some time to figure out what i equals to. Combining the "concise" style with short variable names like i can confuse many because it's hard to understand what this code does.

Short, meaningless variable names like i, j, n, etc., are also part of the Ninja style. If possible, limit the use of such names and opt for more meaningful ones.

Sometimes, you may come across shortened names like: list → lst, userAgent → ua, user → u. It might not be a problem for experienced programmers, or at least those who have encountered them before. However, what happens when someone unfamiliar with these shortcuts encounters them? They will likely spend time trying to decipher this style from the very Ninjas who introduced it. Worse yet, if they find this writing style "neat" and time-saving, they might decide to follow suit... and boom! More Ninjas appear.

Naming variables in programming can sometimes be a "barrier" for many programmers. Not everyone thinks the same way, has the same vocabulary, or sees naming variables as a "time-consuming" task for similar things. However, in reality, variable names play an important role in readability. A clear and specific variable name helps readers understand what data it holds, making it easier to observe data flow within the program.

Ninjas Who Prefer "Abstraction"

This manifests when they try to abstract everything in the code. For example, they use variable names like obj, data, value, item, elem...

Ninjas find it challenging to name variables, so anytime they need to declare an object, they immediately choose data or a similar object name like obj. At first glance, this variable name implies that it contains "data," but with such an abstract name, it may somewhat affect readers trying to understand the code later.

What's worse is when data, obj, etc., have been used, and they need to add another object. What do they do? It's simple; they add a number after the variable name: data1, data2...

To overcome this abstract style of a Ninja, you can spend some time thinking about naming variables. Associate them with the context within the code or give them a name that at least hints at what they "contain." For example, use listMessages to represent a list of Messages or messageObj to indicate a Message object.

Synonyms

Using synonyms for similar features is not uncommon; it may arise from multiple developers collaborating, each with their own definitions to create functions according to their thinking. But if you, as a single developer, create countless functions like this, then you are undoubtedly a Ninja.

For example, consider the prefixes before each function name. If a feature displays a message on the screen as a tooltip or notification and starts with display, for example, displayMessage. Then, another function, instead of displaying a message, displays a user's name but starts with show, showName... then we have both display and show performing the same task, which seems to complicate things.

Over time, you might forget the prefixes from earlier times, and new names like render, paint,... get added, causing others to question, "What are you trying to do?" when they revisit the code.

In summary, for equivalent functions, use a shared prefix. The clearer the prefix, the better; at the very least, it indicates what's about to happen and avoids confusion.

Side-effects Everywhere

Side-effects are present in functions that change content outside of themselves. Side-effect functions can sometimes make reading and maintaining code difficult. If you're unsure about this concept, the article Pure Function in JavaScript. Why should we know this as soon as possible? is for you.

Make sure that a function returns a consistent value and doesn't cause side-effects. It would be surprising if a function with names like isAdmin, checkPermission,... changes any external data. No one wants to guess what changes outside of a function after it's been run.

To address this, create pure functions instead. Completely eliminating side-effects in a modern application is impossible, so organize functions accordingly. Determine which should and should not have side-effects, as well as limit unexpected functionalities, as shown below.

"Beyond Expectation" Features

Ninja Code often tends to create functions that go beyond what you'd expect.

For example, a function with the name validateEmail(email) instead of checking the email format might also include displaying error messages (alerts) and requesting the user to re-enter the email!?

What happens if someone only wants to check the email format, and when they see your validateEmail function, they try it out and quickly realize it's "beyond their expectations," forcing them to create a new function.

To overcome this, focus on the function's intended purpose. If the function's name only implies email format checking, let it perform just that. If you want to do more, create another function with a broader purpose than checking the format.

Conclusion

"Ninja Code" is a term that refers to programmers who write code that's not very readable or understandable. They often write code in their own unique way, making it time-consuming for those who come later to understand what they're trying to accomplish. Honestly, I've been and still am a Ninja in some unavoidable cases. The shadow of a Ninja is always lurking, but sometimes, it's better for others to see you!