11–20 of 159 posts
As was once told to me, my code should look like your code and yours like mine.
> If computers are good at anything, they are good at parsing code and analyzing it. So I set out to make this work, and prettier was born. I didn't want to start from scratch, so it's a fork of recast's printer with the internals rewritten to use Wadler's algorithm from "A prettier printer". Bob Nystrom (munificent) disagrees[0] after writing one himself: > The search space we have to cover is exponentially large, a…
How does this compare to clang-format, which also formats JavaScript and also (to use one of the features highlighted in the article) obeys line length?
function makeComponent() {
return /*test*/ { a: 1
};
}
function makeComponent() {
return /*test*/
{ a: 1 };
}
Between this and eslint+flycheck I will feel less envious of Visual Studio Code's editor environment (if only there were a way to leverage some of its fantastic IntelliSense from emacs...)
[0] https://github.com/jlongster/prettier/tree/master/editors/em...
Nice attempt, but currently wrong. For example, it pretty-formats this code: function makeComponent() { return /*test*/ { a: 1 }; } into function makeComponent() { return /*test*/ { a: 1 }; } From my own experience writing a formatter, comments are very difficult (if one wants to preserve them). I guess the author should reparse the generated code to ensure the AST hasn't changed.
Nice attempt, but currently wrong. For example, it pretty-formats this code: function makeComponent() { return /*test*/ { a: 1 }; } into function makeComponent() { return /*test*/ { a: 1 }; } From my own experience writing a formatter, comments are very difficult (if one wants to preserve them). I guess the author should reparse the generated code to ensure the AST hasn't changed.
There are a very few subtle bugs like the one you mentioned above. As noted in the readme, this is a beta. It's certainly more than an attempt.
Nice attempt, but currently wrong. For example, it pretty-formats this code: function makeComponent() { return /*test*/ { a: 1 }; } into function makeComponent() { return /*test*/ { a: 1 }; } From my own experience writing a formatter, comments are very difficult (if one wants to preserve them). I guess the author should reparse the generated code to ensure the AST hasn't changed.
We do. The entire Flow test suite passes when pretty-printing and re-parsing and comparing ASTs. There are a very few subtle bugs like the one you mentioned above. As noted in the readme, this is a beta. It's certainly more than an attempt.
i.e foo({ num: 3 },