3 ms·

> Another problem I have is that I find there's a common style of JS which consist in daisy-chaining a myriad of methods and anonymous functions, and I really s

by mvdtnz 3y ago

> Another problem I have is that I find there's a common style of JS which consist in daisy-chaining a myriad of methods and anonymous functions, and I really struggle with this. I like to break stuff into lines, name my functions and variables, etc. I think your whole comment is excellent but I just wanted to tell you, you're on the right track here. Certain developers, and in particular JS developers, love to chain things together for no benefit other than keeping it on one line. Which is no benefit at all. Keep doing what you're doing and don't let this moronic idiom infect your mind.

xanderlewis 3y ago
Sometimes making something a one-liner is itself a benefit for readability. Especially if you’re used to reading it. But admittedly it’s very easy (and can be tempting) to take it too far…
zeroonetwothree 3y ago
The downside of extra variables used only once is that as a reader of the code I have to think about whether they might be used again.
- mvdtnz 3y ago
  I know what you mean, but in this situation it shouldn't be a major problem. These would be variables scoped locally and one would hope that this scope would not be more than about a page of code, and hopefully much less. Also - one would hope that local variables are not being re-used!
vjerancrnjak 3y ago
This is just another coding style. After 1-2 weeks you get used to whatever you're reading. Try it and you'll see. It's the high-level code that can become an issue (structuring the state of your program, using dependency injection incorrectly, having a convoluted monad transformer stack, putting very specifically typed effects in your Reader etc.). If you make mistakes there, you will struggle to read, write and reuse code, and even then, not all is lost. If there's bad structure you can most often transform it into a good one. When there's no structure, that's a problem. Seeing .map.filter becomes a quick pattern match. You know what's happening there. It does not matter if it's a named variable or just part of a long a.map .filter .reduce .map chain. I agree, if your goal is to hire a lot of people, then you might want a style that does not strain the pattern matching abilities too much. We can compare which style is the best for that. Nothing stops you from extracting a sequence from a long chain into a function to reuse it elsewhere. pipe( object, map, filter, ... ) Many languages today allow declaring functions inside functions. I'd argue that in that case it's better you declare functions as close as possible to the place where you'll call them, which can be inside another function.

by mvdtnz 3y ago

xanderlewis 3y ago

Sometimes making something a one-liner is itself a benefit for readability. Especially if you’re used to reading it. But admittedly it’s very easy (and can be tempting) to take it too far…

zeroonetwothree 3y ago

The downside of extra variables used only once is that as a reader of the code I have to think about whether they might be used again.

mvdtnz 3y ago
I know what you mean, but in this situation it shouldn't be a major problem. These would be variables scoped locally and one would hope that this scope would not be more than about a page of code, and hopefully much less. Also - one would hope that local variables are not being re-used!

vjerancrnjak 3y ago

This is just another coding style. After 1-2 weeks you get used to whatever you're reading. Try it and you'll see. It's the high-level code that can become an issue (structuring the state of your program, using dependency injection incorrectly, having a convoluted monad transformer stack, putting very specifically typed effects in your Reader etc.). If you make mistakes there, you will struggle to read, write and reuse code, and even then, not all is lost. If there's bad structure you can most often transform it into a good one. When there's no structure, that's a problem. Seeing .map.filter becomes a quick pattern match. You know what's happening there. It does not matter if it's a named variable or just part of a long a.map .filter .reduce .map chain. I agree, if your goal is to hire a lot of people, then you might want a style that does not strain the pattern matching abilities too much. We can compare which style is the best for that. Nothing stops you from extracting a sequence from a long chain into a function to reuse it elsewhere. pipe( object, map, filter, ... ) Many languages today allow declaring functions inside functions. I'd argue that in that case it's better you declare functions as close as possible to the place where you'll call them, which can be inside another function.