Labs

By John Ennew | 26th October 2012

The Principle of Code Kindness and Drupal

At Deeson we coined a best practice term called 'The Principle of Code Kindness'. This comes from a line in the Clean Coder (our developers' professional codebook) which states:

Always check in code cleaner than when you checked it out. Always make some random act of kindness to the code when you see it.

Robert C. Martin calls this 'the Boy Scout Rule' and in Xtreme Programming (XP) this is given then more forceful title of merciless refactoring. Whatever you call it, the Principle of Code Kindness is a best practice philosophy where developers get into the mindset of fixing problems when they see them.

The problems sometimes aren't even very large, just noticing a repeated line of code and refactoring that out. Each small change makes the code more readable and more understandable. Over time this slowly, and inevitably, leads towards more compartmentalised and modular code instead of an attack of the spaghetti monster (may you be touched by his noodly appendage).

This means that there is significantly less fear and doubt when it comes to making a bigger change. It is clearer what each part of the system does and we are less afraid of altering things.

In Drupal, if you inherit a site where config isn't in code, don't wait to be told, get on and add the Features module. If you see some custom code you know could be replaced with a good contrib module, or there is a core function alternative replace it!

This approach is great news for clients who hear less sucking in of breath and furrowed brows when their next feature request comes in. It's also great for devs and agencies who can confidently welcome change, give estimates and know with confidence what alterations in the system will do.

Comments

John Ennew's picture
John Ennew
John Ennew

This is an example of the principle, not a module development standard. We use Features as a standard best practice tool by default for straightforward Views and Entities led site features when site building to allow for config management in code, change control and code re-use across sites. I guess there are probably use cases where it may not be appropriate but that's very situation dependant. As site builders, in the main, Features has the thumbs up from us.

chx
chx

Slow down. Adding features is not a 'best practice'. Using ctools bulk export to get things into code for modules that support it, sure. More than that, definitely wait until told.

Add new comment