proposal: `public_class_matches_filename`

[guidezpl]

public_class_matches_filename

Description

contains a public class which does not match its filename in `PascalCase`. ## Details Naming a class the same as its filename is a common convention in many programming languages, including Dart. While it's not strictly enforced by the language itself, adhering to this convention has several benefits and is considered good practice: - Clarity and Organization: When the class name matches the filename, it becomes easier to locate the code for a specific class in a large codebase. It enhances the organization and readability of the code, making it more maintainable in the long run. - Consistency: Consistency in naming promotes a clean and uniform codebase. When class names and filenames match, it creates a predictable and intuitive structure, leading to a smoother collaboration among developers. - Easy Navigation: Modern IDEs often support convenient navigation features based on filenames and class names. If the convention is followed, developers can jump to a class's source file directly from its declaration or vice versa. - Refactoring: If you need to refactor or rename a class, having the same name for both the class and its file simplifies the process and reduces the likelihood of errors. - Autocompletion: In some code editors or IDEs, when you start typing the class name, the autocompletion feature can suggest matching filenames or vice versa, helping to speed up development. - Platform and Package Conventions: Adhering to this convention aligns with the expectations of the Dart community, and it's more likely to match the conventions used in various Dart packages and libraries. ## Kind style advice ## Bad Examples `mammal.dart` ``` class Bird {} ``` `large_mammal.dart` ``` class Fish {} ``` ## Good Examples `mammal.dart` ``` class Mammal {} ``` `large_mammal.dart` ``` class LargeMammal {} ``` ## Discussion - https://dart.dev/effective-dart/style#do-name-types-using-uppercamelcase - `camel_case_types`: https://dart.dev/tools/linter-rules/camel_case_types - https://dart.dev/effective-dart/style#do-name-packages-and-file-system-entities-using-lowercase-with-underscores - `file_names`: https://dart.dev/tools/linter-rules/file_names I didn't, however, find this specific proposal explicitly called out in official style guides. ### Discussion checklist - [x] List any existing rules this proposal modifies, complements, overlaps or conflicts with. - [x] List any relevant issues (reported here, the [SDK Tracker], or elsewhere). - [x] If there's any prior art (e.g., in other linters), please add references here. - [x] If this proposal corresponds to [Effective Dart] or [Flutter Style Guide] advice, please call it out. (If there isn't any corresponding advice, should there be?) - [x] If this proposal is motivated by real-world examples, please provide as many details as you can. Demonstrating potential impact is _especially valuable_. [Writing Lints]: https://github.com/dart-lang/linter/blob/main/doc/writing-lints.md [Effective Dart]: https://dart.dev/effective-dart [Flutter Style Guide]: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo [SDK Tracker]: https://github.com/dart-lang/sdk/issues

[navaronbracke]

What with the following patterns?

1)

// A common pattern in Flutter
class MyWidget extends StatefulWidget {
  @override
  State<MyWidget> createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {}

2)

// sealed class subclasses should be in the same library
sealed class MySealedClass {}

final class One extends MySealedClass {}

final class Two extends MySealedClass {}

3) part/part of directives in general

[srawlins]

I don't think this rule would have high value. I don't think it would prevent bugs; it would be more a rule for style.

[amrgetment]

I would like to have this linter too