Brevity vs. Comprehensibility

We love using SCSS here at Made, and the way in which we use it is constantly evolving. However, one particular and admittedly quite clever feature of SCSS has bugged me from day one, which is referencing a parent selector inside the current one:

.foo {
  .bar & {
    // your styles
  }
}

SCSS is a beautiful thing and, I think, makes CSS a lot more readable and nicer to look at, especially when working to a style guide, or when a linter is part of your build process. The example above, however, I find horrible to read and I mentally trip over it every time I see it or need to use it, despite being completely aware of what it represents. All that feature does is say:

“Whenever .foo appears inside .bar, apply these styles.”

I like to read up on SCSS mixins and functions other developers have shared with the community, and I found a great alternative to the default parent selector method, a mixin that describes what that method does:

@mixin when-inside($context) {
  #{$context} & {
    @content; 
  }
}

This can then be called within your SCSS like so:

.foo {
  @include when-inside('.bar') {
    // your styles 
  }
}

The biggest argument against doing this, which was pointed out to me not long after introducing this mixin to a project a few of us were working on, is that it’s quite a few more characters to write (an additional 22), plus we’ve had to create a mixin to accommodate it.

The trade off is that the method is much more descriptive, only slightly more verbose, and doesn’t require so much esoteric knowledge of SCSS to understand (although if there was a way I could drop the ‘@include’, I would).

An unwritten rule of development seems to be that the fewer characters you use to write a piece of code, the better, and to an extent that makes sense. If you were to look at a controller in a Rails application and find methods over a hundred lines long, you could spend hours picking through it in an effort to comprehend it, and even longer refactoring it into something that doesn’t make people balk when they see it, so we as developers strive to write code that is both concise and efficient.

Sticking to that unwritten rule encourages cleaner code (the DRY principle, shorter methods with descriptive names, less extraneous white space, single quotes instead of double quotes), and can give you a real desire to find the most ingenious way to achieve the desired outcome a given language will allow.

Having said that, we, the humans reading and writing the code, still need to be able to easily understand what we’re looking at, and I think sometimes there’s a temptation to sacrifice comprehensibility for brevity, to abbreviate or otherwise encrypt code as much as the language will allow without considering how well it’ll read to other developers.

For me, being able to read code written in plain English is far more preferable than spending time trying to decipher arbitrarily obfuscated code.

About the Author