DEV Community

Cover image for Code Should Breathe
Michael Knepprath
Michael Knepprath

Posted on • Originally published at mknepprath.com

Code Should Breathe

Note: This is my opinion. If you have thoughts or concerns, that's fine - feel free to message me.

In programming, there can be an obsession with brevity, compactness and cleverness (i.e. magic). How much can I do in one line? How few lines can I have in my component? How much can I abbreviate my variable names? All of this leads to the code equivalent of hyperventilation.

What if we let our code breathe a little? "Breathing room" here is defined as extra lines and empty space within code. Here are a couple ways this can be accomplished.

Use Blank Lines To Create Sections

A List Apart had a great article about the use of whitespace in web design entitled simply, Whitespace. This piece refers to a concept called active whitespace, "whitespace added to a composition to better emphasize or structure, information." In code, use whitespace (blank lines) to clearly separate imports, methods, and so on. Here's an example from this website:

  // External
  import parse from "date-fns/parse";
  import Link from "next/link";
  import { withRouter } from "next/router";

  // Components
  import Page from "core/page";

  // Data
  import { posts } from "../posts.json";

  class Writing extends React.Component {
    ...

And, of course, there are examples of great whitespace usage in the official React docs. See the code examples in the Adding Lifecycle Methods to a Class section. From the A List Apart article, " [W]hitespace creates breathing room and balance. It’s important."

Lint Rules

If a lint rule exists that enforces adding more lines and space, implement it. One example: vue/html-closing-bracket-newline.

 <!-- Example A: -->
 <p
   id="foo"
   class="bar">
   baz
 </p>

 <!-- Example B: -->
 <p
   id="foo"
   class="bar"
 >
   baz
 </p>

Given the two options above, Example B allows for more breathing room. It's easier to understand at a glance. Multiply Example A by a dozen elements with varying numbers of attributes and it becomes increasingly difficult to see where attributes end and text/nested elements begin. I propose that when choosing between two lint rule options, always choose the one that adds more lines and space.

Close Blocks Clearly

While I do enjoy the simplicity of Pug, the template engine formerly known as Jade, I do believe some human processing speed is lost due to the lack of closing tags.

<!-- Example A (Pug) -->
.fancy-link
    a(href="/")
    | Home
.fancy-link
  a(href="/about")
    | About

<!-- Example B -->
<div class="fancy-link">
    <a href="/">
        Home
    </a>
</div>
<div class="fancy-link">
    <a href="/about">
        About
    </a>
</div>

While I love the brevity of Pug here, I personally think there's too much left to the imagination. Again, multiply Example A by a dozen different, nested elements and it becomes dense and difficult to parse.

Breathe!

On a fun website called Dwitter, contributors are challenged to see what they can create with 140 characters (or less) of JavaScript. While limiting characters can be a fun constraint, this isn't code I want to read on a day-to-day basis. Instead, let's luxuriate in the fact that we have room to breathe.

Top comments (0)