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.

I would like some suggestions for how to name the states associated with a statemachine that controls my user interface my prefered solution would be to have a set of names that describe most screen states a user interface can take on during interaction with a user. in addition i would like the names to be one word (if possible) and singular (i do not like plural names) some screen states that are easy to identify are EMPTY, BUSY, SUCCESS, & ERROR, which would make sense for any UI, however I am struggling for names that describe the first screen presented, e.g. when a user navigates to a screen and has not actually interacted with it yet, maybe INITIAL, OPENING, BEGINING, INTRODUCTION. also theres the issue that some of these states (names) overlap, for example SUCCESS and whatever you want to name the first screen state the user sees are one and the same. if i use SUCCESS for both scenarios it feels "odd" as the user hasnt interacted with the screen when navigating to it for the first time yet they are in the state of SUCCESS. am i over thinking it?

How would you name a read-only type whose mutable version already has a basic name? Specifically, we have some

VecX

types that are mutable vectors, and I'm struggling to find a name for a new read-only Vector type that they should implement. I'm thinking maybe

ReadOnlyVecX

but it seems to be too long. The issue is that changing the name of

VecX

to

MutableVecX

would be a big change, especially considering that most Vec-based code would be using mutability, while the read-only versions likely will be used to specify that method parameters and results can't be modified. I also thought maybe

VecXVals

could be an apt name since the interface would really only define the `val`s required to represent that vector, but it still doesn't seem elegant enough

Hi everyone, does anyone have insight in to the reason behind capitalized function names in Compose? It's a style that has grown on me, and I'm starting to use it for factory functions in my own (non-compose) code, but I don't want to break style conventions for the wrong reason.

The general consensus of naming convention in Java (and Kotlin) for interfaces is to add -able to the end of the proposition. e.g. Composable, Iterable, etc. We are dealing with data objects that may or may not have a range in which it resides. e.g. a diagnose can have a start and an end date. Rangeable isn't a proper word, neither are periodable and other suggestions. I can't find if the proper naming convention thinks this is a good idea anyway. Any suggestions?

Is there any reason for this inspection that was added to the 2023.2 Intellij EAP? It's a relatively common convention to use

PascalCase

for constants instead of

SCREAMING_SNAKE

How should units in variable names be handled? Often, casing changes the meaning significantly. A variable currentLimitMA technically implies that the current limit is in mega-amps, which is very different from the likely intended milli-amps. I really don't like currentLimitmA, since it makes word boundaries unclear.

In enums, its a convention to use SCREAMING_SNAKE_CASE, which I totally agree with. However, in the process of making an enum typesafe, we have opted to rewrite it using sealed classes. Now, this sealed class with sealed children with objects is basically just a 'better' enum. writing the object with SCREAMING_SNAKE_CASE is not seen as best practice, but I feel like, in these cases, it should. Anyone agree/disagree?

naming -Manager, -Helper, -Factory is not good? My coworker said don't use it. And I don't understand because google also uses those names. And personally, I think those names are fine.

Is there any strong opinion for Compose components to be named like

PrimaryButton / SecondaryButton

instead of

ButtonPrimary / ButtonSecondary

?

Hello! Apologies if this is a stupid question. Is there guidance for how to name something that conflicts with a language name / type? For example, I’m writing some code that handles measurements and units, and converting between units. Do I just name something “Unit,” and resign myself to writing

kotlin.Unit

to disambiguate?

Hi, I'm looking for some feedback on a couple of naming changes I'm currently considering for some of my libraries. Please also take into consideration that this is completely used from Java too. (I would also be interested to hear if this affects your stance on naming.) I believe that the new names are more conventional but I'm biased because I'm used to the old notation. So I would love to get some opinions: • Replaced occurrences of 🅰️

ID

in identifiers with 🅱️

Id

. • Renamed 1️⃣

NPCText

,

PoI

(point of interest), and

PvPGame

to 2️⃣

NpcText

,

Poi

, and

PvpGame

respectively. Thanks 🙂

I have a hard time naming the samples GitHub repository of "Compose O'Clock". FYI, Compose O'Clock is library to make Watch Faces for Wear OS using Compose Canvas and runtime. Compose O'Clock itself is not open source (but it's free to use in debug apps), so the repo will be essentially a README and possibly a few other doc markdown files. What would make the most sense to you? 1. Make a public repo named "ComposeOClock-samples", with samples AND the doc 2. The same, but named just "ComposeOClock" 3. Make a public repo named "ComposeOClock" that contains only the doc, AND another one named "ComposeOClock-samples" for the samples

Any better name than KacheableImpl here: https://github.com/dave08/kacheable

I already have an interface with Kacheable as a name...

What would you call a feature that blocks access to URL’s until a person has gone through an OTP authorization process?

Got a composable function whose purpose is to take as much space as the content that is being passed into it. However I do not want it to draw that content. I only need it for the size aspect of it. It then can render something in that space using it’s modifier. Here is the implementation

@Composable
fun Foo(
  modifier: Modifier = Modifier,
  content: @Composable BoxScope.() -> Unit,
) {
  Layout(content = { Box { content() }, modifier = modifier) { measurables, constraints ->
    val placeable = measurables.first().measure(constraints)
    layout(placeable.width, placeable.height) {}
  }
}

How would you name this Layout function? 👀

Naming question for Compose: we all know that Components should be small, reusable and single-purpose and Screens should be the top-level entry point which mostly just sticks Components together. But do we have a convention in-between for sub-screens which might just be a few Components and are related enough to extract to a (private) function but neither full Screens nor reusable. Example would be an Empty state for a List which is just Image + a few Texts. My first thought was that this would also be a Screen but not sure how strictly we should interpret that definition of Screen (can't find any docs from Google that clarify this)

Is it: 1. inline value class 2. inline class 3. value class ? Sounds like 1. is the official term but it's also very long and the doc mostly uses 2. but the code itself is mostly 3. Any preference?