[afavour]

I agree with the author that it’s a little confusing, but that’s why I wouldn’t write code like that.

    const msg = capitalize(greeting) + “!”;
    const { status } = await send(msg);
    console.log(status);

Now it’s perfectly readable, no weird shenanigans required.

[marcus_cemes]

This is clean JavaScript syntax in my opinion and should be what people strive for. It's perfectly readable, it's faster, it does async correctly without any unnecessary computation, can be typed and will have a normal stack trace. Piping is cool when done right, but can introduce complexity fast. Elixir is a good example where it works wonderfully.

[jameshart]

But at what cost? You had to name two intermediate variables - and naming things is hard.

[progx]

In this case the variable is the documentation of the code.

You don't have to write something like "this is the message", you can see it.

[amadeuspagel]

What if it isn't a message? What if "msg" is already used for another variable?

[afavour]

This is some wonderful performance art you’re doing here

[Bjartr]

`greetingMsg`? `greeting`? Naming the other one differently? Splitting the work done with that message and the work done with this message into their own functions?

[wruza]

Frankly, this always sounded like a readability issue seeking a readability problem. Splitting because the names clash, because you decided to name things, because a one-liner was less than ideally readable.

[rickstanley]

"_msg", then.

[colordrops]

Because they provide value and document the chain of events. I fear a long list of piped expressions without any idea of what they are intended to to. Would be like big regexps.

[bassdigit]

Not hard: msg can be derived from the parameter name of the send() function and status is a fixed attribute of the result.

[jameshart]

Even worse - you’re polluting your local namespace with names decided on by other code.

I’m obviously not being serious about naming being hard in this example.

But there are cases where the pattern of using return object property names as variables comes back to bite uou.

Even in this case, what if the response object from ‘send()’ also has a ‘msg’ property?

Changing const { status } into const { status, msg } is an error.

We should be cautious about syntaxes that force us to allocate names. Sometimes.

[bassdigit]

Still not hard: In that case, instead of msg use sendMsg AND/OR in the second statement use { status, msg: resultMsg }, or just result and later result.msg.

[vikingerik]

Code is read many more times than it is written. Put in the minute or two to devise good intermediate variable names, and that will pay back manyfold every time someone needs to read and understand it.

[wruza]

Some code. E.g. most of my code was barely read by anyone, as most of it was utilitary or mvp or niche/local enough to never see big light. And when from time to time I read other code, e.g. on github, in projects I’m occasionally interested in, there’s barely anything resembling these high class advices. FOSS with large reach - yeah. But a library that you found for a specific hardware is “just code”. And to be honest, the difference between the two is not that big. Any decent programmer navigates both almost equally fast. As someone who modified Lua internals (typical example [1]) for employer’s needs I can say that I prefer Lua style to ceremony on top of ceremony, to multiparagraph explanations of what should be obvious to a competent developer, and to hundreds of extracted functions for the sole reason of clean-ish scopes or whatever.

But still I’ve done what people advised, for many years. And know what? It never paid back. I’m sort of tired to keep that secret and nod to this obvious overgeneralization and a blanket idea. Pretty sure I’m not alone.

[1] https://github.com/lua/lua/blob/6baee9ef9d5657ab582c8a4b9f88...