Keep the Code Clean

“A programmer who writes clean code is an artist who can take a blank screen through a series of transformations until it is an elegantly coded system.”

Last month, I started reading a book “Clean Code by Robert C. Martin”. Started at snail’s pace, I dedicated just thirty minutes daily; focusing on learning something from this book. Now, I have just finished and I wonder to share the awesome feedback I have for it. I have so many things to share but let me cut long story short.

The author explains bad vs good code in an ideal way. He urges upon writing clean code all the time by quoting "Later equals never". He suggests that one ought to keep things more cleaned than one found (The Boy Scout Rule). He encourages employees to have an attitude for not making mess in code bending to will of managers who don’t understand.

“Books on art don’t promise to make you an artist”. We should not bemoan over something we did and were not fully successful. Rather we should keep doing better. The author says that having meaningful names of variables, functions and classes is extremely important. “Say what you mean. Mean what you say” is how he explains it.

When he writes about functions, he explains it like a melodious song. We should focus on functions such that they have are so small, do only one thing which they are meant to, and should obey rules (SRP, OCP, and DRY). I personally like them all but DRY (Don’t Repeat Yourself) is one the important rules I applied while I was working on my project. Coming on “Comments”, the author asks to wordsmith your code so it speaks. Don’t use comments to explain bad code.

Formatting your code well makes it readable. Write code so others can understand. Try and take the ownership to make it elegant. He makes use of quote, “You can take the boy away from the metal, but you can’t take the metal out of the boy!” explaining the mentality behind different sort of alignment of code (Vertical/Horizontal).

Objects and Data structures can never be excluded when talking about Clean Code. So does the author, he explains data abstraction, hiding structures, and DTOs in well manner. We know that without error handling, we cannot write clean code. We look into techniques finishing the things smoothly in case of failure. The author urges upon use of try/catch rather than traditional if/else structure to handle errors.

For any code you write, you must set its boundaries. If using some third party code, try to create wrapper in your code to keep things away from mess. Yet the author also urges upon creating clean boundaries.  For testing our code, we should write unit tests which must be clean themselves. Further, class is major element of OOP. Similar to functions, classes must be small and should obey rules. He urges immensely on keep functions close for modification while keeping class open for enhancement. Classes must be organized in such a way that they keep separation of concerns.

Not everything we write is supposed to have perfectly fine architecture, big things take time to accomplish well. That’s how author explains building huge systems. Start with small things, increase gradually and complete gracefully. Emergence is as aspect which can cause us writing bad code. We must try to keep things calm and clean. There are so many myths regarding concurrency, the author explains how we must deal with multi-threaded systems more carefully. Keeping thread-safe functions away from thread functions and figuring out the way to write unit test for it.

Successive refinement is the only way if you have to deal with bad code and make it clean. So many times, you will be dealing with others’ code. In those scenarios, rather than speculative start, understand code well. Stop if you need more time to make things clean but incrementally refine the code. In the final chapters, I like the notion of making code work first, then make it right. At times, we have constraints. In such times, we must make system work first then make it right. An excellent start along with pleasing end explaining the summary is quite mesmerizing. Finishing things like this always puts up great impression. So does the author. He puts an end to this book categorizing major parts like comments, environment, functions etc. and main points of each of them one should always keep in mind. The core of which is keep code clean all the times and removing all dangling information.

If you care for code you write; this is the book worth reading :)

Ville Henriksson

Software Developer at Arado

1 年

Now I know that I can refer to this book at work ??

No doubt, That is a grate article. I like your precis. I have a question, as you mentioned "making code work first, then make it right" first we make our code work but in practical projects we almost never got time to think and implement well designed code as you mentioned "Later equals never". So most of the time we have to deliver this junk code and this orphan code finds its position in production. Do you have any thoughts about it.

Mudassar Ali

Technology & Education

4 年

Keep learning it's not an end, without mentor, books are just books, look, read and create code out of code. ??

M Shafay A.

Lead Data Engineer @ Orion S.A | Dual Data Scientist

4 年

Gg

要查看或添加评论,请登录

社区洞察

其他会员也浏览了