I believe in a quote, attributed to Brian Kernigan that goes like:
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
In languages like javascript, there is a minifier anyway (and a transpiler most probably) in front of our code and the production code that gets served in the browser (unless of course your write code for the server-side).
To be fair, the above is not the worst example of "smart" code that I have seen and the article is a nice explanation of why this works so thanks for that!
To me, more terse code is almost always easier to parse. Of course, everyone's different. There's not really a one size fits all solution. You'll have to agree with your team on a working standard.
I've already expressed mine opinion here around, and to be technically precise the code is easily testable as any if construct.
Thanks for sharing your opinion!
I do find the article helpful but to be honest with you, it was the first time I saw something like this.
I guess someone that is more experienced with the spread operator and augmenting objects in this way might have seen it more than me.
As you said, it is most probably a matter of opinion as a lot of things in javascript are those days, for example, I find something like this pretty hard to read:
let adder = (x) => (y, z) => x + y + z;
compared to the old-style alternative but there are people who love it.
So thank you again for going deep in your explanation :)
I believe in a quote, attributed to Brian Kernigan that goes like:
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
In languages like javascript, there is a minifier anyway (and a transpiler most probably) in front of our code and the production code that gets served in the browser (unless of course your write code for the server-side).
To be fair, the above is not the worst example of "smart" code that I have seen and the article is a nice explanation of why this works so thanks for that!
To me, more terse code is almost always easier to parse. Of course, everyone's different. There's not really a one size fits all solution. You'll have to agree with your team on a working standard.
I've already expressed mine opinion here around, and to be technically precise the code is easily testable as any if construct.
Thanks for sharing your opinion!
I do find the article helpful but to be honest with you, it was the first time I saw something like this.
I guess someone that is more experienced with the spread operator and augmenting objects in this way might have seen it more than me.
As you said, it is most probably a matter of opinion as a lot of things in javascript are those days, for example, I find something like this pretty hard to read:
let adder = (x) => (y, z) => x + y + z;
compared to the old-style alternative but there are people who love it.
So thank you again for going deep in your explanation :)
You're welcome!