A New Level Of Anal-Retentive
21 Sep 2017
What I First Thought About Programming
The first time I looked at a line of code was when I was nine or ten years old. I was trying to learn basic HTML (Hypertext Markup Language) and CSS (Cascading Style Sheets)—two of many programming languages used for web development. I was a very confused little kid trying to understand the meaning of each line of code; experimenting by deleting one line to see how it would affect the overall outcome of the design… and then reverting back to how the code used to be because the design of the page ended up broken somehow (hmmm… I wonder why..). I bring this memory up because despite the hours of looking at a screen and trying to learn by manipulating the code, I actually found it somewhat easy to read and understand each line of code and what it is trying to do because of how the code was structured. For example, in CSS, my “kiddy” mind understood that the brackets signified the start and end of a declaration block. And everything in between were declarations seperated by a semicolon. I would not have come to a realization if the code itself was not spaced and indented properly like the image above. It would have been way too much for my mind to process and prevented me from delving in much further.
Moving On To My First Programming Course
I took my first programming class at Leeward Community College (LCC) at Pearl City, Oahu. Before taking the class, I took a long hiatus in programming. The course I took was an ‘Introduction to Java’. As the semester went on, I thought my professor was very anal because of many reasons. For one, he wanted a certian number of spaces before each line. He also wanted documentation of the program at the top of each .java file a certain way. He wanted each line to be indented a specific number of ‘tabs.’ There were many requirements in the way I had to structure my code in order for me to get a good grade in my coding assignments and I thought to blame my professor because of how strict he was in very miniscule things. I remember he assigned an assignment that I had difficulty completing so I asked a classmate if I could look at his code to see how he did it. When I looked at his .java file, it was not very confusing but I had to do a little thinking because of the difference in details (i.e. spacing, indentation, naming conventions, etc.) that he had compared to mine. I did not realize till then the difficulty of reading others’ code if it does not match the structure that you are so used to.
Coding Standards
This is where coding standards take a role! Those little differences like two spaces for each line of code, or indenting one/two/three ‘tabs’, or naming each variable by using ‘Camel Casing’, or even being repetitive in the documentation of each method/class. All of these actually matter! It makes it better to understand, maintain, debug, and add to code when the code itself has a universal structure.
Conclusion
Being exposed to the coding standards of ESLint with IntelliJ was definitly a pain because of all the errors that would popup. For example, including a space where it was “not needed” or not using a declared variable or its value anywhere in the program. It was ‘Introduction to Java’ class all over again! It took me a while to get used to the different kinds of error messages of ESLint but in all, it really just helps to simplify my programs and make them more easy to look at. Coding standards are definitely a way-to-go when you are working on a program that will be maintained by other developers, when you want a smooth debugging process, or when you want to understand code better/faster, etc.