Add new rule: use_descriptive_names_for_type_parameters

[xJac0b]

Resolves #94

[gemini-code-assist]

Hello @xJac0b, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Hello! Gemini or gemini-code-assist here, providing a summary of this pull request. This PR introduces a new lint rule, use_descriptive_names_for_type_parameters, aimed at improving code readability and maintainability. The rule specifically targets declarations (like classes, functions, methods, aliases, extensions, and mixins) that have three or more type parameters and flags any of those parameters that use a single-letter name. This helps encourage developers to use more descriptive names for type parameters in complex generic types, making the code easier to understand.

Highlights

• New Lint Rule: Adds the use_descriptive_names_for_type_parameters rule to the solid_lints package.
• Rule Logic: The rule triggers a warning when a declaration has three or more type parameters and any of those parameters have a single-letter name.
• AST Visitor Implementation: Includes a dedicated AST visitor (UseDescriptiveNamesForTypeParametersVisitor) to traverse the code and identify violations in various declaration types (classes, functions, methods, generic type aliases, extensions, mixins).
• Test Coverage: Adds a new test file (use_descriptive_names_for_type_parameters_test.dart) with examples demonstrating both violations and valid cases for the new rule.

Changelog

Click here to see the changelog

• lib/solid_lints.dart
  • Imports the new UseDescriptiveNamesForTypeParametersRule.
  • Registers the new rule within the _SolidLints plugin.
• lib/src/lints/use_descriptive_names_for_type_parameters/use_descriptive_names_for_type_parameters_rule.dart
  • Adds the main implementation for the UseDescriptiveNamesForTypeParametersRule.
  • Defines the lint name and problem message.
  • Registers AST visitors for relevant declaration types (class, function, method, generic type alias, extension, mixin) to find violations.
• lib/src/lints/use_descriptive_names_for_type_parameters/visitors/use_descriptive_names_for_type_parameters_visitor.dart
  • Adds the UseDescriptiveNamesForTypeParametersVisitor class.
  • Implements the logic to identify single-letter type parameters in declarations with three or more type parameters.
• lint_test/use_descriptive_names_for_type_parameters_test/analysis_options.yaml
  • Adds configuration to enable the new use_descriptive_names_for_type_parameters rule for testing.
• lint_test/use_descriptive_names_for_type_parameters_test/use_descriptive_names_for_type_parameters_test.dart
  • Adds test cases to verify the behavior of the use_descriptive_names_for_type_parameters rule.
  • Includes examples of classes, functions, methods, typedefs, extensions, and mixins with varying numbers and names of type parameters.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new lint rule, use_descriptive_names_for_type_parameters, which is a valuable addition for improving code clarity when dealing with multiple type parameters. The implementation is largely well-done, and the test coverage is comprehensive, covering various declaration types and scenarios.

I have one suggestion for a refactoring that could simplify the rule's implementation by removing the need for a separate visitor class. Overall, great work on defining and implementing this useful rule!

Summary of Findings

• Code Simplification and Maintainability: The rule's implementation can be simplified by inlining the logic from the UseDescriptiveNamesForTypeParametersVisitor directly into the UseDescriptiveNamesForTypeParametersRule class. This would remove the need for a separate visitor class and file, making the rule more self-contained and easier to maintain.
• Test Coverage: The test cases provided in use_descriptive_names_for_type_parameters_test.dart are comprehensive and effectively validate the rule's behavior across different declaration types and scenarios. This is well done.
• Rule Definition: The lint name, problem message, and the core logic for identifying single-letter type parameters when three or more are present are clear and correctly implemented.

Merge Readiness

The pull request is in good shape and introduces a useful lint rule. The core functionality is correct and well-tested. I've suggested a refactoring to simplify the implementation, which I believe would improve maintainability. I recommend addressing this suggestion before merging. As an AI, I am not authorized to approve pull requests; please ensure further review and approval from team members.