The appearance of a source code is crucial when sharing a program to others, especially for collaborators who may work on it later. Otherwise, it will be difficult for them to follow through the functionality of your program, which will consequently waste precious time for most, if not everyone. To prevent such a tragedy from occurring, many programmers familiarized themselves with basic coding etiquette when writing source code.
Though a single absolute coding style does not exist, leaving it to one’s own interpretation, there are many factors of writing code that are common to nearly all existing styles. These include indentation, use of white space, and variable and function naming. During a week of coding sessions, I utilized a plug-in tool from the Java IDE IntelliJ IDEA called ESLint which tracks parts of a source that is not complying to its coding style rules, some of which are listed above. (See link below for all the rules). Though these rules are perceptive and strict, they show a visually pleasing layout as the outcome and provide me the conditioning they need to write it consistently. Furthermore, as IntelliJ is geared towards Java and JavaScript, the linter tool helped me, a novice JavaScript programmer, solidify my understanding towards the language’s basic syntax.
Link: Rules of ESLint
I can compare any linter tool to that of a grammar stickler, yet deep down I understand the good intentions that came with them. I admit the effort to remove every single underlined error to gain clearance from ESLint is tedious, especially since I mostly care about my code running correctly. It is even more irksome when errors appear at all when I had been writing code for many years through my own style. However, I must consider the idea that a coding style reflects that of the author. Any reader, whether they are a professional or a novice, should not be pitted against messy code, especially if the code is conceptually difficult to begin with. If such a thing happened by my own style, my reputation as a programmer will be tarnished in the long run, which will affect future collaboration with others.
As an upcoming Computer Engineer and Gave Developer, I need to consider the well-being of anyone reading or working on my code. It is understandable for someone to refer to me in order to clarify the complexity of my code, yet it can look foolish if I am referred for a messy coding style. With a linter tool, such as ESLint, I can track any part of the code the program tells me to change in order to arrive at a clean, readable file.