-
Notifications
You must be signed in to change notification settings - Fork 421
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
Buildifier shouldn't break up blocks of constants with newlines #108
Comments
Note that this rule is currently codified in the style guide:
Although the motivation seemed to be one line as opposed to two. |
First off, that rationale is wrong; we have quite a few Bazel files full of utility functions, rule implementations, etc. that most certainly do not "[have] only top-level statements". That said, I agree the intent seems to be 'one blank line, not two', rather than 'one blank line, not none'. Anyway, here's another example where adding a blank line is clunky, if not outright misguided:
With no blank line, it is clear that the comment applies to both declarations. Adding a blank line here is actively harmful to clarity. |
This change does seem reasonable and worth considering, but note that internally it will require a depot-wide change so will have to be rolled out cautiously. |
Bazel files ( |
Add blank line as insisted upon by buildifier. This splits up a block of related variables, disassociating one from its corresponding comment, but there is no currently known way to stop this, and we need to be buildifier-clean in order to switch on enforcing of style correctness as judged by buildifier. See also bazelbuild/buildtools#108.
Add blank line as insisted upon by buildifier. This splits up a block of related variables, disassociating one from its corresponding comment, but there is no currently known way to stop this, and we need to be buildifier-clean in order to switch on enforcing of style correctness as judged by buildifier. See also bazelbuild/buildtools#108.
Is there any activity on fixing this? Or is there a way to disable it for a block of code (like I have a project where I have many groups of related constants in my I found this thread which suggests it's not possible: I also looked through this list of warnings for anything I could disable but didn't immediately find anything relevant: |
There's a recent discussion on it in #890, however there's currently no activity. It might be possible to disable formatter for a specific node with a comment, but in the example above one would need to comment every assignment statement:
Perhaps an easier approach would be to load all the necessary definitions from a .bzl file which is marked as "do not format" with a comment. Regarding blank lines, they are not enforced anymore in |
Alright, I will try the workaround of moving all my blocks into separate files. I am not sure that will be too convenient either, as these were for repository imports that need to be interleaved with Thank you for pointing out that this is specific to |
Note that the disabling comment is not yet implemented, that was just an idea of how it could work. If you mean forced empty lines between statements, that's specific to
|
* Adding `CompactConstantDefinitions` boolean flag to `tables/tables.go`. * Can be set via tables json file (`--add_tables` / `--tables` command line or `tables` / `addTables` json config option). * Updating `compactStmt()` in `build/print.go`. * If `CompactConstantDefinitions` is true and both statements are assignments (for const definitions), then the extra line should be removed. * Lower precedence than various other checks (like comment checks) to still allow extra lines when necessary. * Updating `setFlags()` in `build/print_test.go`. * Checking golden filenames for ".compactconst." to set `CompactConstantDefinitions` to true. * Adding `CompactConstantDefinitions` reset back to false in returned (deferred) func. * Copying various golden files (which contain constant definitions) to be ".compactconst." files. * Removing extra lines between const definitions as applicable. Fixes bazelbuild#108.
becomes
This is not ideal because a
BUILD
file with blocks of related constants can become very "fluffy" and difficult to scan over.Copying the
gofmt
logic of aligning equals signs in blocks of assignments would be nicer:Or, alternatively, just don't add newlines.
The text was updated successfully, but these errors were encountered: