Keeping Your Code Simple | Tiffany R. White Blog

Keeping Your Code Simple

Reading time: 3 mins

One of the biggest lessons I am trying to learn as a mid-level dev is keeping my code simple.

I was working on a few algorithms for a bootcamp I planned to attend1.

I tweeted this algorithm I was stuck on a couple weeks ago:

Clean two-liner. Nice, right?

Let’s take a look below:

function longestString(strs) {
  // is x string length greater than y string length? If so
  // return x
  // if not return y
  // add an empty string as an accumulator
  // as a callback to the reduce function
  const longest = strs.reduce((x, y) => x.length >= y.length ? x : y, '' );
  return longest;
}

Here I am trying to get the longest string in an array. I thought I could accomplish this easily with a functional array method so I searched around. I read the MDN for map, filter and reduce to jog my memory, and then settled on reduce.

Someone on StackOverflow had a similar algorithm they were trying to solve. I adapted my algorithm based on that.

As the Twitter embed shows I had a bit of trouble with the comparison as my test wasn’t passing. I added the appropriate operator and all was well.

This is as clean as it gets.

But is it readable?

Mentors Are Great

A friend of mine and mentor DM’d me on Twitter about this and the solutions people offered me on Twitter. He said that one solution was a mess and that if he had written anything like that he would have gotten chewed out by his boss.

My immediate response was to chuckle at the guy who gave me the nested ternary.

But he wasn’t talking about that. He was talking about my clever two liner. Well…

A Lesson in Dumb Code

My friend and I talked at length about cleverness and writing code for other humans to read. The variables I use in the two line solution don’t have any context. Instead, I should have broken them out into something like this:

let lenX = str1.length;
let lenY = str2.length;

const longest = strs.reduce((str1, str2) => lenX >= lenY ? str1 : str2, '');

This is still terse but more readable and easier to understand.

I could have used a traditional for loop but wanted to look in the know and get in easily2. I wanted to look clever and smart and in the process made the code unreadable, the hallmark of a mid-level dev.

Keep It Simple, Stupid

When I was a newbie dev, I never understood why anyone would write a variable declaration like x or y. I disliked functional programming methods like reduce for that reason: most examples I found used these variables. I never understood what x was referencing. As someone who better understands the language I have fallen into that clever mid-level trap. Don’t do it. While yes, it makes you look as if you know what you’re doing, it also makes the code unreadable and you start to look less and less appealing as a potential dev candidate for X company.

As a friend of mine used to say:

Keep it simple, stupid.

  1. You should definitely not apply or attend. 

  2. I could have gotten in regardless. Their practices are predatory. Especially for POC and other marginalized groups. 


Share

No Ads. No Sponsored Content. Ever.

I've decided that I no longer want to have sponsored posts on this blog. I also, though as tempting as it may sound, don't want ads; even if I got big enough for Carbon ads I don't want them. I want to post free, engaging content for beginning/junior devs. This means that I won't have Setapp posts or affiliates on this blog, though I will keep them on the Uses page. If you enjoy the content, buy me a coffee. Just click the button below.


Coffee Buy me a coffeeBuy me a coffee


Webmentions 0

No webmentions were found.

Newsletter