Readable code or less lines

JavaScript
1

What do you think is the better practice while coding?

-Make a readable piece of code
-Write less lines of code

Same challenge, same solution but with those differences.

SPOILER
I’m posting a solution of longest word challenge

// Short solution
function findLongestWordLength(str) {
  return Math.max(...str.split(' ').map(x => x.length));
}

console.log(findLongestWordLength("The quick brown fox jumped over the lazy dog")); // Logs 6


// More readable solution
function findLongestWordLength(str) {
  let convertToArray = str.split(' ');
  let lengthOfEachWord = convertToArray.map(word => word.length);
  let longestWord = Math.max(...lengthOfEachWord);
  return longestWord;
}

console.log(findLongestWordLength("The quick brown fox jumped over the lazy dog")); // Logs 6
2

LoC isn’t a good metric: less code is generally better but I say that only if you are doing less stuff. The less the code does the easier it is to debug and the less chance there of things breaking. More lines of code can make it easier for mistakes to be introduced.

What you have here is quite basic, and it’s the same code in both versions. The first version I think is better, as there is no need for it to be split, but the two are exactly equivalent, and others may prefer the second. I don’t think it makes much difference in this case, use whatever you feel is clearer.

There are reasons for splitting the chained version up, but they would normally be because you want to run some check in-between. As an example, what if it wasn’t guaranteed to be just a single space character between words? In that case, maybe you split the splitting of the strong out into another function. And so on. Or you want to make it more efficient (maybe you want to run this millions of times!). Your code at the minute is going to allocate intermediate arrays three times and cycle through them afaics, whereas maybe you just want to go through the string once. That will take quite a few more lines of code, but will be much faster (just to emphasise that doing this kind of thing could be pointless, it depends on usage and context).

1 Like
3

thanks for the reply. I’m new to this and sometimes I dont know why I try to solve the challenges like the first one. And then I realized what if I have to go back and check that code. Maybe it would be more difficult to read.

1 Like
4

It’s good to think about now, it’s a good question! It comes with experience I guess:

  1. terse is good if the code is simple…
  2. …but try to do as few things at once – you need to keep how it works in your head while you’re writing it, and code can get complicated real fast.
  3. If it does do anything complicated, might be time to split things down
  4. If you are getting confused, definitely definitely split it out
  5. Don’t try to be clever, write dumb code

Basically, aim to write it so that when you look back at it in a week or a month or a year’s time, you can still understand it straightaway

2 Likes
9

Readability is subjective. It depends on how good your JavaScript is and whether the code is written in your preferred style.

In this case though, the longer solution is not any simpler than the shorter one. It uses the same methods. It just creates three unnecessary temporary variables. The variable names don’t add anything here because they simply tell us what the JavaScript methods do. Variable names should describe the value which they hold. For example, convertToArray should really be called words, or wordList, or wordArray.

In general, shorter code is better, and you should use as few variables as possible (Ockham’s Razor - don’t needlessly multiply entities). However, if you do need a variable, it should be clearly named and you should avoid abbreviations.

It’s also good coding practice to encapsulate difficult code inside clearly named functions. Once the function is written, you can ignore the implementation details and just use it. This approach will make your code more readable as it grows in complexity.

2 Likes
10

Excellent points above, but I’ll just include one obvious one:

Code comments.

Regardless of how terse or readable you think your code is, if there is even a remote chance that you or someone else on your team might have trouble understanding what you wrote 6 months from now, add comments.

1 Like
11

Creating readable code is key, but you must do it with the minimal amount of code necessary.