kotlin:S107 should ignore methods with @Composable annotation

SonarQube Server / Community Build
,
1

Using : SonarQube™ - Enterprise Edition - Version 9.9 (build 65466)
Language : Kotlin
Rule: S107 ( Functions should not have too many parameters).

Expectation:
Methods annotated with @Composable (androidx.compose.runtime.Composable) should be ignored for this rule.

Composable tend to have a lot of parameters and it is by design. It is pretty trivial for composables to have more than 7 parameters, as all values (states, event callbacks, and the content of the child composables) are passed down from parent to child.

Example:

@Composable
fun HazeScaffold(
  modifier: Modifier = Modifier,
  topBar: @Composable () -> Unit = {},
  bottomBar: @Composable () -> Unit = {},
  snackbarHost: @Composable () -> Unit = {},
  floatingActionButton: @Composable () -> Unit = {},
  floatingActionButtonPosition: FabPosition = FabPosition.End,
  containerColor: Color = MaterialTheme.colorScheme.background,
  contentColor: Color = contentColorFor(containerColor),
  contentWindowInsets: WindowInsets = ScaffoldDefaults.contentWindowInsets,
  hazeState: HazeState = remember { HazeState() },
  blurTopBar: Boolean = false,
  blurBottomBar: Boolean = false,
  content: @Composable (PaddingValues) -> Unit,
) {
    // Method body...
}

This is an example sourced from Chris Banes’s tivi project.

4

Hi @jayasuryat,

Thank you for reporting!

I had the same thought at first, but after an investigation, I found it is considered bad practice.
More resources are available here: Android Developers - Thinking in Compose.

All the best,

Irina

6

Hi

Just to give some more information
I don’t think it’s a really bad practice, when we watch the video of android developer they say that we must simplify the compose function to be understand (api)

But we have some cas in android like the sample of Jaya where we must given all the parmeters necesseray to custom the view ( style, color, etc…).

In consequence we can have many parameters in this function some times

For sample, I want to wrap a TextEdit for some behavior(UI) but keep the custom ui purpose by google, for an library component.

When you watch the composable provide by android you can watch many parameters available in.

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun TextField(
    value: String,
    onValueChange: (String) -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    readOnly: Boolean = false,
    textStyle: TextStyle = LocalTextStyle.current,
    label: @Composable (() -> Unit)? = null,
    placeholder: @Composable (() -> Unit)? = null,
    leadingIcon: @Composable (() -> Unit)? = null,
    trailingIcon: @Composable (() -> Unit)? = null,
    prefix: @Composable (() -> Unit)? = null,
    suffix: @Composable (() -> Unit)? = null,
    supportingText: @Composable (() -> Unit)? = null,
    isError: Boolean = false,
    visualTransformation: VisualTransformation = VisualTransformation.None,
    keyboardOptions: KeyboardOptions = KeyboardOptions.Default,
    keyboardActions: KeyboardActions = KeyboardActions.Default,
    singleLine: Boolean = false,
    maxLines: Int = if (singleLine) 1 else Int.MAX_VALUE,
    minLines: Int = 1,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    shape: Shape = TextFieldDefaults.shape,
    colors: TextFieldColors = TextFieldDefaults.colors()
) {

Regards

Florian.

7

Hi Irina, android compose components implemented as below, but sonar rules force us to write less parameters and less function content, can you please consider evaluate to arrange for composable ?

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material/material/src/commonMain/kotlin/androidx/compose/material/Scaffold.kt;l=177?q=file:androidx%2Fcompose%2Fmaterial%2FScaffold.kt%20function:Scaffold

9

Hi @bariscan_kizir and welcome to the community.

We acknowledge that the rule does not make much sense for methods with @Composable annotation. We want to change the rule behavior by either adding an exception for such methods or by having a separate threshold.

We will update this thread once the change is released.

Pierre-Loup

14

Hi Pierre-Loup!

We’re also affected by this issue and are very interested in seeing it resolved. Thanks for looking into it and acknowledging the limitation with the current rule.

Do you have any updates or an estimated timeline for when this change might be released?

Looking forward to hearing more.

Radu

15

Hi Pierre-Loup!

Do you have any updates on this issue?

16

Hi @RaduPrescura,

It will probably be in the next release of our Kotlin Analyzer but I don’t have a timeline to share at this point, sorry.

Regards,

17

Hello,

was this included in a recent version of the Kotlin Analyzer?

18

Hi @MGaetan89,

Welcome to the community!

If you’re on SonarQube Cloud or using a current version self-hosted, then you should have this.

You’ve resurrected a topic that’s 5 months old. Per the FAQ, please don’t do that in the future.

 
Thx,
Ann