Shouldn't this be #nomenclature ?

@yschimke actually we could have called it nominatio.

Let's keep it simple 🙂

Yeah I also vote for calling it #simple 😄

Hello, my name is Louis Cognault Ayeva Derman, but it's too long, so just keep it simple and call me Louis CAD. Thank you.

Love acronyms BTW.

Oh, so the whole time it was just about how to name Louis, I see

😅 I like the coincidence, as I already had a naming question today. We currently try to split up our composables into container (with viewmodel) and stateless view. In this example the container is suffixed with

Route

- which I do not like. I also do not like to suffix the view with

View

- as this term is really overloaded on Android. Any suggestions?

I could use some help in naming this thing. It is a mutable, stateful object. It will keep growing in size and responsibilities for many years to come. It's current primary function is converting formula to excrement, but hopefully it will get better capabilities soon. The first version is called Cassandra, but we haven't come up with a name for this one yet.. 😬

What is your preferred nomenclature for two functions that do the same thing, but one mutates the object, whereas the other returns a new object?

This may not be strictly naming related, but when you read the :: syntax in kotlin (such as checking ::myVar.isInitialized or passing a method reference to a function), how do y’all pronounce it in your head?

Compose related one. In a composable function body, composition could happen when the function is called again with new input parameters or composition could happen from mutableStateOf(state) declare in the body itself. I find my self referring to it as

external triggered composition

and

internal triggered composition

respectively. Any one else using these terms or just not distinguish between the 2? Perhaps

input parameter triggered

vs

internal state triggered

Love this channel! 🐕

Hey there! Has someone also stumbled over how

iosSimulatorArm64()

,

iosX64()

and

iosArm64()

are named? •

iosArm64()

is for a device •

iosX64()

is for a simulator •

iosSimulatorArm64()

is for a simulator How could we name these better?

Please tell me best way to name ids in android xml? Thanks

it's a wrapper for db transactional operations

internal inline fun <T> runRecoveringTransaction(transaction: () -> T?): T? {
    val result = runCatching { transaction() }
    return result.getOrElse {
        if (it is DataIntegrityViolationException) return null else throw it
    }
}

any suggestions for better name? •

recoverTransaction

-> i think it's a bit generic •

ifRollbackReturnNull

-> a bit weird?

I'll so gonna use this channel when we'll have the next baby 😁

What's everyone's take on the classic "naming a library a word with C's replaced with K's"? 1️⃣ : It's getting old 2️⃣ : I'm still krazy for it! 3️⃣ : Indifferent/it depends

I find myself writing a lot of repetitive code like this:

return try {
    // ...
} catch (e: Exception) {
    handleError(e)
}

in some classes that have similar purposes. so, I decided to extract that block into a separate function called something like

runCatching

return runCatching { ... }

but the problem is that it would be easily confused with the standard

kotlin.runCatching

, and I'm not using

kotlin.Result

either. so, I want a good name for that function but I can't think of any name other than

runCatching

. Any better ideas?

Hello folks, in case i have a function which checks for a precondition based on authorization access should i postfix it with

orThrow

or it's ok to omit it? For example:

private val CspAccount.retrieveAuthenticatedDevice: CspDevice
    get() = this.authenticatedDevice.getOrElse {
        throw WebApplicationException(
            "Authenticated device for account: ${this.number} was not found",
            Response.Status.UNAUTHORIZED
        )
    }

It would be better if i renamed it to getAutheticatedDeviceOrThrow()? Thanks in advance for any answers !

if you guys were to have a module for cough utility methods (extensions and what not), what would you call it? I'm really trying to avoid calling it a utility module because I feel like that would be like opening a dumping ground. I'm on the fence with

language-support

as in adding things the language doesn't offer but perhaps could.

Made this function, but I feel like the name (and possibly the signature) can be improved. I use this alot (e.g.

foos.find { it.id == id }

) so this is nice sugar for me (used like

foos.findBy(id) { it.id }

):

inline fun <T, R> Iterable<T>.findBy(key: R, selector: (T) -> R): T? = find { selector(it) == key }

Maybe rename to just

find

?

findIn

?

Naming is HARD https://twitter.com/depthsofwiki/status/1614045362985082881?s=20&t=DLVlqH70jPPCM26_QyXEHA

What’s the right name for this function? It’s like

fold

, but the

operation

is allowed to return

null

, in which case the whole thing exits early with a

null

return value.

private inline fun <T, R> Iterable<T>.fold2(initial: R, operation: (acc: R, T) -> R?): R? =
    fold<T, R?>(initial) { acc, element -> operation(acc ?: return null, element) }

We’ve recently cleaned up our authentication token logic and now got a centralized place (let’s call this AuthenticationService) where we know we’re here logging in, hence storing a token and refresh token, and a logout method which clears these tokens. In our “log out” case, we got a log out usecase, which basically goes ahead and manually clears some caches and stuff, and then finalizes by calling this log out function which finally clears the tokens. We call that log out function manually when the user simply clicks on a button. Now here comes the situation, where we also want to perform this log out logic when they are logged out through other means, like the tokens expire and so on. So I was thinking maybe this is a place to invert how this works, and instead of the log out usecase doing everything and then clears the tokens, it should instead call this AuthenticationService, which will clear the token and then after it’s done it should trigger an event of “Hey I am now logged out”. The idea is that then, other modules who don’t need to to know too much about these modules, just need to be aware of some interface which may be named like

interface AuthenticationListener {
  suspend fun loggedIn()
  suspend fun loggedOut()
}

This will be in a common module without more dependencies, and whichever module is interested can provide implementations of this interface to do stuff that it may need to do on login or logout. Then there should be some class which is called ??? Let’s just say

AuthenticationEventDispatcher

for now

class AuthenticationEventDispatcher(
  authenticationListeners: Set<AuthenticationListener>, // injected
  applicationScope: ApplicationScope,
  coroutineContext: CoroutineContext,
) {
  private val authEvents = Channel<AuthenticationEvent>(Channel.UNLIMITED)
  init {
    applicationScope.launch(coroutineContext) {
      authEvents.consumeAsFlow()
        .collect { event ->
          authenticationListeners.map { authenticationListener ->
            async { when (event) { LOGGED_IN -> authenticationListener.loggedIn(); LOGGED_OUT -> authenticationListener.loggedOut() } } 
          }.awaitAll()
        }
    }
  }
  fun loggedIn() { authEvents.trySend(LOGGED_IN) }
  fun loggedOut() { authEvents.trySend(LOGGED_OUT) }
  private enum class AuthenticationEvent { LOGGED_IN, LOGGED_OUT }
}

Which should just take these events and inform all the AuthenticationListener instances to do whatever it is that they’re gonna do (One example is that I want to get a member ID when logging in from the backend and save it, but this only works after having logged in first) So with all this context, how would you better name “AuthenticationEventDispatcher” or even the “AuthenticationListener” which I am also not happy about?

Any opinion on prefixing

Flow<Boolean>

with "is". E.g.

val isVisible: Flow<Boolean>

?

what is the best (or just shorter) name for this

fun Set<A>nonEmptyIntersection(other: Set<A>) = this.intersect(other).nonEmty()

?

Hey, all. What are your naming conventions for suspending variations of non-suspending functions? •

doThing()

◦

doThingAsync()

◦

doThingSuspending()

◦

doThingSuspended()

◦ etc?

Small thing that is itching me. It's

JSON

and not

Json

, right? I've been using

Json

everywhere but I think I'm wrong?

What should be the name for a class which builds something but is not really implementing

Builder

pattern. You simply have one method

Foo.build(param)

in the class interface which gives you the instance. Such classes use some other builder hierarchy by feeding received configurations in

param

and gives you concrete instance, IE, abstracting away builder logic. For instance, I have a custom notification builder class which is using

NotificationCompat.Builder()

internally and giving

Notification

instance on invocation.