DEV Community 👩‍💻👨‍💻

Discussion on: What is your advice on writing "clean code" ?

Collapse
darshitpp profile image
Darshit Patel

Simple rule: Try not to break the "Single Responsibility Principle" (SRP), and most things will fall into place

Collapse
peerreynders profile image
peerreynders • Edited on

SRP:

"Gather together those things that change for the same reason, and separate those things that change for different reasons ... a subsystem, module, class, or even a function, should not have more than one reason to change ... separating things that change for different reasons, is one of the keys to creating designs that have an independently deployable component structure."

Responsibilities and "one reason to change" are related but not equivalent.

"Single responsibility" is an oversimplification of cohesion.

Ultimately it's about discovering the boundaries where there is

  • high cohesion within the boundaries but
  • low coupling across the boundaries

something that is easier to recognize than it is to author (and it's the fundamental idea behind Bounded Contexts).

Gather together those things that change for the same reason is a good starting point (to avoid the shotgun surgery and divergent change code smells).

Kevlin Henney rant

Collapse
jeremyf profile image
Jeremy Friesen

The quote of "gather together..." has me realize how very much I love proverbs compared to "rules".

Collapse
jeremyf profile image
Jeremy Friesen

When I create a class in Ruby, if I'm at my best, I always try to start with the following comment before I write any code:

The purpose of this class is...

I have a high degree of confidence that that intention will persist regardless of the implementation details.

This then follows with methods, but by the time I've written out the class purpose, the methods are (in the moment) somewhat self-evident. (I still go back and document the methods)