Skip to content

refactor: migrate member_ordering rule#297

Open
solid-illiaaihistov wants to merge 4 commits into
solid-software:analysis_server_migrationfrom
solid-illiaaihistov:252-migrate-member_ordering
Open

refactor: migrate member_ordering rule#297
solid-illiaaihistov wants to merge 4 commits into
solid-software:analysis_server_migrationfrom
solid-illiaaihistov:252-migrate-member_ordering

Conversation

@solid-illiaaihistov

Copy link
Copy Markdown
Collaborator

Closes #252

@solid-illiaaihistov

Copy link
Copy Markdown
Collaborator Author

/gemini review

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the member_ordering lint rule to extend SolidMultiLintRule (a new base class for rules with multiple diagnostic codes), splits several model classes into separate files, and replaces the old test file with a comprehensive unit test suite. The review feedback correctly identifies two critical compilation errors in MemberOrderingVisitor: first, the use of the non-existent BlockClassBody class, and second, attempting to access a .name property on ConstructorDeclaration.typeName (which is a Token and should use .lexeme instead).

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Comment thread lib/src/lints/member_ordering/visitors/member_ordering_visitor.dart
Comment thread lib/src/lints/member_ordering/visitors/member_ordering_visitor.dart Outdated
@solid-illiaaihistov solid-illiaaihistov linked an issue Jun 23, 2026 that may be closed by this pull request
Comment thread lib/src/lints/member_ordering/visitors/member_ordering_visitor.dart Outdated

@override
List<MemberInfo> visitClassDeclaration(ClassDeclaration node) {
void visitClassDeclaration(ClassDeclaration node) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think some of the blocks in this method should be extracted:

void _visitClassDeclaration(ClassDeclaration node) {
    final type = node.extendsClause?.superclass.type;
    final isFlutterWidget =
        isWidgetOrSubclass(type) || isWidgetStateOrSubclass(type);

    final body = node.body;
    if (body is BlockClassBody) {
      for (final member in body.members) {
        if (member is FieldDeclaration) {
          _visitFieldDeclaration(member, isFlutterWidget);
        } else if (member is ConstructorDeclaration) {
          _visitConstructorDeclaration(member, isFlutterWidget);
        } else if (member is MethodDeclaration) {
          _visitMethodDeclaration(member, isFlutterWidget);
        }
      }
    }
}

void _reportWrongOrder() {
    final wrongOrderMembers = _membersInfo.where(
      (info) => info.memberOrder.isWrong,
    );

    for (final memberInfo in wrongOrderMembers) {
      final memberGroup = memberInfo.memberOrder.memberGroup;
      final previousMemberGroup = memberInfo.memberOrder.previousMemberGroup;

      _rule.reportAtNode(
        memberInfo.classMember,
        diagnosticCode: MemberOrderingRule.wrongOrderCode,
        arguments: [
          memberGroup.toString(),
          previousMemberGroup?.toString() ?? '',
        ],
      );
    }
}

void _reportAlphabeticalOrder() {
      final alphabeticallyWrongOrderMembers = _membersInfo.where(
        (info) => info.memberOrder.isAlphabeticallyWrong,
      );

      for (final memberInfo in alphabeticallyWrongOrderMembers) {
        final names = memberInfo.memberOrder.memberNames;
        _rule.reportAtNode(
          memberInfo.classMember,
          diagnosticCode: MemberOrderingRule.alphabeticalOrderCode,
          arguments: [
            names.currentName,
            names.previousName ?? '',
          ],
        );
      }
}

void _reportAlphabeticalTypeOrder() {
final alphabeticallyByTypeWrongOrderMembers = _membersInfo.where(
        (info) => info.memberOrder.isByTypeWrong,
      );

      for (final memberInfo in alphabeticallyByTypeWrongOrderMembers) {
        final names = memberInfo.memberOrder.memberNames;
        _rule.reportAtNode(
          memberInfo.classMember,
          diagnosticCode: MemberOrderingRule.alphabeticalByTypeOrderCode,
          arguments: [
            names.currentName,
            names.previousName ?? '',
          ],
        );
      }
}

  void _reportMembers(bool Function(MemberInfo) filter, DiagnosticCode code) {
    final filtered = _membersInfo.where(filter);

    for (final memberInfo in filtered) {
      final names = memberInfo.memberOrder.memberNames;
      _rule.reportAtNode(
        memberInfo.classMember,
        diagnosticCode: code,
        arguments: [
          names.currentName,
          names.previousName ?? '',
        ],
      );
    }
  }

// Similar repetition in _visitX

I feel like we should also extract the bool _isXGroup methods into an extension on MemberGroup and move it to a separate file

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implemented the refactoring!

_rule.reportAtNode(
memberInfo.classMember,
diagnosticCode: code,
arguments: getArguments(memberInfo),

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like all the callers only use .memberOrder anyway

Suggested change
arguments: getArguments(memberInfo),
arguments: getArguments(memberInfo.memberOrder),

required ClassMember classMember,
required MemberGroup parsedGroup,
required bool isFlutterWidget,
required String name,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
required String name,
required Token? token,

and then do token?.name.lexeme ?? '' inside to make the calls shorter

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I played around refactoring it and I was able to get rid of this file completely:

lib/src/utils/implies.dart:

/// Logical implication operation.
extension BoolImplies on bool {
  /// Logical implication operation.
  ///
  /// True implies that [other] is also true.
  // ignore: avoid_positional_boolean_parameters
  bool implies(bool other) => objectImplies(this, other, false);
}

/// Sugar syntax helper to write extensions analogus to bool implies.
///
/// A truthy (!= [falsy]) value of [a] implies an equal value of [b].
bool objectImplies<T>(T a, T b, T falsy) => a == falsy || a == b;

/// A class that supports logical implication of it's objects.
abstract class Implicable {
  /// Logical implication operation.
  ///
  /// A truthy value of this object implies an equal value of [other].
  bool implies(Implicable other);
}

Add a new method to abstract class MemberGroup:

  abstract class MemberGroup implements Implicable {

...

  @override
  bool implies(covariant MemberGroup other) =>
      modifier.implies(other.modifier) && annotation.implies(other.annotation);
}

and same for subclasses and relevant enums:

  @override
  bool implies(covariant ConstructorMemberGroup other) =>
      isFactory.implies(other.isFactory) && isNamed.implies(other.isNamed);
  @override
  bool implies(covariant FieldMemberGroup other) =>
      isLate.implies(other.isLate) &&
      isStatic.implies(other.isStatic) &&
      isNullable.implies(other.isNullable) &&
      keyword.implies(other.keyword);
  @override
  bool implies(covariant Modifier other) =>
      objectImplies(this, other, Modifier.unset);
  @override
  bool implies(covariant Annotation other) =>
      objectImplies(this, other, Annotation.unset);
  @override
  bool implies(covariant FieldKeyword other) =>
      objectImplies(this, other, FieldKeyword.unset);
  @override
  bool implies(MemberGroup other) =>
      super.implies(other) &&
      other is MethodMemberGroup &&
      isStatic.implies(other.isStatic) &&
      isNullable.implies(other.isNullable) &&
      name.implies(other.name);
}

extension on String? {
  bool implies(String? other) => objectImplies(this, other, null);
}
  @override
  bool implies(covariant FieldMemberGroup other) =>
      isLate.implies(other.isLate) &&
      isStatic.implies(other.isStatic) &&
      isNullable.implies(other.isNullable) &&
      keyword.implies(other.keyword);

One thing I'm not entirely sure about is covariant - maybe we should just check is in the method instead.

WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Migrate member_ordering

2 participants