CRAP Software

May 12, 2020

Today I learned about C.R.A.P. design. Seriously, go Google C.R.A.P. design and have a read. It’s good stuff. I’m really surprised that I hadn’t heard of it before.

Although, I view it a little differently. I view it in the terms of source code. Which, in my opinion, is design. The way we structure and align things has a huge impact on its readability.

So, number one is Contrast. If you start to look at contrast, you may see a few meaningful things jump out at you. Things like group things that are the same together, or make things that are different stand out. If you’ve ever tried to find something in a log file, you know what I mean. It all looks the same and makes finding things extremely difficult. Same goes for a sea of if statements. When there is one thing buried in the middle of that, it’s really hard to find. This is just one of many reasons to reduce if statements.

Improving contrast can have big impact.

Number two is Repetition. This just screams do the same thing. Few things are worse than a codebase where everyone does their own thing. Different file naming conventions and different coding styles will almost always lead to a confusing codebase.

I usually try to follow the lead of the developers before me, or have a conversation about coding style and what’s preferred.

Number three is Alignment. Speaking of alignment, I have to admit that I was never a big fan of aligning equal signs and such, but I’ve started to come around. It really does help guide the eye to what sort of data structure it is, as long as it’s not too far apart.

This is nice and readable.

{
  "one"   = 1,
  "two"   = 2,
  "three" = 3
  "four"  = 4
}

This is not.

{
  "A-super-long-word-and-stuff"   = 1,
  "two"                           = 2,
  "three"                         = 3
  "four"                          = 4
}

Alignment also reminds me of the shape of code. Check out the Squint Test

And finally Proximity. I’ve just started to think about this as I structure code.

There are a couple of approaches when writing functions. Some developers add them to the top of the file or the bottom of the file as they come. They figure their editor will help them find what they need. There is also the camp that feels that alphabetizing is the best approach. While I like this in theory, it becomes difficult to navigate.

I’ve recently adopted the proximity approach. If I have a function that calls some other functions, I’ll order them near to where they are called to help when navigating around. With a large project, there can be a lot of jumping around. If you can try to keep the code you need together on one screen, you can reduce the complexity a lot.

I hadn’t considered graphic design principles in my code writing, but I will now.

More stuff:

or go see everything in the archive.