🎨 Patterns for Practical Elegance
Engineering Resilience, Not Just Readability
By Nigel Dsouza
📘 Preface
Thi...
For further actions, you may consider blocking this person and/or reporting abuse
I’d strongly recommend revisiting and rewriting this article — here are a few points that might help improve its quality:
Code formatting: It looks like ESLint isn’t being used. The code examples are difficult to read — objects should be split across multiple lines to improve clarity and structure.
Point 2 — terminology and logic: While I agree with the title, I can’t say the same for the content. Throwing exceptions in a validate function is perfectly acceptable and widely used (see Zod for reference). Also, naming a function saveToDB makes sense if you have entity-specific save methods. A normal example is needed.
Missing Node.js example: It’s unclear why Node.js isn’t included in point 3. Adding it would improve consistency and relevance.
Code style and syntax: The code lacks proper linting and indentation, which makes it hard to follow. It would be much more readable if broken into multiple lines. Also, consider using async/await—it’s generally cleaner and more intuitive than chaining .then and .catch.
This article is completely repeated: refactoring.guru/refactoring/what-... , not by example, but content.
Hi Dmitrii,
Thank you so much for the thoughtful feedback and peer reviewing the article, I really appreciated how specific and constructive it was. I’ve taken your points seriously and completely rewrote the article. The code is now properly formatted with multi-line object literals, async/await is used instead of chaining, and I added the missing Node.js example for DRY logic. I also refined the validation logic and renamed vague functions like saveToDB() to make everything clearer. The updated version is called Clean Code Reimagined, would love for you to check it out when you get a chance. Thanks again, your feedback helped make it better.
cleancodecookbook.com/
There's already a clean code cookbook on O'Reilly
Hi Maxi, totally valid point. I’ve since updated the piece and renamed it to Clean Code Reimagined to make it stand apart from O’Reilly’s book. I’ve also added new metaphors, unique formatting, and practical code examples in both Node.js and Java to give it a fresh angle. Appreciate the callout, it pushed me to rethink and improve the whole thing. Thanks.
thanks to you!
Clean code by Robert C Martin is an evergreen book with a lot of good practical examples in case you are interested!
Helpful insight!
Thanks for such a useful article. Keep up the good work!
It is good practice to document code so that it is readable and understandable to others and must become a habit but maybe due to time constraints this practice is lost along the way.
Insightful!!
""Because clean code isn't just for you — it's for everyone who comes after you."" I found this the core of the issue and kudos to you for highlighting it.
Coming from the Y2K generation, which was also hugely limited in character capacity amongst others, this rings a clear bell. Code has to live on after its creator and be clear to those who come after.
A little more time and effort in code writing but a quantum jump in code utility going forward. Well said!!
Loved this! Nigel takes us through practical rules that make messy code neat and safe—using everyday examples like good names for things, keeping each job focused, and making errors easy to handle. It’s like cooking: pick fresh ingredients (clear names), follow easy steps (small functions), and spice it just right (useful logs). Even someone not deep in programming can see the sense: cleaner code means fewer surprises and less stress later. It’s not just for coders—it’s about building solid foundations that anyone coming after you will appreciate.
Thanks Nigel. Rather than just listing best practices, you encourage a shift in mindset that’s vital for every developer. The way you transform common anti-patterns into clean, maintainable code is both appreciative and powerful. From meaningful naming and focused functions to data-driven logic, each example strikes a perfect balance between clarity and real-world application. But best is your culinary metaphor, “prep your variables, follow a clean recipe, and taste before you ship,” It captures the heart of every coder brilliantly.
Absolutely agree that clean code is a practice....an ethic....a way of programming life!!
It needs to be in place early in life, else it may never happen!
Great use of examples to illustrate the point!!
Definately worth reading. Thanks for sharing 👍
Appropriciate your work . 👏👏👍
Interesting reading.
It’s been a log time since I did any coding.
Great read!
Very well written Nigel, Brilliant. Thank you for sharing.
Another approach I have been following lately is to not be very DRY. I only abstract things if it makes logical sense or if it's being repeated more than twice.