-
Notifications
You must be signed in to change notification settings - Fork 86
Break up complex if expressions into multiple lines #465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This formatting was added in v0.12.0 (was discussed in #289) It will only apply if your line is above the column width though, which I assume in this example it isn't |
I find the first example really hard to read. I ended up rewriting it to use a regular if statement instead. I think it would have been fine to stay as an ifexpr if it was broken up though. |
Yeah I agree with you that it's definitely nicer to read when separated on multiple lines. Not entirely sure what kind of heuristic to apply here though, because it's technically correct in that it respects column width, but we want it to trigger earlier. An arbitrary reduction in column width (e.g. column width - 20) is also odd. Relying on existing formatting is also something I want to avoid. The simplest way right now would be to change your own column width to something like 100 instead of 120, but if you're following a standard then that isn't ideal. |
What I'm finding in other large Luau projects is that 120 characters column width as the standard code style just doesn't work with the increased density and flexibility being added to the language. This lines up with a pattern I saw in JS projects migrating TypeScript, and in C++ projects that migrated to C++14 and started to adopt lambdas and other density-per-line increases. In those cases, we also dropped the column width from 120 to 100, or 100 to 80, for the same reasons. (Modern syntax-coloring and grammar-aware code editors were in use in all those projects as well.) |
FYI, we merged a change to the Roblox Lua Style Guide today that now recommends using a 100 character line length, versus 120 characters. |
Coming back to this, I wonder if we should accept the formatter irreversability (like we do for tables), and keep an if expression expanded if it was already expanded in the input code. I don't think there is any nice heuristic to make this look reasonable, so relying on input is probably our best bet. Drawback is that it will also suffer from #264 |
Before:
After (suggested):
The text was updated successfully, but these errors were encountered: