Be more CUPID, be less SOLID

Should we write code SOLID? I’ve always liked a bit of single responsibility principal and dependency injection, but don’t often find myself using interface segregation.

Dan North argues that the SOLID Principals are not the be all and end all of good software. On a recent .NET Rocks 1745 he explains what’s wrong with SOLID and puts forward his own set of CUPID Properties. Properties are less strict than principals, but if you write code that has more of these properties then it will be better.

Dan North seems to have plans to write a series of detailed blog posts about the CUPID properties, but it looks like he’s very busy at the moment and hasn’t got round to it. So, I’ve written this very quick blog post outlining them from his explanations in the podcast. They make sense to me. Their aim is to write simple code that is a joy to work with for you and others.

Composable – Create code that can be used with other code, and is easy to use with other code. This is easier if it is consistent, small and does not have too many dependencies.

Unix philosophy – Things should do one thing and do it well. This is similar to single responsibility principal, but it concentrates on what the code does, rather than the code.

Predictable – A consumer of your code can predict what your code does and it will behave the same every time.

Idiomatic – Code that conforms to the conventions of the ecosystem it is part of. You should play well in the project that you are part of. There are some global conventions in programming and any project or organisation builds up its own set of conventions.

Domain based – Things should be named and organised for the domain. The names used in the domain should be familiar to people who are experts in that domain.