Take a Step Back

Intro

Often while working on a piece of code, we do so from a point of perfect understanding. We have already familiarized ourselves with the current level of complexity. In this position we easily run into the danger of adding another tiny bit of complexity or inconsistency, without even realizing that the quality of our code base might finally tip over.

To avoid these problems we often have rules and shared ideas of what clean code should look like. This post describes an unconventional but effective hack to spot irregularities and code smells in a file.

The Hack

Luckily, there's a simple hack, which we can use when we finished a piece of code.

It works by using our ability to quickly recognize shapes. Something we, humans, are really efficient at for evolutionary reasons. At the same time, it helps us to detach ourselves from the knowledge we already have about the code.

So, here's the trick!

Take a step back. Zoom out.

Like, literally. Zoom out in your code editor until the font is illegible.

What does the structure of the code look like?

Things to look out for

After time you will develop an intuition of what proper code should look like in your project/programming language/company/treehouse.

However, here are a few examples that worked well for me:

Size

are the blocks of text all of an acceptable size? or is there a huge block that doesn't fit in with the other ones?

Maybe the method got too big over time, maybe we just added a few additional lines and it is finally the time to refactor it.

Very long methods are typically difficult to understand and to test.

If you encounter this shape, look closely if you could raise the level of abstraction in the method and extract a few smaller methods it could call instead.

Repeated Shapes

Are there any repeated patterns?

Visually repeated patterns often indicate blocks of code that can be extracted and reused.

In some cases it might be as simple as extracting a method. In other cases, a middleware or a wrapper might solve the issue.

Triangles

Are there any triangles or right-pointing arrows in your methods?

Deep nesting almost always violates the single level of abstraction principle.

I have yet to see OOP code that does a bunch of work on multiple nesting levels without violating this principle.

The only exception that comes to mind is processing and reshaping of data-objects.