Skip to content
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

Rule: newline before "{" #458

Closed
CalebeRios opened this issue Jun 5, 2019 · 9 comments
Closed

Rule: newline before "{" #458

CalebeRios opened this issue Jun 5, 2019 · 9 comments

Comments

@CalebeRios
Copy link

Hello everyone, in the project I work we use { a line below the function signature. I would like to know if it is possible to ignore this rule through .editorConfig

@shashachu
Copy link
Contributor

Hi, there's not currently a way to globally disable rules but that is in the roadmap.

@CalebeRios
Copy link
Author

Ok, but where is this roadmap?

@shashachu
Copy link
Contributor

A high level roadmap is here: https://medium.com/@Pinterest_Engineering/pinterest-ktlint-35391a1a162f

For this specific issue, I just put up a PR: #459

@CalebeRios
Copy link
Author

Oh, I understand. I will follow this PR. Thanks!

@JLLeitschuh
Copy link
Contributor

JLLeitschuh commented Jun 7, 2019

@shashachu Just want to comment on this general principle of configurable:

The mission statement of the project is:

An anti-bikeshedding Kotlin linter with built-in formatter

Adding additional configuration like this seems to be bikeshedding and is in contradiction with the original intention of the project.

@shashachu
Copy link
Contributor

@shashachu Just want to comment on this general principle of configurable:

The mission statement of the project is:

An anti-bikeshedding Kotlin linter with built-in formatter

Adding additional configuration like this seems to be bikeshedding and is in contradiction with the original intention of the project.

@JLLeitschuh thanks for the feedback. I actually agree with you. But in this case we're approaching it from a perspective of trying to balance what is 'right' vs what is best for the project. When we initially talked to @shyiko he mentioned things like disallowing wildcard imports being a big point of contention, and a named reason why developers had not adopted the tool. So in his handover doc, he listed as a recommendation some sort of glob-pattern-based rule suppression file, and I agree that this is the best thing in the interest of supporting wider adoption of ktlint. I do think this is a form of bikeshedding, but by giving developers an on-off switch, we at least push the bikeshedding out of ktlint and into their own projects, if that makes sense.

@JLLeitschuh
Copy link
Contributor

I think an on/off switch is a good happy medium

Sent with GitHawk

@shashachu
Copy link
Contributor

@CalebeRios I landed PR #503 to add support for a disabled_rules option in the .editorconfig to globally disable rules. It will be released in 0.34.0.

@CalebeRios
Copy link
Author

Hei, thanks a lot. I hope this release launch fast, but thanks for fast reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants