A Bit of Clean Code
As a junior high schooler who was really into computers, I’ve had always wondered how things work behind these big websites. And then I figured out that certain browsers have these features that reveal a website’s ‘source code’, or at least what I thought was a source code. Take a look at this piece of HTML ‘source code’ of Google.
Jeez, what are those? I mean, who in their right minds would name their classes by “gb_Fa” or even “gbqfb”? I used to think that this is how these professional coders do it: jumbling up non-sense that somehow is good enough to be interpreted by our computers, because computers are the ones who are supposed to understand them, and not us humans? Right?
Thankfully I learned that those confusing disarrayed lines aren’t how they really do it. Those codes have passed what is called as obfuscation, where basically companies deliberately transforming completely readable and tidy source codes into ones that are difficult for humans to understand, for security and privacy intentions.
So, how do they really write their codes?
The Clean Code
Robert C. Martin wrote a really good 434 pages book regarding this topic; I’ll try my best summarizing what I’ve got, and have used in some of my PPL course work as examples. If you want to see a full summary of the book, take a look at this cheat sheet.
Follow Standard Conventions — Language & Team Related.
Learning Python as my first programming language got me to dislike using semicolons to end expressions. After trying out some front end development, I discovered that javascript doesn’t require you to use semicolons at all, except for cases that will trigger the ASI: a set of rules that will determine whether or not a semicolon will be interpreted in certain spots. This is a good example of a very opinionated subject, which is why I find it important to declare and follow team guidelines while working with a group of people.
Below is a piece of code from my PPL course work, which shows correct Javascript variables, functions, and classes naming convention.
Don’t Repeat Yourself
Probably the easiest one to understand. Every time you have to write the same series of code twice, you are repeating yourself. This does not mean that you can’t write a single line of code twice, but rather abstracting the duplication in its logic.
Below is a basic example of my PPL course work. Instead of calling two separate functions for a POST request and a PUT request to endpoints, use a flag (isCreate) instead.
Boy scout rule — Leave the camp cleaner than you found it.
Sounds easier to say than to do. Cleaning up someone else’s work could take ages to do, as one must manage to not change the functionalities while doing so. Refactor whenever it makes sense to spend time doing so. Usually, teams take the approach of pending all value-adding work for some period of time and use the time to clean up the codebase. But for the most part, the boy scout rule applies to much smaller changes, which can be noticed and fixed quickly with the help of linters. Linters are tools that can help analyze source codes and reveal unnoticed errors, such as stylistic errors, improper conventions, and many more.
Linter that I use for my PPL course is ESLint, which is a VSCode extension to help me notice errors made by me or by my group mates, and quickly resolve all the errors in a single click of a button. A very handy tool and a must-have for all javascript developers.
Three things that I’ve mentioned above are only some of the general rules stated in Robert’s book. There are plenty more subject-specific rules that I couldn’t possibly mention all of them in this article. So consider reading the book by yourself!
That is all for this article. Thanks for reading!
Written as an assignment for my software engineering project individual review.
