hi is there any convention I should follow when I ...

# codingconventions

[david.bilik]

hi is there any convention I should follow when I want to name a function that returns Flow type? eg. im observing users from database, should i name it like

fun users() : Flow<List<User>>
or
fun observeUsers() : Flow<List<User>>
or
fun usersChanges() : Flow<List<User>>
or 
fun getUsersStream() : Flow<List<User>>

?
There is a lot of options and im curious about the best practices

[sindrenm]

We're currently using getUsersFlow . Whether it's a well-used convention, I don't know.

[Marc Knaup]

I avoid calling anything get as it’s mostly redundant in Kotlin and rarely used.

userFlow() or simply users() would be fine imo 🙂

[sindrenm]

I like verbs in functions.

[Marc Knaup]

If it doesn't create a new flow but always returns the same it could be a val.
If I need a verb, for example for API calls, I prefer "fetch" and "retrieve" over "get". The latter is mostly used for getters and usually simple behavior with almost no side effects are assumed.

[sindrenm]

Not gonna argue with you there.

[Orhan Tozan]

I think it depends. If it really represents a simple stream, users() is what I would use, however, when there is some initial loading going like an initial overhead, I would call it observeUsers()

[Orhan Tozan]

Calling it users() should be the same, regardless how often I call it in a row

[david.bilik]

i’ve used observeUsers in the past as well (with Rx) but now when I thought about it it does not make sense - the method is not observing anything, its returning me the observable. I am observing the result that the method will return me. I went with getUsersStream approach

[Marc Knaup]

It’s not really a user stream though. That would be Flow<User>.
The plural “users” doesn’t make it much better imo as it’s easy to miss and not every word has a plural “s”, so consistency is difficult.

It could be either a “user list stream” or “user list state”.

I associate “stream” with something that keeps appending new data as it becomes available.
The Flow<List<User>> more likely emits a completely new list every time that replaces the previous list. Hence “state”.