Skip to content

Discussion: when should we split parameters, modifiers and return types in multiple lines? #474

@fvictorio

Description

@fvictorio

Previous discussions: #139, #256, #454.

Before releasing a stable version of Prettier Solidity, we should decide what we want to do with respect to long function signatures. This is by far the most contentious issue, and chances are we won't make everyone happy. But I would like to, at least, get as many opinions as possible.

Right now, if I recall correctly, we split if there are more than two parameters/modifiers/return types. I personally don't like this approach, and I think it's not consistent with what prettier core does.

An alternative more similar to what prettier does (with long typescript functions) is to split the parameter lists first and then the modifiers list.

The return types are not treated different than a modifier with several arguments, so the question is what happens if they are too long (or if a modifier has a looot of arguments). For example:

function foo () modifier1 modifier2(aVeryLongArgument) returns (AVeryLongType, AnotherVeryVeryVeryVeryLongType)  {

An analogue situation in typescript is this:

function foo(): [[number, number, number, number, number], number, number] {}

and prettier does this:

function foo(): [
  [number, number, number, number, number],
  number,
  number
] {}

or, if the array doesn't fit, this:

function foo(): [
  [
    number,
    number,
    number,
    number,
    number
  ],
  number,
  number
] {}

So, using that as a guide, that solidity function should be formatted like this:

function foo ()
  modifier1
  modifier2(aVeryLongArgument)
  returns (AVeryLongType, AnotherVeryVeryVeryVeryLongType)  {

and, if the return types or a modifier have too many arguments/types, we split them further:

function foo ()
  modifier1
  modifier2(aVeryLongArgument)
  returns (
    AVeryLongType,
    AnotherVeryVeryVeryVeryLongType
  )  {

An unfortunate effect of this is that the first line of the function body is at the same indentation level that the ) of the return types. But this can also happen in typescript:

function foo():
  | AVeryLongLongLongType
  | AnotherVeryVeryVeryLongType {
  console.log();
}

Anyway, I guess my point is that we can create somewhat similar scenarios in typescript and see what prettier core does, and just imitate it as much as possible. But, again, I would like to hear more opinions on this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions