![\"code](\"https:\/\/www.audero.it\/blog\/wp-content\/uploads\/2016\/08\/code-readability.jpg\")
<\/p>\nA\u00a0few days ago I found an online test\u00a0featuring six exercises on JavaScript. For fun, wishing to challenge myself with something tricky, I decided to take it.\u00a0The test proved to be very simple, so it isn’t worth a discussion. It’s what happened next that inspired this article.<\/p>\n
I was talking with a workmate about the test and he decided to take it despite my warning about its simplicity. We compared the solutions we wrote for two of the six exercises and we found out that they were quite different: his solutions were terse\u00a0and clever, mine were long and\u00a0extremely simple in their approach to the problem. These differences have generated an interesting discussion that touched several topics: readability, complexity, performance, and maintainability.<\/p>\n
Starting from the analysis of the two exercises we compared and the solutions we wrote, in this article I’ll share my thoughts about the power of simplicity in code.
\n<\/p>\n
<\/p>\n
But before starting the discussion, I want to describe the exercises and the solutions we came up with.<\/p>\n
The first exercise is well-known as\u00a0the “fizz buzz” test<\/a>.\u00a0This test\u00a0is proposed\u00a0in many interviews, regardless of the programming language(s) relevant to the position, and it’s usually given\u00a0at an early stage of the interview process due to its simplicity. Nonetheless, many have found that a large number of developers can’t solve the “fizz buzz” test<\/a>\u00a0or even write code at all in the attempt to solve it.<\/p>\n The “fizz buzz” test is presented below:<\/p>\n Write a program that prints the numbers from 1 to 100. But for multiples of three print “fizz” instead of the number, and for the multiples of five print “buzz”. For numbers which are multiples of both three and five print “fizzbuzz”.<\/p><\/blockquote>\n To keep the discussion focused, I will only report the core The code I wrote for this exercise is reported below:<\/p>\n The other solution for the “fizz buzz” test is the following:<\/p>\n The second exercise was slightly more complex than the “fizz buzz” test but still simple in its nature. The text of the exercise is the following:<\/p>\n Create a So, if the call to the function is<\/p>\n the string returned is<\/p>\n “You gave me 4 arguments and they are “hello”, “world”, “fizz” and “buzz”.”<\/p><\/blockquote>\n The code that\u00a0I wrote to solve this exercise is the following:<\/p>\n The solution developed by my workmate for this exercise is shown below:<\/p>\n As mentioned in the introduction, the two exercises are simple and their solution doesn’t require more than a few lines of code. Nonetheless, the solutions presented in this post are really different in complexity and the approach used. I’ll start their comparison by discussing how readable the code of the two solutions is.<\/p>\n My solution for the “fizz buzz” test is longer and more verbose than necessary but it gains in readability. I dare anyone having a basic knowledge of programming to not understand what the code does. But what I mean exactly with readability<\/em>? Code readability doesn’t have a real definition, so every developer might explain it in a slightly different way. My definition of code readability is:<\/p>\n A code is readable<\/em> if it can be understood by anyone with a basic knowledge of the programming language in use with a single read.<\/p><\/blockquote>\n With In my definition I also mention Let’s now take a closer look at my solution for the first exercise to see how it relates with such definition.<\/p>\n My For example, the following is more readable than<\/p>\n While for most developers this change won’t make any real difference, it can have a big impact on a junior developer.<\/p>\n But how my function compares with the other one? The latter features the use of a couple of interesting techniques worth a mention.<\/p>\n The first technique relies on how Boolean expressions are evaluated in JavaScript. When a Boolean expression is evaluated in JavaScript, the rightmost value processed is returned. So, in the expression The second interesting technique employed is the use of the Both these techniques are nice and communicate something good about the author of the code. However, this cleverness comes with a price. The price is the nontrivial cognitive effort that a less experienced developer has to put in order to be able to understand the code. Even worse, the reader of the code might not be able to understand the code at all, turning the snippet into a magic box that he or she will avoid at all costs.<\/p>\n Before moving to the next topic, I want to show you the shortest solution for the “fizz buzz” test:<\/p>\n As you can see, the above With this question in mind, let’s discuss about code simplicity.<\/p>\n I’ve been coding for a while now and an important lesson I’ve learned in my career is:<\/p>\n If there is a simpler solution to a problem, implement it.<\/p><\/blockquote>\n This approach is not new and many others have come to this conclusion way before me. The above quote is nothing but a paraphrase of the KISS principle<\/a> with which you may be familiar with.<\/p>\n Once completed a feature, many developers tend to refactor their code to improve it. However, many of them strive for the wrong goal. Instead of refactoring to improve code readability and to implement a simpler solution, many developers focus on shortening their code, often by employing clever techniques or relying on obscure language features. A good example of this habit can be spot by looking at the second solution for the “fizz buzz” test.<\/p>\n When refactoring we should always strive for code simplicity. This involves reducing the cognitive effort required to understand a code. The solutions proposed to solve the second exercise offer a great starting point to analyze this aspect. This time, instead of focusing my attention on the specific lines of code written, I want to focus on the approach adopted.<\/p>\n My solution consists of a single function, while the other is split in three. Generally speaking, I’m all for splitting a problem into multiple, smaller problems, solve them, and then combine the solutions to solve the original problem. However, experience has taught me that going too far with this approach can be harmful.<\/p>\n Jumping from a function to another to grasp the aim of a code causes a lot of context switching in a developer’s brain. Too much context switching can lead to focus loss. It can also cause the loss of the original reason that firstly led to the code investigation. How many times have you started exploring a snippet of code to fix a bug and have found yourself few minutes later wondering what was your original goal? How many times have you felt that you’ve gone so many levels deep into the code that you lost track of what you were doing? I bet a lot. In these cases, it can be beneficial to combine two or more functions together to avoid too many jumps.<\/p>\n In conclusion, if you reach a point where a problem has become fairly simple, don’t split it into subproblems. The context switching required by those reading the code might cause them a lot of frustration. Be sure you don’t violate the single responsibility principle<\/a> by combining unrelated functions, but avoid creating trivial functions.<\/p>\n There is yet another benefit that code simplicity can bring to the table. Let’s examine it.<\/p>\n Readability is a crucial factor when writing code, but there is another important aspect developers should be concerned about: performance. Many think that a shorter, clever code always leads to better performance. In several cases this assumption is false, in others cases the improvement in performance is irrelevant (more on this in a moment), and only in few cases it really matters. As Kyle Simpson<\/a> has pointed out in several occasions, ECMAScript engines become better and better every month, and their ability to optimize code is constantly improving. So, there are cases where a developer can write terse and cryptic code that takes advantage of optimization techniques that lead to better performance compared to other solutions. But this gain will eventually vanish in a future release of the engines. Therefore, all that’s left is obscure code that nobody wants to read or change.<\/p>\n As an example of a clever code that doesn’t lead to a faster execution, let’s take into account the solutions for the “fizz buzz” test. My solution is more verbose and adopts a simple approach, but it’s also incredibly faster than the other. The actual difference increases with the amount of times the performance test is run. The other solution is 4x to more than 50x slower<\/strong> than mine. If you want to test the difference by yourself, have a look at the JSBin I’ve set up<\/a>.<\/p>\nfizzBuzz()<\/code> functions my workmate and I developed. Both of them accept a number as its only argument and return the result expected by the test.<\/p>\nMy solution<\/h3>\n
\r\nfunction fizzBuzz(n) {\r\n var isDivisibleBy3 = n % 3 === 0;\r\n var isDivisibleBy5 = n % 5 === 0;\r\n\r\n if (!isDivisibleBy3 && !isDivisibleBy5) {\r\n return n;\r\n }\r\n\r\n var str = '';\r\n\r\n if (isDivisibleBy3) {\r\n str += 'fizz';\r\n }\r\n\r\n if (isDivisibleBy5) {\r\n str += 'buzz';\r\n }\r\n\r\n return str;\r\n}\r\n<\/pre>\nOther solution<\/h3>\n
\r\nfunction fizzBuzz(n) {\r\n return [\r\n !(n % 3) && 'fizz',\r\n !(n % 3) && 'buzz'\r\n ]\r\n .filter(Boolean)\r\n .join('') || n;\r\n}\r\n<\/pre>\nExercise 2: string formatting<\/h2>\n
strFormat()<\/code> format function that accepts a variable number of arguments in input. The function behaves as follows:<\/p>\n\n
_ARGUMENT_<\/code> is the value of the argument provided<\/li>\n_ARGUMENTS-LENGTH_<\/code> is the number of arguments provided, and _ARGUMENT-1_<\/code>, _ARGUMENT-2_<\/code>, and _ARGUMENT-N_<\/code> their relevant values.<\/li>\n<\/ul>\nstrFormat(\"hello\", \"world\", \"fizz\", \"buzz\")<\/code><\/p>\nMy solution<\/h3>\n
\r\nfunction strFormat(...args) {\r\n if (args.length === 0) {\r\n return "You didn't give me any arguments.";\r\n }\r\n\r\n if (args.length === 1) {\r\n return `You gave me 1 argument and it is "${args[0]}"`;\r\n }\r\n\r\n var formattedArguments = args\r\n .map(argument => `"${argument}"`)\r\n .join(', ')\r\n .replace(\/(.*), (.*)$\/, '$1 and $2');\r\n\r\n return `You gave me ${args.length} arguments ` +\r\n `and they are ${formattedArguments}.`;\r\n}\r\n<\/pre>\nOther solution<\/h3>\n
\r\nfunction generateSentence(args) {\r\n let n = args.length;\r\n let sentences = [\r\n 'You didn\\'t give me any arguments.',\r\n 'You gave me 1 argument and it is {lastArg}',\r\n `You gave me ${n} arguments and they are {args} and {lastArg}`\r\n ];\r\n let sentence = n > 1 ? sentences[2] : sentences[n];\r\n\r\n return sentence;\r\n}\r\n\r\nfunction templateSentence(sentence, list) {\r\n return sentence\r\n .replace('{args}', list.slice(0, -1).join(', '))\r\n .replace('{lastArg}', list.slice(-1));\r\n}\r\n\r\nfunction strFormat(...args) {\r\n let list = args.map(arg => `"${arg}"`);\r\n\r\n return templateSentence(generateSentence(list), list);\r\n}\r\n<\/pre>\nThe power of simplicity in code<\/h2>\n
Code readability<\/h3>\n
basic knowledge of the programming language in use<\/q> I mean that the person reading the code must understand essential statements like
if...else<\/code> and for<\/code>. This means that if a person that doesn’t meet this condition is not able to understand the code under examination, the problem is not the code.<\/p>\nwith a single read<\/q>. If a developer has to read a code multiple times to understand what it does, the code can be improved. The less experienced is the developer that is reading the code, the better. If a piece of code can be understood by anyone in the team, the code won’t turn into a magic box that nobody touches for the fear of breaking it.<\/p>\n
![\"code](\"https:\/\/www.audero.it\/blog\/wp-content\/uploads\/2016\/08\/code-simplicity.png\")
<\/p>\nfizzBuzz()<\/code> function is made of basic language statements (if<\/code> and return<\/code>) and operations (modulo<\/code> and assignments<\/code>). In addition, the use of variable names (such as isDivisibleBy3<\/code>) makes the code even easier to read.<\/p>\nif<\/code> statement<\/p>\n\r\nif (isDivisibleBy3) {\r\n str += 'fizz';\r\n}\r\n<\/pre>\n\r\nif (n % 3 === 0) {\r\n str += 'fizz';\r\n}\r\n<\/pre>\n!(n % 3) && 'fizz'<\/code> if n<\/code> is divisible by 3, the right operand (the 'fizz'<\/code> string) is evaluated and returned. This means that if n<\/code> is divisible by 3, the result of the expression !(n % 3) && 'fizz'<\/code> is 'fizz'<\/code>. If you’re new to JavaScript this result might come as a surprise because in most languages the result of a Boolean expression is always a Boolean.<\/p>\nBoolean<\/code> constructor with the filter()<\/code> function<\/a>. Line 6 (.filter(Boolean)<\/code>) shows that the Boolean<\/code> constructor is passed as the first argument to filter()<\/code>. This is a method to filter all the falsy<\/em> values<\/a> from the array returned by the function.<\/p>\n\r\nfunction fizzBuzz(n) {\r\n return (n % 3 ? '' : 'fizz') + (n % 5 ? '' : 'buzz') || n;\r\n}\r\n<\/pre>\nfizzBuzz()<\/code> function is made of a single statement. While this is a short and simple solution to the problem, what do you think of its readability?<\/p>\nCode simplicity<\/h3>\n
![\"PHP](\"https:\/\/www.audero.it\/blog\/wp-content\/uploads\/2016\/08\/php-street-fighter.jpg\")
<\/p>\nA note on performance<\/h3>\n