Is your code a bit flabby?

Flabby code doesn’t bode well for anyone. In the short term, everything seems fine. We tell ourselves tiny little white lies that we’ll sort it all out later — but we never do.

We get sidetracked, sidelined, or switched over to a new project completely. Then we come back to our code and wonder about our life choices at the time.

But what, exactly is, flabby code?

Flabby code is the bloat that we code into our work through patterns and architectural decisions. Sometimes we take shortcuts. Sometimes we ignore our bad habits and tendencies until they compound enough to be a major problem. Sometimes we just do things we shouldn’t be doing because we don’t know any better.

So how do you fix flabby code? How do you train away the flabby pooch that bumps up your final kilobyte size that turns your app from a heavy and cumbersome thing to a lightweight superspeedy beauty?

Going on a code diet

Flabbiness often occurs when you’ve let yourself go in certain areas of your code. There’s more to it than just clean your code up. Sure, you can lint your code to make it shorter and better formatted, but there are some things that linting can’t help you with.

Here are some things you can do to help reduce the flab.

create logical names

Naming things is not exactly rocket science, but many of us still get it wrong. We write long-winded names that end up either being too generic or too specific. Either that, or we write things that are so cryptic that three months down the line, we’re convinced that we’re staring at some Egyptian hieroglyphics.

Code is the bridge between humans and machines, it is the language we use to communicate and do things with the hardware and intermediary compilers and engines. This means that we need to understand it as well.

Write your function and class names for humans, not as a bunch of acronyms. It only takes one developer and missing documentation to lose all the information associated with it.

reduce, reuse, recycle

Compact components, functions, and classes generally follow the single functionality rule. The more functionality and features you have, the harder it is to turn your code into a lego set.

Because, as developers, that’s what we do — we create modular code in order for it to be reused again the future for whatever purpose. We reduce our bloat by reducing the components down to the bare necessities and recycling the bigger ones down to the better-suited size.

be flexible like bamboo

Often times, we get over too zealous and overengineer our code. This often creates the issue of long term rigidity, locking you into a structure that may not suit the trajectory you’re actually going down.

Sometimes, we try to be over flexible that our code turns into a floppy gloop that can’t hold its own weight over time.

Whatever is happening, finding the right balance akin to scaffolding your app’s architecture with bamboo — a cheap material that can hold immense weight and pressure — over steel frames, which can be harder to modify if plans suddenly change.

To do this, you need to only scope for the current sprint and refactor the architecture as needed in the next iteration. If the foreseeable future is trustworthy and will certainly happen, you can extend the scope of the scaffold and architecture as needed.

It’s better to have a working app than one that’s built to withstand hurricanes and tornadoes. Code will change over time and the revelations and understanding that comes with it will help you create better code in the long run.

code to the project vibe

There are conventions and suggestions galore on the Internet. Everyone has their own opinions on how projects should be structured, named and coded.

Don’t follow them blindly.

Use your judgment wisely and create against the project vibe. You know the trajectory of your project better than someone on the Internet telling you what you should be doing.

There are somethings that you should take into consideration — like what to do to write clean code, plugins to use, and how to structure things — but you and your team need to balance it out with what the actual project needs.

So code to the project’s vibe — not what the Internet tells you to do.

Final thoughts

Code pooch is something that can be slimmed down over time, but it takes good processes and long term commitment for it to take effect.

Some people call it a technical debt, except techincal debt is more symptomatic of a bigger problem. Code bloat is a feature of technical debt but it’s not the only one.

Code bloat happens when we overthink our code for what it is. We might be aware of clean, lean and mean ways to code but sometimes we get over excited and end up trying to implement everything all at once.

Save it for your next project.

Figure out what you need and code to the conditions. Don’t over code your project, slim your number of lines down by limiting your features and functionality inside a particular block or set of code.

Once you get into the habit of doing that, you’re on your way to having code that’s truly lightweight for its conditions.

**************

footnotes:

Check out my blog - dottedsquirrel.com - the space where all my code tutorials and thoughts live.