-
-
Notifications
You must be signed in to change notification settings - Fork 873
New Rule: LT15 #6641
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
New Rule: LT15 #6641
Conversation
Coverage Results ✅
|
layout.newlines: | ||
maximum_empty_lines_between_statements: 1 | ||
|
||
test_fail_bad_edge_case: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alanmcruickshank here is the edge case that i'd like to avoid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean 🤔 . I'm really not sure this is a problem. Personally I feel like the semicolon "belongs" to the preceding statement, but I also think a comma "belongs" to the preceding line. Leaving this open so that we're a bit more lenient on whether the "between statements" gap is before or after the semicolon I think is ok.
I don't think hard coding the behaviour is worth the extra complexity unless we also give people the option to configure it in case they want to do.... leading semicolons?!.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm trying to say: I think this PR is ok as-is. We can always optionally tighten it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add a comment to that test case to explain
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. I don't think the edge case is a problem at the moment. Yeah some people will disagree but I think that's small potatoes and can be handled at a later date. This already adds a bunch of value as-is.
Brief summary of the change made
This PR adds a long-requested rule. It allows the control of how many blank lines there can be in a row. It is configurable to different values inside and outside of a statement.
This changes the default rule set - and so should trigger a minor release.
Fixes #2634
Are there any other side effects of this change that we should be aware of?
No
Pull Request checklist
Please confirm you have completed any of the necessary steps below.
Included test cases to demonstrate any code changes, which may be one or more of the following:
.yml
rule test cases intest/fixtures/rules/std_rule_cases
..sql
/.yml
parser test cases intest/fixtures/dialects
(note YML files can be auto generated withtox -e generate-fixture-yml
).test/fixtures/linter/autofix
.Added appropriate documentation for the change.
Created GitHub issues for any relevant followup/future enhancements if appropriate.