https://kotlinlang.org logo
Join Slack
Powered by
Hi all, what do you use for linting Kotlin project...
# server
o
Hi all, what do you use for linting Kotlin projects?
j
t
we use detekt + the ktlint plugin for it. Other than when we first added it to the project we don't use the auto format from ktlint cli. Only did that initially then just configured the IDE format settings to match what the linter expects so you can spam autoformat as you work and come out matching the spec. some of the few appropriate to commit files from .idea imo.
👍 1
j
s
Previous gig I started us on Qodana. It was nice to have things running on server and the integration with GH made PR reviews so much better.
I learned we cant trust developers to be addressing lint rules/"problems" on their own. Some of them completely turned off warning UI elements rather than addressing. mind blown
😄 1
e
Maven Ktlint plugin with default settings to: • locally run 
./mvnw ktlint:format
as a pre-commit hook • robot for creating PRs/ MRs with 
./mvnw ktlint:format
autoformatted full codebase. For working in team The plugin setup is in pom.xml in my pet project https://github.com/Sedose/codecrafters-interpreter-kotlin as an example. I'm sure there is one for Gradle as well
✅ 1
To create such a pre-commit hook all you need is: • Run 
mkdir -p .githooks
• Run 
git config core.hooksPath .githooks
• Create similar file 
your_project_root/.githooks/pre-commit
Copy code
#!/bin/bash
# Run ktlint:format before commit

echo "Running ktlint formatter..."
./mvnw ktlint:format

# Check for any unstaged changes (i.e., formatting changes)
if ! git diff --quiet
then
  echo "Ktlint made formatting changes. Please review and stage them."
  git diff
  exit 1
fi
• Run 
chmod +x .githooks/pre-commit
With this setup you get autoformatting each time before you commit. And add this file to git to track it for your team so that everyone can use it
e
We use 
Detekt
for all Kotlin code in our project and 
Spotless
for all other code. If you are interested you can check our Gradle build file: https://github.com/infonl/dimpact-zaakafhandelcomponent/blob/main/build.gradle.kts
a
We use ktlint, which is great and very configurable, but out of the box it is EXTREMELY opinionated and they are very up front about it. We have to disable quite a few rules and some we have to live with until we create a custom rule that suits our style better. The standard indent rule for example has a lot of built in opinions about how chained methods and function paramters should be formatted that we aren't big fans of.
👍 1
e
Just to add. Golang gofmt is intentionally opinionated, and its creator argues that having a non-configurable formatter promotes consistency across all Go codebases. The underlying idea is that the benefits of universal formatting—such as improved readability, easier code reviews, and reduced bike-shedding—outweigh the drawbacks of not being able to customize formatting rules. Here is the original thread regarding this https://github.com/golang/go/issues/40028
👍 2
j
@Anonymike - you might be interested in this (if you haven't seen it)
👍 1
a
The spirit of that is great, but its a lot easier for the creator to say because its their opinion that gets coded lol. I'm certainly not against consistency, but there are definitely issues where developers tend to choose structural formatting over formatting for readability and the rules could be 95% the same (as we do with a lot of ktlint rules).
👍 1
t
hell didn't ktlint intentionally not support customization in the beginning in an attempt to be similar to gofmt?
👍 2
a
Yes, and we actually submitted pull requests to the project to help fix a bug or two. So its not that we're against ktlint by any means and still use it on every project.
We were completely on that boat at first, until we learned the lessons of that ourselves haha
t
it is a ton of fun to tell noisy devs to "go fmt yourself"
🤣 2
28 Views
Open in Slack
PreviousNext
Powered by