3 ms·

I wanted to post that ktfmt, the FB Kotlin formatter, is much less well-known than ktlint. IMO, it produces the most (subjectively) readable code, and is the o

I wanted to post that ktfmt, the FB Kotlin formatter, is much less well-known than ktlint. IMO, it produces the most (subjectively) readable code, and is the only one that doesn't leave room for you to inject personal style in certain places. (ktlint will let you get away with one of several ways of formatting code, so long as it falls within some guidelines, which can lead to inconsistent formatting). It's a superior formatting tool IMO. https://github.com/facebook/ktfmt https://github.com/facebook/ktfmt

deleted 4y ago
[deleted]
BoorishBears 4y ago
I had it act generally "weird" when adding it to our codebase and ripped it out. Sometimes it'd hang for several minutes, memory usage would spike from time to time. Didn't have time to bother debugging when ktlint just worked immediately.
- strulovich 4y ago
  When was that? IS that a big codebase? I fixed a memory leak issue a few months ago that would have a big effect when running over hundreds of files at once.
  - BoorishBears 4y ago
    More than a few months ago, and a fairly large codebase (~1000 files). I might give it another try for some personal projects since I did like the anti-bikeshedding angle with respect to configuration, but yeah linting can be a hard sell once build performance starts to suffer for it
    - strulovich 4y ago
      Most likely this fix would make a big difference then: https://github.com/facebook/ktfmt/commit/6ea9e8f461853c32177f3a3bc0d2ae4ea5718452 https://github.com/facebook/ktfmt/commit/6ea9e8f461853c32177...
jillesvangurp 4y ago
These two formatters both suffer from the flaw that what intellij does when it autoformats is different from what either of those two do and can only be controlled through plugins. Especially when it comes to controlling imports this stuff is just broken in Intellij. The settings for this are not actually part of the code formatting settings. Most sane code formatters & code standards: "don't use import wild cards!" Intellij's default since forever: "wildcards all over the place; please jump through hoops to get rid of them". I've given up on having code formatters in my kotlin builds for this reason. Just not worth the hassle of trying to make both sides just do the same thing by default so I don't have to think about it. And then having to explain to every new team member how they have to customize their intellij setup so it isn't broken. I just gave up on it. These days I tell people, auto format your code, leave the settings alone. Try to only format the code you modified to avoid endless formatting related diffs. The fix would be for Jetbrains to finally fix their IDE to have proper formatting that includes the behavior of organize imports and is perfectly in sync with whatever your build file says is the code style rather than whatever manual or built in stuff. Any IDE settings for this should IMHO just be removed as they are completely and utterly wrong in the presence of a build file that says how things should be formatted. Just default to whatever your build file says is the code standard with some sane default that just comes with the kotlin compiler. This should not be optional. You want to override it: do it in your build file. Auto format on save in intellij. CI build verifies that nothing is mis-formatted because the IDE did it right because it does whatever the build file specifies needs doing without second guessing that. Have a githook to format before commit (optional). Zero manual fixing of anything ever related to formatting. It should not have a chance to go wrong and break the build unless somebody forgot to format or have a commit hook to do so. Just import the project and everything does the right thing. That would be the goal. IMHO it's not technically hard but it would require addressing what is likely to be quite a bit of technical debt related to this in intellij. And it's about time they did that.
- BoorishBears 4y ago
  You wrote this entire comment but ktlint can generate a .editorconfig (and in fact used to generate a IntelliJ specific config file) which is a universal way of solving this exact problem. Pretty sure the FB equivalent also has a matching .editorconfig Also you could just setup a prepush hook so they run before your CI does which afaik both give you examples of.

deleted 4y ago

[deleted]

BoorishBears 4y ago

I had it act generally "weird" when adding it to our codebase and ripped it out. Sometimes it'd hang for several minutes, memory usage would spike from time to time. Didn't have time to bother debugging when ktlint just worked immediately.

strulovich 4y ago
When was that? IS that a big codebase? I fixed a memory leak issue a few months ago that would have a big effect when running over hundreds of files at once.
- BoorishBears 4y ago
  More than a few months ago, and a fairly large codebase (~1000 files). I might give it another try for some personal projects since I did like the anti-bikeshedding angle with respect to configuration, but yeah linting can be a hard sell once build performance starts to suffer for it
  - strulovich 4y ago
    Most likely this fix would make a big difference then: https://github.com/facebook/ktfmt/commit/6ea9e8f461853c32177f3a3bc0d2ae4ea5718452 https://github.com/facebook/ktfmt/commit/6ea9e8f461853c32177...

jillesvangurp 4y ago

These two formatters both suffer from the flaw that what intellij does when it autoformats is different from what either of those two do and can only be controlled through plugins. Especially when it comes to controlling imports this stuff is just broken in Intellij. The settings for this are not actually part of the code formatting settings. Most sane code formatters & code standards: "don't use import wild cards!" Intellij's default since forever: "wildcards all over the place; please jump through hoops to get rid of them". I've given up on having code formatters in my kotlin builds for this reason. Just not worth the hassle of trying to make both sides just do the same thing by default so I don't have to think about it. And then having to explain to every new team member how they have to customize their intellij setup so it isn't broken. I just gave up on it. These days I tell people, auto format your code, leave the settings alone. Try to only format the code you modified to avoid endless formatting related diffs. The fix would be for Jetbrains to finally fix their IDE to have proper formatting that includes the behavior of organize imports and is perfectly in sync with whatever your build file says is the code style rather than whatever manual or built in stuff. Any IDE settings for this should IMHO just be removed as they are completely and utterly wrong in the presence of a build file that says how things should be formatted. Just default to whatever your build file says is the code standard with some sane default that just comes with the kotlin compiler. This should not be optional. You want to override it: do it in your build file. Auto format on save in intellij. CI build verifies that nothing is mis-formatted because the IDE did it right because it does whatever the build file specifies needs doing without second guessing that. Have a githook to format before commit (optional). Zero manual fixing of anything ever related to formatting. It should not have a chance to go wrong and break the build unless somebody forgot to format or have a commit hook to do so. Just import the project and everything does the right thing. That would be the goal. IMHO it's not technically hard but it would require addressing what is likely to be quite a bit of technical debt related to this in intellij. And it's about time they did that.

BoorishBears 4y ago
You wrote this entire comment but ktlint can generate a .editorconfig (and in fact used to generate a IntelliJ specific config file) which is a universal way of solving this exact problem. Pretty sure the FB equivalent also has a matching .editorconfig Also you could just setup a prepush hook so they run before your CI does which afaik both give you examples of.