We often meet, communicate, and work together in our lives. Each has lived a different life, has a different style of communication, and has a different personality. These characteristics enrich our lives, create a good society, and create a company culture that respects diversity, but common rules are needed in projects that must move forward with a common goal. The common rule can be etiquette or culture when people communicate, and it can be code for developers. The coding style is a characteristic that each developer has, but sometimes the maintenance or code readability of large projects decreases, slowing down the progress.
Different styles of code every time while typing code relieves anxiety of obsession to have coding standards. The first impression of using eslint, one of the Java script coding standards, to write code, felt like a tool to keep code clean, but it was embarrassing to make many errors. Unexpected errors were not good to see when coding alone because errors do not occur well unless the function or logic is wrong. Over time, coding standards such as eslint changed my coding habits and brought some advantages. First, increased productivity has become more advantageous in producing, organizing, and maintaining a lot of code, thanks to readability that has become easier to read.
Regular indentation made the code look good and easier to locate errors while debugging. And if you’re in a joint project where you have to work with someone jointly sharing code in GitHub, you can make communication easier and make it easier for each other to understand. I think coding standards are very necessary in that they can reduce errors in projects involving a large number of people and see code written by others like the code I wrote and develop into consideration for each other.