3 ms·
FWIW Black ( https://github.com/ambv/black https://github.com/ambv/black ) is a disciplined Python formatter that's reasonably successful, so I'm not convinced
by alangpierce 8y ago
FWIW Black ( https://github.com/ambv/black https://github.com/ambv/black ) is a disciplined Python formatter that's reasonably successful, so I'm not convinced that the "significant indentation" thing actually matters too much; it probably just means that formatters need to be more careful to not introduce bugs, but the same principle of code -> AST -> code seems just as valid.
What line splitting issues are you referring to? I've been pretty happy with the approach used by Prettier (and I believe Black) of fitting it on one line if possible, and doing one per line otherwise. I'd say that's my favorite part of Prettier: I don't need to think about wrapping anymore, it figures it out, so it's sad to see that gofmt doesn't do that (from my testing just now).
- mbell 8y agoI think you're only considering a one-way transform, what's being proposed above is two-way. i.e. Store the output of Black as the 'canonical' version, but translate it back into your preferred style when looking at the code in your editor. > but the same principle of code -> AST -> code seems just as valid The question is really the reversibility of the transform in a reasonable way. If you are translating all your source to an AST there is technically no reason multiple programmers even need to be working in the same language. However in practice, even within a single language, there are many possible transforms from an AST back into code. Some will make sense, some will be nearly indecipherable. In practice you either limit the allowed transforms such that there is little benefit over a simple linting tool or the problem explodes in complexity.