Longer code vs shorter code

I have been on codewars and I am seeing solutions that are “shorter” than let’s say, doing a for loop. The solutions that are voted “best practice” are the ones that are a lot shorter. Let’s say that the longer solution, (for example finding the minimum number and maximum number in an array, then finding the difference between the maximum and the minimum), is using a for loop to get the solution. Is the fact that it is longer than doing the solution in one line takes longer to load?

Shorter is not automatically better. Simpler and clearer is better. Frequently, making code simpler will also make it shorter.

Code shortness does not have a direct relationship overall code runtime, as built in methods are usually using loops internally.

I honestly wouldn’t worry too much about what users of ‘coding challenge’ sites like Codewars or Leetcode think good code looks like.


Hello there,

Often, you will find Code Golf on platforms like Code Wars. It can be fun to try to solve a problem in the fewest bytes of code (text) as possible.

In production, this is discouraged, because it is often not readable, and can cause more headache than anything else.

On the other hand, which is more readable:

const arr = [1, 5, 2, 20];
let maxNum = 0;
for (let i = 0; i < arr.length; i++) {
  if (arr[i] > maxNum) {
    maxNum = arr[i]


const maxNum = arr.max();

EDIT: I actually do not think that is valid JavaScript, but you get the idea:

const maxNum = Math.max(arr);
1 Like

Shorter isn’t better. More readable is better, faster is better, less memory is better, shorter is just shorter.

I will say if you can avoid using for loops by using array methods that is in my opinion much preferable. And if there are built-in methods that can do the work, don’t reinvent the wheel and implement your own version.

Spread the arr

const arr = [1, 5, 2, 20];
console.log(Math.max(...arr)); // 20

Shorter code does not lead to better performance. What does lead to better/worse performance is usually the underlying algorithm. The study of what is fast/slow is considered to be the study of data structures and algorithms. Which are usually the “answers” to what most problems require.

For example, there are fast and slow ways to find the minimum and maximum number within an array.

The fastest has to be O(n), where n is just the number if inputs. The “Big-Oh” represents the worse-case.

A slower option would be to iterate over the array 2 times, one to get the largest, one to get the smallest and then do the rest of the calculations.
This would be O(2n) , so for each input of n it runs 2 times.

An even slower option would be to sort both arrays roughly: O(n log n) to get the highest/lowest number then do the rest of the calculations. Depending on the sorting algorithm used you could see even slower performance, to the point the worse sorting algorithms can take longer than the heat-death of the universe for larger inputs of n!

Computers are fast, but each of these approaches will take significantly different amounts of time to execute once the input gets large.

The final factor besides “runtime” is actually the human element. If code is short but complex and difficult to read, you as the developer might need to spend more time to understand it, or worse having to come back to fix a bug you created because you though a tricky but flawed approach was “cooler”. At the same time your boss and customer service reps had to spend hours dealing with the bug you created, and stockholders are now homeless because you screwed up, etc etc.

This is of course an extreme example, but is the practicalities that code is not just for machines to run fast, but also relates to the human elements.