-
When you are coding you are doing two things
- Telling the machine to do a certain task for you
- Telling others who might look at your code that this is what you are intending to do
- We always focus on the 1st, not 2nd. IMO the point 2 is far more important than 1
-
Don't make your code complier friendly, make it human-friendly.
-
Everyone should be able to read your code like they are reading simple English.
-
Your code can be self-documented or you can add more documents in the form of comments and guides but more importantly, the code should tell a story. The reader should know where to start, how the move forward and where it ends.
-
Don't let ppl or compiler assume things, make it explicit.
-
If things aren't explicit then write comments. Let ppl know what you are doing and why you are doing that. We are all smart ppl, we don't do anything without a valid reason so tell ppl that reason.
-
Own the code, the piece of code you write represent your team, your product, most importantly it represents you.
-
Attention to details, writing docs, naming things meaningfully, writing test cases all these should come as second nature. You should do it because you'd want to not because someone told you to do so
-
Show empathy towards others who might look at your code.
-
A perfect analogy is "consider others who might look at your code as your guests"
-
You'd want them to feel welcome, you'd want them to get comfortable and not feel lost. The same applies here. You don't want your code reviewers or someone who might look at your code feel lost. Give them directions. Let the code be the guiding force.
-
Typescript is awesome only if you use it properly. Don't try to fight the compiler instead think that the compiler is there to help you out.
-
Don't make fixes to get around the compiler. Whenever it throws an error/warning, try to read and understand why it is happening then you don't need to do any hack.
-
You don't need a separate document if your code with comments and test cases are good enough
-
Learn if you don't know something, don't be intimidated. Fear of not knowing something is common for everyone. So you are not alone.
-
Thrive to write better/clean code. Your code should be an example for others to follow. If a new member joins the team then we should be able to point them to any of our PRs to understand how we write features and tests.
-
We don't need guidelines. Guidelines are difficult to remember and maintain.
- Test for all corner cases you can think of
- Do not just write test cases only for happy cases.
- Test the component for all the state change and user interactions
- Think like tests are your users.
- 99 % of the time you'll figure out edge cases and failure cases only when you are writing tests and assigning type definitions
- You should feel confident about changing any piece of code. Tests are your safety net, you don't want to jump into refactoring with that.