Why should I choose the shortest way if it needs an article to be explained? In my opinion, the best code is the self-explanatory one, not the shortest one
I work with pedagogies, teach, write curricula, coach, manage, mentor, consult, speak publicly, polemicize, and sometimes work as a full-stack web developer, architect, ontologist, and more.
This is a perfectly self-explanatory technique. If you understand the spread syntax, and how short-circuted Boolean expressions work, then you can see at a glance what this does. The text above is not an explanation of the code, but proof that it works without surprises. Hence, this is both the shortest and quite self-explanatory.
I would even go so far as to say that this is a lot more readable than the alternatives. Bravo, Mr. Costa.
At no point does the author claim that short code should supersede readable code.
You centered the point, thank you for intervening!
P.S. I think it's very readable too, but I'm realizing, reading a great number of opinions and comments even on a small thing like the one I presented in the article, how readability is a subjective thing.
It's called an "idiom". Like any other idiom, including idioms in naturally language, you have to learn it. That doesn't mean it's not useful. If people run into it and are not familiar with it, they'll figure it out quickly and then know it themselves.
I completely disagree because lot of JS syntax and features need an explaination. Think about coercion, generators, arrow functions, async await, the asynchronous iteration, proxies, ecc.
More generally each concept in every programming language, also the basic ones, may need an explanation.
And, with your line of thinking, people risk to never learn anything and never improve themselves.
The article is explaining why the syntax is valid. But the main concept, the optional insertion of a property, is understandable in 10 seconds.
After a little example, if you spend 5 mins with it, you can already understand what's going on:
...condition && {prop:value}
If the condition is true a prop will be added. No side effects in the other case. Simple.
It's something with which one can become familiar in no time, it's something immediately teachable to others and I've demostrated that it works not because an undefined, untrustable behaviour but thanks to a precise logic put black on white in the spec.
I don't criticize the use of idiomatic code (I often use it, too) but the emphasis on the shortest way.
It seems to encourage the writing of compact or idiomatic code at any cost, and it is not always the best choice.
As with natural language, if you use very strict jargon, you reduce the number of people who are able to understand it with little effort.
The shortest way means only one thing: fewer characters are required.
The second part you deduced is your personal interpretation of the title, which obviously does not reflect my thinking at all.
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
I like this pattern not just because it's the "shortest" but because it's the most declarative. This way, I can construct and assign my object in one place, without going back later to mutate it's contents. I think that leads to better code because it reduces the need to mentally execute each line.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why should I choose the shortest way if it needs an article to be explained? In my opinion, the best code is the self-explanatory one, not the shortest one
This is referred to as the "either/or fallacy", also referred to as the "false dilemma": en.wikipedia.org/wiki/False_dilemma
This is a perfectly self-explanatory technique. If you understand the spread syntax, and how short-circuted Boolean expressions work, then you can see at a glance what this does. The text above is not an explanation of the code, but proof that it works without surprises. Hence, this is both the shortest and quite self-explanatory.
I would even go so far as to say that this is a lot more readable than the alternatives. Bravo, Mr. Costa.
At no point does the author claim that short code should supersede readable code.
You centered the point, thank you for intervening!
P.S. I think it's very readable too, but I'm realizing, reading a great number of opinions and comments even on a small thing like the one I presented in the article, how readability is a subjective thing.
It's called an "idiom". Like any other idiom, including idioms in naturally language, you have to learn it. That doesn't mean it's not useful. If people run into it and are not familiar with it, they'll figure it out quickly and then know it themselves.
I completely agree with you.
I completely disagree because lot of JS syntax and features need an explaination. Think about coercion, generators, arrow functions, async await, the asynchronous iteration, proxies, ecc.
More generally each concept in every programming language, also the basic ones, may need an explanation.
And, with your line of thinking, people risk to never learn anything and never improve themselves.
The article is explaining why the syntax is valid. But the main concept, the optional insertion of a property, is understandable in 10 seconds.
After a little example, if you spend 5 mins with it, you can already understand what's going on:
...condition && {prop:value}
If the condition is true a prop will be added. No side effects in the other case. Simple.
It's something with which one can become familiar in no time, it's something immediately teachable to others and I've demostrated that it works not because an undefined, untrustable behaviour but thanks to a precise logic put black on white in the spec.
I don't criticize the use of idiomatic code (I often use it, too) but the emphasis on the shortest way.
It seems to encourage the writing of compact or idiomatic code at any cost, and it is not always the best choice.
As with natural language, if you use very strict jargon, you reduce the number of people who are able to understand it with little effort.
The shortest way means only one thing: fewer characters are required.
The second part you deduced is your personal interpretation of the title, which obviously does not reflect my thinking at all.
Maybe you're right. Sorry for any misunderstanding.
No problems 😃!
See you at the DevFest, with peaceful intentions of course 😝
I've never had any non-peaceful intentions :-)
See you at the DevFest!
I like this pattern not just because it's the "shortest" but because it's the most declarative. This way, I can construct and assign my object in one place, without going back later to mutate it's contents. I think that leads to better code because it reduces the need to mentally execute each line.