Measuring simplicity in code
Tags: programming, javascript, planning, systemdesign
Published: 2021-01-23 16:04:11

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/09oo29oaky2huu3b2ixe.jpg)
<span>Photo by <a href="https://unsplash.com/@blakeconnally?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Blake Connally</a> on <a href="https://unsplash.com/s/photos/simple-code?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></span>

> These are my personal opinions and not intended as an expert view on things. Accept with a pinch of salt :)

Simple and child-like. Elegant. Beautiful. A work of art. These are the few adjectives we might have heard referring to a piece of code over the years. And most of the time these are coloured with personal biases one develops over the years.

I have some. So might you.

While biases in themselves are not wrong, but at times kind of fall short of objectively measuring the concept over which a bias is formed in the first place.

One metric I found to have worked for me over time is this: amount of code (number of files + logic + LOC) one must load into their brain to be able to understand and extend a functionality.

Talk is cheap, show me a contrived example!

{% codesandbox devto-demo-complex-no3ux view=split %}

Here, we have a form which 'syncs' it's state to some store. Same data is used to render a greeting.

Now in a regular application, you can add `redux` and few API calls in addition to the codesandbox demo and unknown to you, the developer, a Frankenstein's monster is born. And you, the developer with context is the proverbial Dr. Frankenstein in our story :)

Enter me, a new developer to your team. First task assigned is this:
"Add a share option to the Greeting component"

Looks harmless enough to be marked beginner friendly.

Now, for me to start work, even in the contrived example, I have to go through the following files only to understand how data is flowing:

1. `App.js`
2. `withFormContext.js`
3. `FormWrapper.js`
4. (Now circling back to `App.js`) `Form.js`
5. (And finally) `Greeting.js`

If somehow I did not follow the sequence and went from `App.js` to `Form.js` directly, I would have had to go back to `FormWrapper.js`, `withFormContext.js` and then some how land on `Greeting.js`

This gets the job done. It uses component state, higher order component and context to achieve dependency injection of state. Nothing wrong with this per se. Except for the level of indirection thrown around over time.

Now, look at the following example. Yes, it is contrived still, but please try to look beyond the obvious.
We used the plain old concept of "lift state up".

{% codesandbox devto-demo-simplified-o0f3i view=split %}

Now when I need to add sharing options to `Greeting` component, this is the set of components / files I need to go through:

1. `App.js`
2. `Greeting.js`

The indirection is gone and feature wise, both examples are similar. 

Please look into your own codebase and be on the lookout for sections of code that need extra documentation or takes new comers longer to onboard into.

Every time you add a new feature / code review, please try to check the amount of code / files you need to load into your runtime (brain) for you to be able to work with the feature. 

If it is more than you are able to remember by the time you reach into the depth of it, this could be a prime candidate for refactor.

---

Thank you for reading this far. Let me know what you feel in comments.