One Off the Slack: How Big Should a Composable Be?

Filip Wiesner asked:

What is the size (LOC) of @Composable function when you ask yourself “should I divide this into separate composables/files”?

This was a “poll by emojis” sort of Slack post, with various options like “100 lines”. The winner, by a wide margin, was “It’s not dependant on number of lines but rather number and cohesion of parameters”.

Filip followed up on that one with:

is there some some other secondary limit? Honestly I can’t imagine 300+ LOC function doing one thing

Google’s Zach Klippenstein suggested that composable functions and non-composable functions would have the same sort of sizing rules. Filip disagreed initially:

Personally it is different for me. The difference being that I pass a lot of lambda functions around and it gets quickly messy.

Thinking about (re-)composition and reusability in bigger scope is also a big difference for me.

Zach pushed back:

Right but non-composable functions can also have lots of lambdas, e.g. for DSLs. And recomposition shouldn’t affect this answer in most cases – if the correctness of your code depends on very specific recomposition boundaries between components, something else is probably wrong.

Filip was not completely convinced:

Yes, you are right. Now that I thought about what I wrote, I am not that sure anymore if it makes difference for function size 😅

But composable/non-composable function size preference is still different for me. I think I can handle bigger UI-emitting composables than normal funcitons.

I… use way more empty lines with Composable functions. And maybe it is just because I am not used to writing really long non-composable functions so it does not feel as “okay” 🤔

Google’s Adam Powell chimed in:

for me it’s down to how many places I need to jump around and look at to understand what something is doing

Eric De Wildt pointed out:

It’s hard to offer much advice with out understanding your code more intimately though.

Filip replied:

I was just interested in other people opinion on this and to be honest I didn’t expect so many people are fine with having big composable function as long as they do “one thing” (whatever that means). Whenever I have 150+ LOC long composable I start actively looking how to divide it because it feels really weird and cumbersome. Even if it does one thing, e.g. Screen component that just puts together other parts.

Eric continued:

XML got just as big and nobody said boo about it.

Eventually you have to realize that code is not perfect,

It’s designed by imperfect humans. Ideals are nice but being dogmatic about them is rarely practical.

Adam took issue with part of that:

I mean, a lot of people said boo about android layout xml, that’s how we got databinding and viewbinding and compose 😁

but the rest, yeah. If it communicates intent, it’s easy to test, it’s easy to maintain, and it performs well, it’s good code

This thread also contained an extensive discussion between Eric, Adam, and others regarding the nature of parameter lists to composables — be sure to check out the original thread!

---

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!