Some quick guidelines to Clean Code

I recently read Clean Code by Robert C. Martin, and here is a very summarized compilation of tips/principles that I understoo or found useful.


Names should convey correct meaning. (descriptive and correct)
Names should be pronounceable.
Names should be searchable.


Functions should be small, < 10 lines.
Functions should do one thing and do it well.
A function that takes 2 parameter is good. A function that takes 1 is better. A function that takes 0 is best.
Avoid flag arguments (i.e. Boolean values), it shows that a function does >1 thing.
Functions should not have side effects (i.e. do things other than stated in its name).


Avoid comments if possible, your code should be explanatory.
Good comments: explaining intent, clarification of obscure parts, amplification of seemingly unimportant parts, TODO, warnings.
Bad comments: redundant, misleading, journal.


Small files are easier to understand than big files.
Newspaper metaphor: Headline -> Quick summary/Gist -> Details.
Use blank lines to separate different concepts.
Code that is related should be close together e.g. variable declarations in a loop.
Use white space between words to emphasize relation.
There are no laws for indentation, just set rules within the team and stick to them.

Objects and Data Structures

Objects hide data behind abstractions and expose functions that operate on the data.
Data Structures are containers for data and have no meaningful functions.
Avoid train wrecks (i.e. someThing().anotherThing().lastThing().orIsIt()).


Use exceptions instead of return codes, this enables separation of error checking and function logic.
Write try-catch statements first (in line with TDD).
Write Unit Tests.
Three laws of TDD:
1 – You may not write production code until you have written a failin test.
2 – You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
3 – You may not write more production code than is sufficient to pass the currently failing test.
Tests, like your production code, should be clean.
Single concept per test.


Classes should be small, just like functions.
Single Responsibility Principle (SRP), a class or module should have one, and only one, reason to change.
Classes should be open for change.

Good Designs (Rules by Kent Beck)

1 – Runs all the test
2 – Contains no duplication
3 – Expresses the intent of the programmer
4 – Minimizes the number of classs and methods

Successive Refinement


Quickview for YouTube

-UPDATE- My first user review on Chrome Web Store 😀

5-stars yay!

5-stars yay!

I released Quickview for Youtube on the Chrome Web Store last right, it was a really exciting 30 mins.

Beads of sweat trickling down my faces as I waited in anticipation for the zip file complete uploading, cursor hovering above the “Pubish now” button, as if I need to click it before it disappears suddenly. “Completed.” Within a split second I pressed my mouse left button as hard as I could and then it was live, on the Chrome Web Store. I would get millions of users and everyone would love what I did. But first let me see if it works. Bam. Reality strikes hard. I uploaded a wrong version. “Take it down, take it down” I told myself as I maneuvered what seemed like a labyrinth of links to finally reach the console where I could remove it. No way I was going to ship something that broken. Within minutes, things have turned out well.

Perhaps things weren’t that dramatic but it really was a unnerving experience publishing my first Chrome extension. But that night I did so, friends told me they are using it, liked it, and shared it with their friends. So I’m very happy they found it useful.

From a technical perspective, this extension is definitely not difficult. I had to learn bits about DOM, constantly refer to the jQuery API, check out Web Platform and the MDN; and I’m really glad there are so many great resources for anyone interested. I recently read a book called Clean Code by Robert C. Martin, and I wanted to apply some principles I learned, such as proper meaningful naming, and simple do one thing functions. It is not as DRY as I like it to be, so there’s lots of room for improvement.  While building Quickview, I had moments where I needed to decide which was the better way to do things. Here I learned something about trade-offs, such as clever-looking code v.s. maintainability.

I have a long way to go, but Quickview is definitely a small step, and hopefully in the right direction.

PS. Quickview is open-source.