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.dartclassParentextendsStatelessWidget {
...
}
class_ChildextendsStatelessWidget {
...
}

GOOD

// parent.dartimport'child.dart';
classParentextendsStatelessWidget {
...
}
// child.dartclassChildextendsStatelessWidget {
...
}

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

classSomeWidgetextendsStatefulWidget {
...
}
class_SomeWidgetStateextendsState<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 countedallow_typedef: true# we may want to allow small helpers to reside in the same filemaximum_loc: 20# one can argue that if secondary classes aren't exported, they can be allowed to reside in the same fileallow_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