We have a kind of policy that the output that is g...
# ktlintp
Paul Dingemans
12/28/2021, 5:30 PMWe have a kind of policy that the output that is generated by ktlint should be accepted without any further changes by the default IntelliJ code formatter. Although I do understand this policy, I do not always like it.
Sometimes, the IntelliJ code formatter just formats code in a way which is clearly wrong or not consistent with what a user is expecting. Even though we would be able to produce nicer and consistent code, we avoid doing so as IntelliJ would reformat that code once more. This could end up in an endless cycle in which IntellIiJ and KtLint are reformatting the code over and over again. But is it really a valid assumption that both ktlint and IntelliJ code formatting are used within the same code base? Can't we expect that if project chooses KtLint to format its code, that IntelliJ code formatting no longer should be applied?
@Sha Sha Chu @romtsn @tapchicoma
b
Brais Gabin
12/28/2021, 6:37 PMI use ktlint on my CI but I use the IntelliJ formatter all the time. I agree with you that IntelliJ some times doesn't format the code nicely but I think that ktlint should work nice with the IntelliJ formatter.
Maybe there can be a "compromise": If ktlint provides a "better default configuration". (I know that this doesn't give complete freedom)
p
Paul Dingemans
12/28/2021, 8:36 PMWhat is the advantage of using different formatting in CI versus in IntelliJ? Does the CI just fail on linting errors?
Is it correct that with providing a "better default configuration" you mean that ktlint proposes changes in the ".editorconfig" file?
b
Brais Gabin
12/29/2021, 10:58 AMThe advantage is that we don't force to anyone to install ktlint in their machines (anyone can do it if they want but we don't force it). They just need to follow the code style. In CI we just check that no one forget to format its code properly.
I was thinking about creating a
.xml.editorconfigp
Paul Dingemans
12/29/2021, 1:54 PMOk, it is clear to me why there is a use case for using ktlint and IntelliJ formatting next to each other.
But I am afraid that it is blocking us from improving problems like issue https://github.com/pinterest/ktlint/issues/1324 unless the underlying problem is first addressed by the IntelliJ team responsible for code formatting. I see no way to solve issues like with this with changes in the .editorconfig file.
b
Brais Gabin
12/29/2021, 3:03 PMYes, I understand you. It's an ugly trade off... It was my 2 cents.
s
Sha Sha Chu
01/04/2022, 4:53 PMHi all, yes it’s been a semi-official stance that we should match IntelliJ’s formatting due to it being by far the most popular Kotlin IDE. our general long-term strategy is to introduce codestyle sets, so there might be an ‘IntelliJ’ set where the rules all match the intellij formatting, then another set if you want custom rules. it doesn’t directly address this issue, but whenever we don’t match IntelliJ formatting we get a lot of bugs around it so it’s been easiest to try to match IntelliJ, quirks and all.
p
Paul Dingemans
01/04/2022, 6:05 PMOk clear. What would the advice be in the issue I mentioned before? I would prefer to close the issue as "won't fix" until it has been addressed by the IntelliJ team. Also, I think it is the responsibility of
the original poster of the issue to address this with the IntelliJ team if (s)he really wants this to be fixed.
s
Sha Sha Chu
01/10/2022, 5:44 PMYeah for now I'd say let's err on the side of matching intellij. We can leave it open but maybe link the bug ok the intellij side
p
Paul Dingemans
01/10/2022, 6:04 PMSorry but that is not an answer to my question. I will close the issue. If the original poster add a link to the Intellij issue, it can be reopened.
6 Views