Change the rule that expression functions should only be one line.

[davethomas11]

One line for expression functions?!? I must rebel on this one.

I like seeing code like this:

fun computeCollatzSteps(n: Int) = generateSequence(n) {
  require(it > 0)
  if (it % 2 == 0) it / 2 else it * 3 + 1
}.takeWhile({ it != 1 }).count()

Versus something like this:

fun computeCollatzSteps(n: Int): Int {
  require(n > 0)
  return generateSequence(n) {
    if (it % 2 == 0) it / 2 else it * 3 + 1
  }.takeWhile({ it != 1 }).count()
}

This function is for counting the number of steps in the Collatz Conjecture for a number. Taken from here http://exercism.io/exercises/kotlin/collatz-conjecture/readme

I know the second one is better because it calls require only once. But I added that so I could call out the reason for my argument, which is not for efficiency but for a certain coding style. When efficiency is not a concern but rather the benefits of functional programming are important, I feel that function expressions lead themselves towards this.

I do not claim to be an expert on functional programming by any means. I am a total newbie to these concepts. Concepts that have been around for a long time. But when you lock down a function in Kotlin into a simple expression format, to me it adds constraints on that function that make it work in more of a purely mathematical way. It makes it harder for the coder to write a none pure function. While it is still possible, I feel like it limits your options with the function, and encourages you to keep it more focused on its task.

I like having those limitations, I like having to think in a functional chain. Why? I feel like it makes code less error-prone. Also, forget being "cute", I think code written in this manner can actually be easier to read and maintain. Having one stream of flow to a function forces you to not rely on state manipulating changes. While that is still possible, I would frown on that in an expression function and strive for a purely functional approach. An approach where we have the same output for every input used.

Obviously a matter of opinion, but I think we should open expression functions to being more than one line for those of us that use them to express our code in that manner. My ask is for this restriction in the coding style to be removed, and for functional programming styles to be encouraged.

Perhaps the rule should be if your expression function does not modify the state of its surrounding code container and it always returns the same output for every input then multiple lines should be allowed.

One line is not enough to express some mathematical functions.

Also, nevermind simple cases where we have long class names ;) For example:
Ie.

  @Provides fun provideDatabase(context: Context): AppDB = 
      Room.databaseBuilder(context, AppDB::class.java, dbName).build()

That's 123 characters on one line.

I don't want to have to write that as a function with the return keyword.

Personally, I'd like to see the return keyword taken out back and put on a shelf for only the most necessary of use cases.

In my mind, you either have a void method that is doing a bunch of setup work or you have a function that returns some result. That result returned should be simple enough that an expression function should suffice.

---

Those that are more informed on these topics than I, please call me out where I am wrong on any concepts that I am thinking/writing here!

This one line rule for expression functions does not sit right with me.

---

So in conjecture with possible varying opinions on the matter of expression functions, would it be possible to loosen up this restriction?

We could perhaps say, "Multiple lines are allowed for expression functions that are pure functions"

A pure function is a function where the return value is only determined by its input values, without observable side effects.

---

My two cents, and this is by no means critical. Just sharing my opinion at the moment =)

[JakeWharton]

Dupe of #36. Your example is allowed as-is.

[davethomas11]

Lmao, thanks Jake. Once again I didn’t research other issues first or read into more detail through out the style guide. :p. Lesson learned!