4 ms·

>suggest shorter yet less readable alternatives What do you mean exactly? I feel like Kotlin's brevity is what actually makes it a lot more readable than Java.

>suggest shorter yet less readable alternatives What do you mean exactly? I feel like Kotlin's brevity is what actually makes it a lot more readable than Java. With Java there's just often so much noise and fluff that doesn't actually mean much, obscuring what the program actually does. Could just be my personal preference, but I feel like in general I have an easier time understanding terse, dense code rather than spacious, verbose code.

renke1 6y ago
I can't give specific examples, but something along the lines of suggesting to replace an early return in the form of `if (…)` by something like `… ?:return`. The former alternative makes it way easier to spot on first glance where the functions bails out. The latter hides it in an assignment making it harder to see. I should say, though, that I am by no means an expert Kotlin developer; maybe I just have to get used to idiomatic Kotlin.
- thu2111 6y ago
  Don't take idiomatic Kotlin too seriously. It's not Go where there's exactly one allowed way to do things. IntelliJ's suggestions go both ways - you can convert to short form and also back to long form automatically. It's that way for a reason: you're trusted to pick the right form on your own.
  - 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 ago
      The 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.
- hitekker 6y ago
  I think you're onto something. Developers look at their freshly written code, marvel at how succinct it is and then pat themselves on the back for being so clever. "It's just one line and I read it. Boom! Readable!". A few months later, another developer comes to look at the code and has to spend 10x more time parsing each character in that statement before they can even understand the logic behind it. Brevity might be a kind of "vanity metric" when it comes readability.

renke1 6y ago

I can't give specific examples, but something along the lines of suggesting to replace an early return in the form of `if (…)` by something like `… ?:return`. The former alternative makes it way easier to spot on first glance where the functions bails out. The latter hides it in an assignment making it harder to see. I should say, though, that I am by no means an expert Kotlin developer; maybe I just have to get used to idiomatic Kotlin.

thu2111 6y ago
Don't take idiomatic Kotlin too seriously. It's not Go where there's exactly one allowed way to do things. IntelliJ's suggestions go both ways - you can convert to short form and also back to long form automatically. It's that way for a reason: you're trusted to pick the right form on your own.
- 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 ago
    The 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.
hitekker 6y ago
I think you're onto something. Developers look at their freshly written code, marvel at how succinct it is and then pat themselves on the back for being so clever. "It's just one line and I read it. Boom! Readable!". A few months later, another developer comes to look at the code and has to spend 10x more time parsing each character in that statement before they can even understand the logic behind it. Brevity might be a kind of "vanity metric" when it comes readability.