Is there any call-site parameter ordering standard imposed by google? I am seeing different styling ...

# compose-android

[Lucas Kivi]

Is there any call-site parameter ordering standard imposed by google? I am seeing different styling between foundation code and material3 code. Mainly I am concerned with where the modifier should be. Seems like there are two options:
1. Always at the end
2. Wherever it exists in the signature of the function

// signature
fun UiStuff(
    mandatoryState: MandatoryState,
    modifier: Modifier = Modifier,
    optionalState: OptionalState = OptionalState.A,
    content: @Composable () -> Unit = {},
) { ... }

// call-site option 1
UiStuff(
    mandatoryState = MandatoryState.A,
    optionalState = OptionalState.A,
    modifier = modifier
        .background(...)
        .border(...)
        .androidPixyDust(...),
) {
    // Content
}

// call-site option 2
UiStuff(
    mandatoryState = MandatoryState.A,
    modifier = modifier
        .background(...)
        .border(...)
        .androidPixyDust(...),
    optionalState = OptionalState.A,
) {
    // Content
}

[Lucas Kivi]

I personally prefer option 1 so that the invocation isn’t broken up by the indentation.

[Stylianos Gakis]

https://android.googlesource.com/platform/frameworks/support/+/androidx-main/compose/docs/compose-api-guidelines.md#elements-accep[…]ifier-parameter

Element functions MUST accept a parameter of type Modifier. This parameter MUST be named “`modifier`” and MUST appear as the first optional parameter in the element function’s parameter list. Element functions MUST NOT accept multiple Modifier parameters.

Focus on the MUST appear as the first optional parameter part.

[Stylianos Gakis]

And later:
“Modifiers occupy the first optional parameter slot to set a consistent expectation for developers that they can always provide a modifier as the final positional parameter to an element call for any given element’s common case.”

[Lucas Kivi]

so common case means without optional parameters?

[Lucas Kivi]

Because, like I said, I have seen inconsistency with how google does this. This makes me think there is some distinction between the signature definition guidelines and the callsite guidelines.

[Stylianos Gakis]

I just realized you said “call-site parameter ordering”.
I don’t think there’s a de-facto standard for what happens on the call-site to be honest.
Do whatever makes you feel better is probably the suggestion 😄

[Stylianos Gakis]

common case means without optional parameters

They are optimizing the API to be called normally without named parameters in the “common” cases, which is with all the default parameters left as-is. So I suppose what you are saying here is true.

[Lucas Kivi]

Ok got it. Hahaha I was hoping you would just tell me what is right so I could move on with my life 🤣

[Lucas Kivi]

Option 1 it is 😉

[Stylianos Gakis]

Yeah I also like having some sane “Just do this by default” guidelines, to avoid bikeshedding (until I hate that default 😅). But I unfortunately think there are none for this case 😄

[Stylianos Gakis]

FWIW I also typically go for option 1 too

[Zach Klippenstein (he/him) [MOD]]

Yea I don’t think we care what order you use if you’re specifying param names