Reflecting on Coding Standards
24 Sep 2020Rules, rules, and more rules!
Why should we care about format??
In a previous course entitled Program Structure, we dived into the world of C and C++, an extremely dense and powerful language and it’s slightly diluted sibling. While by then most of us were accustomed to tedious rules such as syntax, semantics, the semi-colons, the brackets, naming conventions… the list goes on. We were not, however, prepared for the number of rules that went beyond this. Functions could not have return statements within code; indents had to be four spaces; brackets had to align vertically; every function needed a comment header; global variables were strongly discouraged… another list that goes on and on. At first the rules seemed pointless. Why are we so focused on how we format each line and file? Shouldn’t we be more concerned about the code’s accuracy? It was not until the midterm project that I realized how this particular structure was helpful. The project involved multiple files, each longer than the last. Instead of having to waste time finding a section, everything was readily labelled and aligned. I imagined reading a novel that had no chapter labels or aligned indents. There was also frequent behind the scenes collaboration. Real life work that involves coding is often a cooperative effort. Very rarely does a singular person handle all the coding elements, and because of this, producing files that are easy to read and edit increases efficiency and fosters effective teamwork. Putting in some extra effort at the beginning to properly format your work removes the pain of having to rummage through gibberish later.
The rules of language
As a person who speaks five natural languages, writing instructions in programming languages feels more rigid and far less fluid. English, for example, offers a wide range of expression, whereas Java is quite literally robotic and monotone. Aside from the fact that natural languages belong to the human race as programming languages belong to computers, natural languages include emotion and freedom--it’s not just about giving someone instruction. In professional settings, there are guidelines to maximize efficiency. Pieces such as research papers, lab reports, and dissertations all have a specific format that must be followed, and failure to do so can result in disqualification. Rules such as having to use a particular citation format or labelling electric schematics are there to prevent error and confusion, particularly for projects or work that involve numerous pieces and that need to be handled by multiple people. There are countless examples of why formats exist, but it all boils down to accident prevention and efficiency. Whether it be Spanish, English, Java, or C++, there is always going to be a general format that must be followed when demonstrating knowledge or providing a solution.
ICS 314 and its many rules
Now in terms of ESLint with IntelliJ, the coding standards involved are rather simple. Frankly speaking, the coding standards thus far have not been much of a concern because of the automated process. In the same way we rely on spellcheck to fix our writing, we can depend on ESLint to catch and fix the important and most apparent issues. While this course comes with stringent rules and regulations, there is a practical application and reason for each one. This does not mean we have to love the rules. In the same way many of us abhor MLA format for essays, we can also detest formatting code. But we can still appreciate the purpose and motivation behind wanting work to be less painful and tedious later.