[Clean Architecture] The function has too many parameters warning

[9Realms-Zwl]

nowinandroid/feature/bookmarks/src/main/kotlin/com/google/samples/apps/nowinandroid/feature/bookmarks/BookmarksScreen.kt

Line 104 in 4277366

internal fun BookmarksScreen(

"This function has 9 parameters, which is greater than the 7 authorized."

When working with the Compose function, you will notice that the number of parameters in the function is very large. After SonarQube detection, the function is marked with a Code Smell at the MAJOR level. The levels are CRITICAL, MAJOR, MINOR, INFO, in that order.

Question: Is there a good way to fix this code smell?

Solutions that come to mind so far:

1. Change the minimum number for this rule
2. Solve by passing a sealed interface, for example
3. more coming soon

example
// defined event types
sealed interface Event {
  data class RemoteFromBookmark(val markId: String): Event
  data class OnNewsResourceViewed(val newsId: String): Event
  data class OnTopicClick(val topicId: String): Event
  data object UndoBookmarkRemoval: Event
  data object ClearUndoState: Event
}

/*
@Composable
internal fun BookmarksScreen(
    feedState: NewsFeedUiState,
    onShowSnackbar: suspend (String, String?) -> Boolean,
    removeFromBookmarks: (String) -> Unit,
    onNewsResourceViewed: (String) -> Unit,
    onTopicClick: (String) -> Unit,
    modifier: Modifier = Modifier,
    shouldDisplayUndoBookmark: Boolean = false,
    undoBookmarkRemoval: () -> Unit = {},
    clearUndoState: () -> Unit = {},
) 
*/
@VisibleForTesting(otherwise = VisibleForTesting.PRIVATE)
@Composable
internal fun BookmarksScreen(
    feedState: NewsFeedUiState,
    onShowSnackbar: suspend (String, String?) -> Boolean,
    modifier: Modifier = Modifier,
    shouldDisplayUndoBookmark: Boolean = false,
    onEvent: (Event) -> Unit = {},
)

[dturner]

I mean, "code smell" is the opinion of SonarQube static analysis which we do not use in this project. Admittedly, BookmarksScreen does have a lot of parameters and they are inconsistently named so definitely room for improvement.

Your proposed sealed interface solution is MVI, and while it may be appropriate for this one function, if it was implemented consistently across the entire codebase it would add a lot of unnecessary complexity.

Happy to accept a pull request that renames the lambda parameters so that they are all prefixed with on.

[SimonMarquis]

This looks like a chatgpt-like bot...