4 ms·
If I personally prefer the second Promise chain: myPromise.then(() => { // ... }).then(() => { // ... }).catch(() => { // ..
by BrandonM 10y ago
If I personally prefer the second Promise chain:
myPromise.then(() => {
// ...
}).then(() => {
// ...
}).catch(() => {
// ..
});
and if I also prefer the Lisp-like approach and hate putting:
);
on its own line, am I part of the problem? What if my whole team uses that style? For example, we would write:
foo(
reallyLongArg(),
omgSoManyParameters(),
IShouldRefactorThis(),
isThereSeriouslyAnotherOne()
);
as:
foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(),
isThereSeriouslyAnotherOne());
(100 characters wide, double indent on the continuation line. This is pretty standard for Java formatting.)
Stated differently, is this meant to be very opinionated in hopes that all JS would follow a uniform style? I think that can work for Go since it was like that from Day 1. For JS, though, it has been out for so long that many teams have developed their own preferred style. I suspect that most of them would avoid an opinionated formatter that differs in a few small ways from their in-house format, if only because it seems silly to break diffs and git blame for a sweeping formatting change.
- tlrobinson 10y agoI avoid opinionated lint rules because it's annoying to retrain yourself, but if my editor does all the work and it's readable enough I'd love to adopt this or something like it. The version control issues might be a blocker though. It would be neat if git had a way to do diffs at the syntax tree level.
- Semiapies 10y agoWould using the git diff with whitespace ignored not help?
- tlrobinson 10y agoPrettier inserts missing semicolons, but otherwise maybe.
- joshwcomeau 10y agoI think that this is definitely not a tool for everybody, and I think that's alright. Dan Abramov said it best, when he opened an issue urging to resist the urge to add configuration: https://github.com/jlongster/prettier/issues/40 https://github.com/jlongster/prettier/issues/40 Configuration has a cost, and the product will be better and more reliable if it's limited. As it stands right now, the configuration isn't ideal for my preferences, but I'm fine with that; either I'll * use the tool and adopt new patterns (ones which, frankly, have very little impact on anything), * keep doing this stuff manually (it's gotten me this far!) * fork the project, and bear the cost of maintaining the updated configuration myself.
- gsylvie 10y agoI find if I hate a formatting pattern that I'm forced to use, after a while I prefer it and hate all others.