fix(SNP-1286): rules member ordering

[ilyasov-ainur]

Changes

• Changed member-ordering

• Changed arguments-ordering.
  Added last order for :
  - body
  - child
  - children

• Added parameters-ordering

[github-actions]

Link to Pyrus task

[ilyasov-ainur]

This order of arguments is needed for the child, children and body arguments come last.

Note: Text styles use the body style. Should I add an excluded to it?

[plasticfiresam]

Note: Text styles use the body style. Should I add an excluded to it?

You mean there is a body text style in theme extensions?

You can look at ignoring the rule for files that describe styles, as a rule they have theme and extension in the filename, which can be used as a reference. But in this case you will need to fix this nuance of the linter either in the template project (to maintain a unified projects structure), or for the template project add an override of this rule in analysis rule file

[ilyasov-ainur]

Yes, I meant text extensions.
At first, I added excluding for text_scheme file, but then i removed it in this commit
because I also thought it would be better to do it in a template project

[ilyasov-ainur]

This order of parameters inside class constructors.

Note: I didn't find:

1. how to disable alphabetical order;
2. how to set the order of anonymous fields that are not referred to class fields
   Example:

ElementaryWidget({
    super.key,
    /// For this parameter
    WidgetModelFactory wmFactory = defaultWMFactory,
})

[plasticfiresam]

1. how to disable alphabetical order;
2. how to set the order of anonymous fields that are not referred to class fields

1. I think alphabetical sorting is OK, it's easier to navigate the code that way.
2. Isn't "default" option responsible for this? https://dcm.dev/docs/rules/common/parameters-ordering/

[ilyasov-ainur]

2. Yes, but in our projects such parameters often come after super, and parameters with default values, which are specified through this, come before.

[plasticfiresam]

2. Yes, but in our projects such parameters often come after super, and parameters with default values, which are specified through this, come before.

Does this only apply to ElementaryWidget, or are there other cases? In the case of ElementaryWidget I tend to think that such widgets should not have their own final fields, the arguments should be passed directly to WM

[Sadhorsephile]

I think alphabetical sorting is OK, it's easier to navigate the code that way.

To be honest, I used to order arguments by semantic. E.g.:

  const SomeWidget({
    required this.id,
    required this.title,
    required this.description,
    required this.closeIcon,
    super.key,
  });

With alphabetic order it'll be look like this:

const SomeWidget({
      required this.closeIcon,
      required this.description,
      required this.id,
      required this.title,
      super.key,
    });

This is not a big problem, but it can be inconvient in some cases

[ilyasov-ainur]

To be honest, I used to order arguments by semantic. E.g.:

I agree, that's why I wanted to turn off the alphabetical order

[ilyasov-ainur]

Does this only apply to ElementaryWidget, or are there other cases?

I can't think of a practical example using all types of parameters...

Example:

class SomeSuperClass {
  final int? a;

  const SomeSuperClass({this.a});
}

class SomeClass extends SomeSuperClass {
  final int b;
  final int d;
  final int _c;

  SomeClass({
    required this.d,
    super.a,
    this.b = 1,
    int c = 2,
  }) : _c = c;
}

[plasticfiresam]

Let`s finish the body-text issue and we can merge, LGTM

[plasticfiresam]

1. how to disable alphabetical order;
2. how to set the order of anonymous fields that are not referred to class fields

1. I think alphabetical sorting is OK, it's easier to navigate the code that way.
2. Isn't "default" option responsible for this? https://dcm.dev/docs/rules/common/parameters-ordering/

[plasticfiresam]

@Sadhorsephile
Can you participate in the review too?

[Sadhorsephile]

I think alphabetical sorting is OK, it's easier to navigate the code that way.

To be honest, I used to order arguments by semantic. E.g.:

  const SomeWidget({
    required this.id,
    required this.title,
    required this.description,
    required this.closeIcon,
    super.key,
  });

With alphabetic order it'll be look like this:

const SomeWidget({
      required this.closeIcon,
      required this.description,
      required this.id,
      required this.title,
      super.key,
    });

This is not a big problem, but it can be inconvient in some cases