4 ms·

Do you have any examples where prettier code is much less readable? I haven't really ran into that issue and have been very happy with prettier.

deleted 3y ago
[deleted]
harimau777 3y ago
Prettier often makes code written using sequences of .chaining much more difficult to read by forcing it all to the same line. For the same reason, it often makes code written using composition more difficult to read since it won't let you decide when to put a sub-call on its own indented line for clarity.
- floydnoel 3y ago
  In those situations I make use of comments to force new lines where I want them. Stupid but it works!
- pkilgore 3y ago
  Disable it! (https://prettier.io/docs/en/ignore.html https://prettier.io/docs/en/ignore.html) I do this occasionally, and especially with things like test tables. Linters/formatters are there to help in the common case, not to be some oppressive dogma.
  - hu3 3y ago
    If the fix is to disable prettier for an entire file, you're proving your parent poster point.
    - dewey 3y ago
      It doesn't have to be disabled for the whole file, you can annotate lines too as shown in the link the parent commenter shared.
      - francislavoie 3y ago
        Adding comments just to fight with prettier is... uglier. I rather just not use prettier at all. It's more harmful than good IMO.
- HellsMaddy 3y ago
  I had the same gripe, and recently tried switching to dprint. It is much less aggressive with changing where lines break, and honestly it’s a huge relief to be able to break lines wherever I think makes the code most readable. It’s also significantly faster than prettier. I’ve been very happy with it.
  - morbicer 3y ago
    dprint is soo much better (configurable) and already written in Rust so very fast I am sad it's not getting more popular
mostlylurks 3y ago
If I don't remember wrong, doesn't it put object destructurings on one line if they fit? That's both less readable than putting each destructured member on its own line as well as a cause of unnecessary whitespace changes in your commit history if you ever add one more field to the destructuring that takes it over the line length limit.
- floydnoel 3y ago
  Add a comment anywhere in the destructuring and it will force each property onto its own line.
nicoburns 3y ago
A good example from further down the comment section: Prettier doesn't break template literals, but it will break non-literal sections of template strings. For example, if we wrote this: const foo = `aaaaaaaaaaaaaaa${bbbbbbbbbbbbb}ccccccccccccccc${ddddddddddd}`; prettier would fix it to const foo = `aaaaaaaaaaaaaaa${ bbbbbbbbbbbbb }ccccccccccccccc${ ddddddddddd }`; Which is not only much harder to read in it's own right, but now takes up 6 lines instead of one!
- bakkoting 3y ago
  I have a PR fixing that: https://github.com/prettier/prettier/pull/15209 https://github.com/prettier/prettier/pull/15209 Just needs another maintainer's stamp.

deleted 3y ago

[deleted]

harimau777 3y ago

Prettier often makes code written using sequences of .chaining much more difficult to read by forcing it all to the same line. For the same reason, it often makes code written using composition more difficult to read since it won't let you decide when to put a sub-call on its own indented line for clarity.

floydnoel 3y ago
In those situations I make use of comments to force new lines where I want them. Stupid but it works!
pkilgore 3y ago
Disable it! (https://prettier.io/docs/en/ignore.html https://prettier.io/docs/en/ignore.html) I do this occasionally, and especially with things like test tables. Linters/formatters are there to help in the common case, not to be some oppressive dogma.
- hu3 3y ago
  If the fix is to disable prettier for an entire file, you're proving your parent poster point.
  - dewey 3y ago
    It doesn't have to be disabled for the whole file, you can annotate lines too as shown in the link the parent commenter shared.
    - francislavoie 3y ago
      Adding comments just to fight with prettier is... uglier. I rather just not use prettier at all. It's more harmful than good IMO.
HellsMaddy 3y ago
I had the same gripe, and recently tried switching to dprint. It is much less aggressive with changing where lines break, and honestly it’s a huge relief to be able to break lines wherever I think makes the code most readable. It’s also significantly faster than prettier. I’ve been very happy with it.
- morbicer 3y ago
  dprint is soo much better (configurable) and already written in Rust so very fast I am sad it's not getting more popular

mostlylurks 3y ago

If I don't remember wrong, doesn't it put object destructurings on one line if they fit? That's both less readable than putting each destructured member on its own line as well as a cause of unnecessary whitespace changes in your commit history if you ever add one more field to the destructuring that takes it over the line length limit.

floydnoel 3y ago
Add a comment anywhere in the destructuring and it will force each property onto its own line.

nicoburns 3y ago

A good example from further down the comment section: Prettier doesn't break template literals, but it will break non-literal sections of template strings. For example, if we wrote this: const foo = `aaaaaaaaaaaaaaa${bbbbbbbbbbbbb}ccccccccccccccc${ddddddddddd}`; prettier would fix it to const foo = `aaaaaaaaaaaaaaa${ bbbbbbbbbbbbb }ccccccccccccccc${ ddddddddddd }`; Which is not only much harder to read in it's own right, but now takes up 6 lines instead of one!

bakkoting 3y ago
I have a PR fixing that: https://github.com/prettier/prettier/pull/15209 https://github.com/prettier/prettier/pull/15209 Just needs another maintainer's stamp.