Clean Code Notes

“Needs will change, therefore code will change.”

“To restate the former points for emphasis: We want our systems to be composed of many small classes, not a few large ones. Each small class encapsulates a single responsibility, has a single reason to change, and collaborates with a few others to achieve the
desired system behaviors”

“Single responsibility principle is also tends for functions”

“However, a system with many small classes has no more moving parts than a system with a few large classes. There is just as much to learn in the system with a few large classes. So the question is: Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?
Every sizable system will contain a large amount of logic and complexity. The primary goal in managing such complexity is to
organize it so that a developer knows where to look to find things and need only understand the directly affected complexity at any
given time.”

“The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that.”

“Tests preserve and enhance the flexibility, maintainability, and reusability of the production code.”

“Use of minimum assert statements per test”

“By clarity we mean clarity, simplicity and density of expression”

“So if your tests are dirty, then your ability to change your code is hampered, and you begin to lose the ability to improve the structure of that code. The dirtier your tests, the dirtier your code becomes. Eventually you lose the tests, and your code rots.”

“No matter how flexible your architecture is, no matter how nicely partitioned your design, without tests you will be reluctant to make changes because of the fear that you will introduce undetected bugs. But with tests that fear virtually disappears. The higher your test coverage, the less your fear. You can make changes with near impunity to code that has a less than stellar architecture and a tangled and opaque design. Indeed, you can improve
that architecture and design without fear!”

“Object should hide its internal logic”

“Function should only do what it’s name says and has no side effects i.e : — checkPassword function should only checks password not intialise the session for the user”

“Use factory to hide conditionals with polymorphism”

“Class name should be of noun and it’s function names should be verb”

“Use polymorphism over conditionals”

“Fuction should consist of less arguments maximum 3”