5 ms·
I'd agree in general, but that hardly works for larger teams or even multiple teams. This can probably be solved by a good linting tool, but I am not too famili
by renke1 6y ago
I'd agree in general, but that hardly works for larger teams or even multiple teams. This can probably be solved by a good linting tool, but I am not too familiar with the state of linting in Kotlin.
- thu2111 6y agoThe best linter for Kotlin is the IntelliJ inspector, which is very powerful. You can run inspections from CI builds using TeamCity, at least, probably other CI builds. You may also configure project defaults to trigger various patterns as warnings or errors. Even better, in the latest IntelliJ you can create new inspections from structural search, which is an AST based matching system. So you have a lot of flexibility to make your own lints and warnings without needing to write plugins. However, I think there's a more general issue here, which is that if you don't trust your team to write tasteful code, linters will be of limited use. It may be better to invest in more rigorous code reviews, trainings, style guidance, mentoring etc. I've spent five years managing technical teams using Kotlin (yep, early adopter!) and found most of them could handle it just fine. A little training goes a long way. The worst problems came from developers creating overly complex abstractions, not playing code golf.