Read on Twitter
Writing clean code is the line between a system that lasts decades over one that persists a few years.
It's the difference between a junior dev and a senior engineer; it's a scalable organization that pivots without chaos.
Here's my 10 main take-aways to writing Clean Code
It's the difference between a junior dev and a senior engineer; it's a scalable organization that pivots without chaos.
Here's my 10 main take-aways to writing Clean Code
1) Making your code readable is as important as making it executable
The clearer the code, the less time others will have to spend understanding it. Be nice to the other devs who will be reading your code in the future.
The clearer the code, the less time others will have to spend understanding it. Be nice to the other devs who will be reading your code in the future.
2) Later equals never
We've all been that person that says they'll delete it later and never do. Don't leave scraps of useless code that no longer serve a purpose and often confuse others.
We've all been that person that says they'll delete it later and never do. Don't leave scraps of useless code that no longer serve a purpose and often confuse others.
3) Functions should be small
The smaller the function, the more specific its responsibility, the more descriptive the name, the easier to understand what it does.
0 arguments is best, then 1, then 2. Avoid 3.
The smaller the function, the more specific its responsibility, the more descriptive the name, the easier to understand what it does.
0 arguments is best, then 1, then 2. Avoid 3.
4) Duplication is the evil of all code
Duplication represents additional work, additional risk, and additional unnecessary complexity. Keep your code DRY.
Duplication represents additional work, additional risk, and additional unnecessary complexity. Keep your code DRY.
5) The only good comment is the one you found a way not to write
Usually comments are crutches or excuses for poor code or justifications for insufficient decisions. When unmaintained, they often lie to other devs. Replace comments with good naming conventions and tests.
Usually comments are crutches or excuses for poor code or justifications for insufficient decisions. When unmaintained, they often lie to other devs. Replace comments with good naming conventions and tests.
6) An object exposes behavior but not data
Not everyone should see you naked. An object should not expose its internal structure through accessors because to do so is to expose its internal structure to bugs and privacy issues.
Not everyone should see you naked. An object should not expose its internal structure through accessors because to do so is to expose its internal structure to bugs and privacy issues.
7) Testing
Keeping tests clean is so important because without them, you lose the very thing that keeps your production code flexible, maintainable, and reusable. Tests should follow the FIRST principles.
https://medium.com/@tasdikrahman/f-i-r-s-t-principles-of-testing-1a497acda8d6 @tasdikrahman
Keeping tests clean is so important because without them, you lose the very thing that keeps your production code flexible, maintainable, and reusable. Tests should follow the FIRST principles.
https://medium.com/@tasdikrahman/f-i-r-s-t-principles-of-testing-1a497acda8d6 @tasdikrahman
8) Error handling
Each exception that you throw should provide enough context to determine the source and location of the error; only the stack trace can't tell you the intent of the operation that failed. Nice error handling saves hours of debugging later.
Each exception that you throw should provide enough context to determine the source and location of the error; only the stack trace can't tell you the intent of the operation that failed. Nice error handling saves hours of debugging later.
9) Classes
Classes should be small, but rather than counting lines, we should count responsibilities. Each class has a single reason to exist and collaborates with a few others to achieve the desired system behaviors.
Classes should be small, but rather than counting lines, we should count responsibilities. Each class has a single reason to exist and collaborates with a few others to achieve the desired system behaviors.
10) Format
Short lines are preferred to long ones
Blank lines show differentiation of concepts
Local variables should appear at the top of the function
Instance variables should appear on the top of the class
Short lines are preferred to long ones
Blank lines show differentiation of concepts
Local variables should appear at the top of the function
Instance variables should appear on the top of the class
If you're interested in learning more about how this translates into your coding habits: https://dev.to/_juliettech/how-to-write-clean-code-3lhl
