Does anyone else feel the need to post fix `Flow lt T gt ` c

Question

Does anyone else feel the need to post fix `Flow lt T gt ` class members with `Flow` ```class Server val notificationsFlow Flow lt Notification gt val notifications Flow lt Notification gt ``` Do people prefer `notifications` or `notificationsFlow`

Adam Powell · Answer

`notifications`

Dominaezzz · Answer

Yeah I feel like I m leaning that way now

chao · Answer

More importantly to stay consistent with the style in the codebase There can be cases like migrating from `LiveData` to `Flow` that we may have both `notificationsLiveData` and `notificationsFlow`

melatonina · Answer

Code like the following ```private val somethingMutableFlow = MutableStateFlow lt Something gt Something ZERO val somethingFlow StateFlow lt Something gt get = somethingMutableFlow var something by somethingMutableFlow private set``` is common for me

Erik · Answer

Unless there s a similar wrapper collection flow channel etc of the same type nearby I use `items` not `itemsFlow` If I have a mutable shared flow nearby then that s called `mutableItems` next to `items`

louiscad · Answer

Same question but with the type `Flow lt List lt Notification gt gt `

Erik · Answer

`notificationLists`

Erik · Answer

Note the s suffix which indicates that this is something wrapping lists wrapping notifications

Dominaezzz · Answer

For this very specific notification case I d probably go with `notifications` still It s all in the semantics I guess

ursus · Answer

notificationGrid

Oliver.O · Answer

`notificationBatches`

Oliver.O · Answer

In general I d say stay away from putting type names into variable names Put the purpose there Use type names as part of variable names as a last resort if they are the only differentiating factor type conversion scenarios

Erik · Answer

Sounds nice but depending on the practice by the developers using with the code it s not nice they might have to check manually for the type and therefore the interface they can use Inferred type hints are available in IDEs but not on e g GitHub So when reviewing code on such a platform it becomes more difficult to read Besides what does a batch even mean other than it being some kind of group What can I do with a batch What functions does it have Isn t that why we have well established words like collection set flow list etc In this case Kotlin s `List` interface clearly defines the contract gt A generic ordered collection of elements Sound like a good description of the the use case to me there s notifications and they re ordered No need for a new word like batch What if a future type `Batch` is introduced in your code base Then you d have to remember that `notificationBatches` is actually not a good name any more Admittedly the same applies to the `notificationLists` name if you d ever refactor to `Flow lt Collection lt Notification gt gt ` or something but that s a refactor directly on this variable s type so easier to see remember It s just the nature of refactoring So I stay by `notificationLists` if you re using and expecting flows by default or even `notificationListFlow` There s a strong type system for a reason use types explicitly either by specifying them or using them in the name if you rely on type inference

Oliver.O · Answer

Using the wrong tools for development is not an excuse I would easily accept these days Indeed the type system is there for a reason and its namespace is deliberately separate from that of variables Mix the two and you d end up with <https en wikipedia org wiki Hungarian notation> Batch in this case means exactly that A bunch of notifications no strings attached This is a contract with a sufficient but least specific promise Why imply ordering How do you know that s important for the use case at hand Maybe it s just an implementation detail maybe an array would do or some other `Iterable` Once you re exposing too much people will depend on it limiting your refactoring options

Erik · Answer

gt Why imply ordering The question was how to name `Flow lt List lt Notification gt gt ` so the `List` type and therefore the ordering of elements was imposed not implied

Erik · Answer

If that s not the intended behaviour then use a `Collection` or another wrapper type

Erik · Answer

Honestly but that might be my language barrier I m dutch a non native english speaker I don t understand what batch means other than what a word like collection set or list already describes very well at least on JVM

Erik · Answer

So for me the contract of batch is completely undefined whereas the contract of a list is perfectly well defined

Erik · Answer

In any case let s agree that naming is hard because there are many other cases we don t even want to discuss stuck out tongue

Oliver.O · Answer

I m a non native English speaker too German Your English might even be better than mine in many cases Dutch people beat Germans easily in that discipline +1 In this case we just cannot know if `List` is part of the implementation or the use site contract as all we have is a simple variable declaration So with respect to naming I went with as little implied coupling as possible Batch has a lesser meaning While in many cases that would not be a good thing in this case it s exactly what I intended slightly smiling face

Erik · Answer

Oh hi neighbour waving from afar left I still think that in idiomatic Kotlin as it s a high level language it pays to use types and their contracts to model intended behaviour usage So if you use a list you intend the list interface to be available to the users I think you said something similar in your previous comment So I guess we agree about that The question is if the type which holds intended behaviour information isn t clearly visible e g inferred then something else must tell the user that is you and your fellow code readers not the compiler in the case of Kotlin about the intended usage Therefore the name could I m not saying should reflect the type Yes that can lead to Hungarian notation But what else than a flow of lists of notifications is the type in question If you want it to behave and be used as a notification batch then create a type e g interface or alias `NotificationBatch` or something similar Then you can perfectly name the variable like you suggested And that would still be Hungarian notation wink

Oliver.O · Answer

Well I d say Hungarian would be to encode everything and the kitchen sink into the name And yes if `List` is what describes your purpose best then go with `notificationLists` Once we had really figured out the true intention of the example we might actually agree on naming smile

ursus · Answer

I have this dillemma with my Dao s when I have a `val foo Flow lt Foo gt ` but also a suspend function which selects foo 1 time as normal how to call this `loadFoo ` `findFoo ` or other way around call the flow `fooFlow` and `foo ` for the suspend function

Erik · Answer

My two cents DAOs basically expose CRUD db operations so what about using verbs like create read update and delete And then names for some cases `suspend fun readFoo Foo` `fun readFoos Flow lt Foo gt ` And otherwise I don t think it s too bad to just name them `fooFlow` and `foo` Or maybe even name the flow just `foos`

Oliver.O · Answer

And another 2 cents Do not use `loadFoo ` `findFoo ` `readFoo ` as these names would imply something imperative not returning a value So go with `private val foo Flow lt Foo gt ` and `suspend fun foo Foo` See <https kotlinlang org docs coding conventions html choose good names|Choose good names> an underestimated chapter in the Kotlin coding conventions I know this case is less than ideal and a suspending `get ` looks preferable but its not there yet That a function and property exist side by side serving the same purpose is really just an implementation artifact There is no perfect naming solution to overcome this There should ideally be just one thing

ursus · Answer

ive only seen underscore in private vals youd put them public i d find that odd

Oliver.O · Answer

No I would not See above `private val foo Flow lt Foo gt ` If you really need both in public the accessor function and the variable I would reconsider the design While I would not blindly adapt the design for the sake of naming in my experience problematic designs often manifest themselves in naming difficulties Your mileage may vary but that s what I would look at

ursus · Answer

Well can you add your opinion Its a Dao wrapping database contains ways to read and write data + some queries are observable flows how would you design it

Oliver.O · Answer

I guess I d need more details about your use case for that Can you point to a GitHub gist or something

ursus · Answer

something like this ```interface FooDao fun foos Flow lt List lt Foo gt gt fun fooByIdFlow id Strong Flow lt Foo gt suspend fun fooById id String Foo suspend fun saveFoos foos List lt Foo gt ``` and its implementation is driven by sqldelight for example

Oliver.O · Answer

DAOs are less than ideal in general so I d avoid that approach I d probably go with something lightweight ORM like otherwise I might lean towards something like the following and use one abstraction for the storage database subsystem In the end it would all depend on the use site needs number of classes involved and so on but hopefully you get the idea ```import kotlinx coroutines flow import kotlinx coroutines class Foo id String name String sealed class FooCriteria object All FooCriteria class Id value String FooCriteria class Name value String FooCriteria interface Storage fun foos criteria FooCriteria Flow lt Foo gt suspend fun addOrUpdate foos Iterable lt Foo gt fun storage Storage = TODO fun main = runBlocking storage foos FooCriteria All collect println it storage foos FooCriteria Id 23 collect println it ```

ursus · Answer

Hmm I don t follow You d rather spread ORM imports all over the code rather than hiding the ORM behind the DAO interface Also looking at the sample that looks like my Dao just renamed to Storage unless im missing something Or is the trick in the Criteria abstraction

Oliver.O · Answer

`Storage` in this case is your entire database not a single object s persistence API As the above interface does not even have to be a database could be flat file or whatever it is named just `Storage` There is really no special trick involved In the end it is more about choosing the right abstraction A DAO is just a name for a bunch of functions without clear boundaries Storage or more specific database is a better understood abstraction you can almost instantly visualize it And yes I would not care spreading ORM imports that would not be a factor if the ORM is the proper abstraction Keep in mind that all of this is mostly about how you think about stuff how easily you can understand it initially and then pick it up again after a 6 month pause The perception also changes depending on what you are used to You may not follow if you were used to a different set of abstractions In that case the quality would show if you try to introduce those abstractions to new people unfamiliar with the chosen concepts