Skip to content

New rule: avoid_multiple_classes_in_one_file #330

Description

@solid-danylosafonov

If some functionality was already extracted to a separate class it usually doesn't make sense keeping it the file of another class.

BAD

// parent.dart

class Parent extends StatelessWidget {
...
}

class _Child extends StatelessWidget {
...
}

GOOD

// parent.dart
import 'child.dart';

class Parent extends StatelessWidget {
...
}
// child.dart
class Child extends StatelessWidget {
...
}

There should also be a way to specify exceptions, e.g. T and State<T> should be allowed in the same file by default
GOOD

class SomeWidget extends StatefulWidget {
...
}

class _SomeWidgetState extends State<SomeWidget> {
...
}

Given that there will be other exceptions, I think this rule should be configurable, and the part about StatefulWidget shouldn't be hardcoded, but put in analysis_options.yaml instead:

solid_lints:
  diagnostics:
    ...
    avoid_multiple_classes_in_one_file:
      exclude:
        # this would ignore any subclasses of `State`
        - State
      # whether typedefs are counted
      allow_typedef: true
      # we may want to allow small helpers to reside in the same file
      maximum_loc: 20
      # one can argue that if secondary classes aren't exported, they can be allowed to reside in the same file
      allow_private: false
    ...

There may be other valid exceptions to this rule, but I'm not even sure that we want to implement any of those except for sub classes. Any other cases seem rare enough to me that we can just use // ignore_for_file instead of complicating the rule itself

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions