avoid_banned_names

v1.0.0WarningConfigurableArchitecture

Flags declarations named with an identifier you ban, optionally only inside the directories you name. Enforces a project’s vocabulary: ban data, temp and manager as meaningless, or reserve a domain term for the one thing it should mean.

Names like data, info, temp and manager survive because they are never wrong — every value is data and every class manages something. That is exactly what makes them useless: they tell the next reader nothing the type did not already say.

This rule is in no preset and reports nothing until you add banned:. Every example below shows the configuration that produces it.

Setup

analysis_options.yaml

analysis_options.yaml

many_lints:
  rules:
    avoid_banned_names:
      banned:
        - deny: ['data', 'temp', 'info', 'manager']
          message: 'Name it for what it holds.'

many_lints.yaml

many_lints.yaml

rules:
  avoid_banned_names:
    banned:
      - deny: ['data', 'temp', 'info', 'manager']
        message: 'Name it for what it holds.'

deny matches exactly. Use deny_pattern to match by shape, and in: to limit an entry to part of the tree.

Examples

Ban meaningless names

- deny: ['data', 'temp', 'manager']
  message: 'Name it for what it holds.'

// Don't
final data = fetchUsers();  // LINT
void process(int temp) {}   // LINT
class Manager {}            // LINT

// Do
final users = fetchUsers();
void process(int celsius) {}
class UserDirectory {}

Exact matching means userData and dataSource are left alone — only the bare name data is reported.

Ban a naming convention with a pattern

deny_pattern is anchored to the whole name, so .*Impl matches UserImpl but not ImplementationDetail:

- deny_pattern: ['.*Impl']
  message: 'Name the implementation for how it differs.'

// Don't
class UserImpl {}  // LINT

// Do
class InMemoryUserRepository {}

Reserve a domain term

If Order means a customer purchase, keep it from also meaning a sort direction:

- deny: ['Order']
  in: ['lib/ui/**']
  message: 'Order is the purchase entity; call a sort direction SortDirection.'

// Don't  — in lib/ui/product_list.dart
enum Order { ascending, descending }  // LINT

// Do
enum SortDirection { ascending, descending }

Ban single-letter type parameters

Type parameters are declarations too, so the same list reaches them:

- deny: ['T1', 'T2', 'X']
  message: 'Name the type parameter after what it stands for.'

// Don't
class Cache<T1, T2> {}  // LINT on both

// Do
class Cache<Key, Value> {}

Options

Option	Type	Default	Description
banned	list of entries	[]	The entries to enforce. With none, the rule reports nothing

Per entry:

Key	Type	Required	Description
deny	string or list	one of deny / deny_pattern	Identifiers banned by exact match
deny_pattern	string or list	one of deny / deny_pattern	Regular expressions, anchored to the whole name
in	list of globs	no	Paths, relative to the package root, where the entry applies. Omit to apply everywhere
message	string	no	A project-specific explanation appended to the diagnostic

Known limitations

Declarations only. Variables, parameters, methods, functions, classes, mixins, enums, extension types and type parameters are checked — every place a name is chosen. Uses of a banned name are not reported, because renaming the declaration fixes them all at once.

Exact unless you ask otherwise. deny: ['data'] does not report userData. Reach for deny_pattern when you want the shape rather than the word.

A malformed entry is skipped silently. An entry denying nothing, or an invalid regular expression, costs you that entry and nothing else — a plugin cannot report problems against a YAML file.

Related rules

• avoid_banned_annotations — Ban specific annotations, optionally scoped by directory.
• avoid_banned_exports — Ban re-exports of specific libraries, optionally scoped by directory.
• avoid_banned_imports — Ban imports of specific libraries, optionally scoped by directory.
• avoid_banned_types — Ban specific types from being named, optionally scoped by directory.