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

• List any existing rules this proposal modifies, complements, overlaps or conflicts with.
• List any relevant issues (reported here, the SDK Tracker, or elsewhere).
• If there's any prior art (e.g., in other linters), please add references here.
• 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?)
• If this proposal is motivated by real-world examples, please provide as many details as you can. Demonstrating potential impact is especially valuable.

[navaronbracke]

What with the following patterns?

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

class _MyWidgetState extends State<MyWidget> {}

// 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