“Poorly crafted Code frays at the edge much faster than we might expect. “
There is not any specific checklist or harry potter’s stick to write and understand clean code. It’s a paradigm or thought process to design clean or self-explanatory code. But still, I would like to share a few points which I understood after studying, Clean Code(Book by Robert C. Martin).
In this book, Martin describes best practices and deconstructs poor practices, admonishing those who fail to recognize why and how those habits are bad. It also describes how and why to write good code.
How to implement clean code? well, first of all, we shouldn’t think in the direction of actual coding project or implementation rather we should be thinking as a designing and planning perspective. Many of us often rush into the code because of the tight deadline or get the job done quickly. In contrast, a clean coder makes sure the developer fully understand the problem before beginning to code. So that developers can avoid hiccups during development or post deployments.
Understand the scope of project/modules/sub-modules/classes/methods and blocks, try to design with specific need rather implementation multiple domains or functionalities within single entities. Many of us have a myth that because of all the time we spent on design, our code will be better right away and it can just be written in a straight forward manner. That isn’t the case, We should still stay regimented and carefully craft and test(i.e. TDD ) our code, even if we think our design and implementation are flawless.
Clean Code in a nutshell:-
· Code should be Elegant
We should implement code elegantly and refactor. So that anyone can understand the code by looking at it. The peer shouldn’t be lost while doing code review.
If we’ll not do so after some time it is hard to maintain or enhance that code. So its recommended, write small methods and small classes.
· Code Should be focused
Always we should write focused method or classes rather including multiple functionalities. Try to use SOLID principle if there is any scope in the project.
· Naming convention(i.e. Class, Methods, Variables, Data Members etc…) should be self-explanatory.
Project Name, Modules name, sub-modules name, classes name, methods name and variables name should be self-explanatory.
· Write Unit tests ( for code, functionality and DevOps ) with proper code coverage
We should adopt proper TDD approach and try to cover as much scenario as possible. By following, this approach we can minimize bad or smelly code and bugs.
· Follow the TDDs law:
- Don’t create code before you have a failing test.
- Don’t create more tests than necessary to fail.
- You cannot write more code than enough to pass the test that is failing.
· DRY (Don’t repeat yourself)
While implementing functionalities always we should think of ourselves or discuss within the team to understand the behaviour.
Ask two questions:-
· Can this be a shared or individual functionality?
· Is there any other module/class going to use in future?
· Proper boundaries and responsibilities definition
We should define proper boundaries of project, modules, classes and methods within the application. If we need to implement complex and composite component we can leverage inheritance or association based on the nature of requirement.
· Appropriate use of Architectural styles, Architectural patterns, Design principles, Design patterns and Data Structures.
“Don’t invent the wheel always”
sometimes we should use existing, mature or proven solutions. Considering the below factors we can prevent or avoid many knowns and unknowns in the production.
Analyse all the requirement or use-cases based on the following factors:-
· Scalability — with huge data volume, with huge request volume
· HA — (SLA nearly 99.9% )
· Performance — (with huge growing data volume, with huge growing request volume)
· Ease of implementation keeping future in mind.
· Proper Error and Exception handling
Error handling should be planned carefully by all programmers. When the wrong things occur, we have to get it to do the right things. We should give preference to launching an exception than treating it just to hide.
Our implementation should be self-explanatory so that we require less or no comments.
· Proper and Mature AOP implementation
Implementing proper AOP aims to increase modularity by allowing the separation of cross-cutting concerns.
Clean code is a paradigm, not a rule book. we can design our software the way we think, today’s effort can save future pain.