Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Rewrite function signature rule #1341

Closed
paul-dingemans opened this issue Jan 22, 2022 · 0 comments · Fixed by #1459
Closed

Rewrite function signature rule #1341

paul-dingemans opened this issue Jan 22, 2022 · 0 comments · Fixed by #1459
Assignees
Labels
Milestone

Comments

@paul-dingemans
Copy link
Collaborator

paul-dingemans commented Jan 22, 2022

The Kotlin and Android code guidelines are more or less specific about how to write a function signature

From Android Coding style guide (https://developer.android.com/kotlin/style-guide#functions):

When a function signature does not fit on a single line, break each parameter declaration onto its own line. Parameters defined in this format should use a single indent (+4). The closing parenthesis ()) and return type are placed on their own line with no additional indent.

fun <T> Iterable<T>.joinToString(
    separator: CharSequence = ", ",
    prefix: CharSequence = "",
    postfix: CharSequence = ""
): String {
    // …
}

Although the Kotlin style guide is less specific about this topic (https://kotlinlang.org/docs/coding-conventions.html#functions) it boils down to the exact same format for multiline signatures.

The idea is to create a new rule that determines whether the function signature fits on a single line (with respect to the max_line_length) and if so, it rewrites the function signature to a single line. If the function signature does not fit on a single line, it will be formatted as shown in example before.

The concept of this rule is already working on my local machine. Known limitations so far:

  • Function signatures which contain inline comments (both block and EOL comments) are ignored as it is merely impossible to decide how such comments needs to be handled. Also the comments can be placed at really weird positions from which I hardly can imagine why somebody would do so. Example:
            private /* some comment */ fun f1(a: Any, b: Any): String = "some-result"
            private fun /* some comment */ f2(a: Any, b: Any): String = "some-result"
            private fun f3 /* some comment */ (a: Any, b: Any): String = "some-result"
            private fun f4( /* some comment */ a: Any, b: Any): String = "some-result"
            private fun f5(a /* some comment */: Any, b: Any): String = "some-result"
            private fun f6(a: /* some comment */ Any, b: Any): String = "some-result"
            private fun f7(a: Any /* some comment */, b: Any): String = "some-result"
            private fun f8(a: Any, b: Any) /* some comment */: String = "some-result"
            private fun f9(a: Any, b: Any): /* some comment */ String = "some-result"
            private fun f10(a: Any, b: Any): String /* some comment */ = "some-result"
            private fun f11(
                a: Any, // An EOL comment at this place is a bit weird because it is place after the comma. From a parser perspective it seems to belong to parameter "b" instead of "a"
                b: Any
            ): String = "f10"
  • When max_line_length is not set, the function signature will not be rewritten to a single line as that could result in really long and unreadable lines.

One thing that I am doubting about is whether this rule should be made configurable a bit. Not in all cases I would like to have my function be rewritten automatically. For example, I do see no real harm in having a function with two parameters to be written on a single line if it first. Starting from 3 parameters, I would dislike it. So I would like to add a configuration setting for this rule which defines that a function signature will be forced to a multiline signature if the function has too many parameters for a single line function signature. By default this configuration setting will be empty and allow an unrestricted number of parameters.

Before this rule can be launched, I need some other rules which are fixing a few unhandled spacing issues in the function signature. I will raise a separate PR for each indivual rule.

@paul-dingemans paul-dingemans self-assigned this Jan 22, 2022
paul-dingemans pushed a commit to paul-dingemans/ktlint that referenced this issue Jan 22, 2022
paul-dingemans pushed a commit to paul-dingemans/ktlint that referenced this issue Feb 5, 2022
This rule lints and format the spacing between modifier in and after the last modifier
in a modifier list.

This rule is required to create a rule which can rewrite the function signature
automatically as is described in pinterest#1341
paul-dingemans pushed a commit to paul-dingemans/ktlint that referenced this issue Feb 5, 2022
Lints and formats the spacing after the fun keyword.

This rule is required to create a rule which can rewrite the function signature automatically as is described in pinterest#1341
paul-dingemans pushed a commit to paul-dingemans/ktlint that referenced this issue Feb 9, 2022
Autocorrect is not implemented. This is an error which only
happens rarely. Its value is that it makes implementation of
some rules way easier when comment do not have to be taken
into account.

Initial implementation just contains one single discouraged
location. More will follow when implementing the rule to
rewrite the function signature automatically as is described
in pinterest#1341.
paul-dingemans pushed a commit to paul-dingemans/ktlint that referenced this issue Feb 9, 2022
…eter list in a function signature

This rule is required to create a rule which can rewrite the function signature automatically as is described in pinterest#1341
paul-dingemans added a commit that referenced this issue Mar 8, 2022
This rule is required to create a rule which can rewrite the function signature automatically as is described in #1341
paul-dingemans added a commit that referenced this issue Mar 9, 2022
This rule lints and format the spacing between modifier in and after the last modifier
in a modifier list.

This rule is required to create a rule which can rewrite the function signature
automatically as is described in #1341
paul-dingemans added a commit that referenced this issue Mar 9, 2022
Lints and formats the spacing after the fun keyword.

This rule is required to create a rule which can rewrite the function signature automatically as is described in #1341
paul-dingemans added a commit that referenced this issue Mar 9, 2022
Autocorrect is not implemented. This is an error which only
happens rarely. Its value is that it makes implementation of
some rules way easier when comment do not have to be taken
into account.

Initial implementation just contains one single discouraged
location. More will follow when implementing the rule to
rewrite the function signature automatically as is described
in #1341.
paul-dingemans added a commit that referenced this issue Mar 13, 2022
…eter list in a function signature (#1366)

Rule op-spacing should not handle characters like '<', '>' and '*' when not used as operator. This logic is moved to the TypeParameterListSpacingRule and new rule TypeArgumentListSpacingRule. 

This rule is required to create a rule which can rewrite the function signature automatically as is described in #1341
paul-dingemans added a commit to paul-dingemans/ktlint that referenced this issue Mar 13, 2022
…n function name and the opening parenthesis

Includes cleanup of AnnotationSpacingRuleTest as it broke due to
existence of test which was not related to annotation spacing.
Also removed the unneeded blank final line in code examples
which are linted and formatted.

This rule is required for implementing the function signature rewrite rule pinterest#1341
paul-dingemans added a commit to paul-dingemans/ktlint that referenced this issue Mar 15, 2022
This rule is required for implementing the rewrite function signature rule pinterest#1341
@paul-dingemans paul-dingemans added this to the 0.46.0 milestone Mar 17, 2022
paul-dingemans added a commit to paul-dingemans/ktlint that referenced this issue Mar 18, 2022
…rn type of a function

This rule is required for implementing pinterest#1341.
paul-dingemans added a commit to paul-dingemans/ktlint that referenced this issue Mar 19, 2022
…t of the body expression or body block

This rule is required for implementing pinterest#1341.
paul-dingemans added a commit to paul-dingemans/ktlint that referenced this issue Mar 20, 2022
…le type

Required for implementing the signature rewrite rule (pinterest#1341)
paul-dingemans added a commit that referenced this issue Apr 26, 2022
Enforce consistent spacing (e.g. no whitespace element at all) between function name and the opening parenthesis

This rule is required for implementing the function signature rewrite rule #1341
paul-dingemans added a commit that referenced this issue Apr 26, 2022
* Add new experimental rule ParameterListSpacingRule

This rule is required for implementing the rewrite function signature rule #1341
paul-dingemans added a commit that referenced this issue Apr 26, 2022
…rn type of a function (#1422)

* Add new experimental rule to check consistent spacing around the return type of a function

This rule is required for implementing #1341.
paul-dingemans added a commit that referenced this issue Apr 26, 2022
* Add new experimental rule to check consistent spacing before the start of the body expression or body block

This rule is required for implementing #1341.
paul-dingemans added a commit that referenced this issue Apr 26, 2022
* Add new experimental rule which prohibits whitespaces inside a nullable type

Required for implementing the signature rewrite rule (#1341)
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant