Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lint for missing type info in formal parameter #57147

Open
pq opened this issue Jan 30, 2015 · 4 comments
Open

Lint for missing type info in formal parameter #57147

pq opened this issue Jan 30, 2015 · 4 comments
Labels
area-devexp Developer Experience related issues (DevTools, IDEs, Analysis Server, completions, refactoring, etc) devexp-linter Issues with the analyzer's support for the linter package linter-lint-request P4 type-enhancement A request for a change that isn't a bug

Comments

@pq
Copy link
Member

pq commented Jan 30, 2015

Discovered in the wild a number of cases like this:

typedef A(B);
typedef B(dynamic);

Both of them are essentially equivalent to dynamic->dynamic which is most likely not what the user has in mind. Instead, they likely mean:

typedef A(B _);
typedef B(dynamic _);

As Paul Berry points out it's a nasty user trap in the language, especially for people coming from a C/C++ background where using a single identifier as a formal parameter denotes the type of the formal parameter. A proposed lint:

whenever a single identifier is used to name a formal parameter, check the enclosing scope to see if
the name shadows a type. If it does, give a hint because the user probably meant the identifier to
denote the type of the formal parameter. We could even add a quick fix which adds "_" as the
parameter name.

@pq pq added the type-enhancement A request for a change that isn't a bug label Feb 4, 2015
@pq pq changed the title Missing type info in formal parameter Lint for missing type info in formal parameter Feb 7, 2015
@pq pq self-assigned this Feb 7, 2015
pq referenced this issue Sep 23, 2015
Lo and behold this harkens back to lint request #1 (https://github.com/dart-lang/linter/issues/1). Could have saved me a headache!

[email protected]

Review URL: https://codereview.chromium.org//1367723003 .
@ochafik
Copy link
Contributor

ochafik commented Jun 16, 2016

An easy way to tackle this would be to check that argument names start with lowercase. And a similar check for method names would help spot another sneaky case:

class MyClassNameBeforeRefactoring {
  // oops, forgot to rename the constructor...
  MyClassNameAfterRefactoring() {
    // something important that will never happen
  }
}

@zoechi
Copy link
Contributor

zoechi commented Jun 16, 2016

@ochafik for your case a rule for functions and methods like http://dart-lang.github.io/linter/lints/non_constant_identifier_names.html would be nice to catch this.

@dotdoom
Copy link

dotdoom commented Sep 10, 2018

Looks like this will become irrelevant when the old typedef syntax becomes obsolete?

@srawlins
Copy link
Member

srawlins commented Aug 1, 2024

Yeah I think we've likely dodged this by recommending the new typedef format.

@srawlins srawlins added the P4 label Aug 1, 2024
@devoncarew devoncarew added devexp-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. labels Nov 18, 2024
@devoncarew devoncarew transferred this issue from dart-lang/linter Nov 18, 2024
@bwilkerson bwilkerson added area-devexp Developer Experience related issues (DevTools, IDEs, Analysis Server, completions, refactoring, etc) and removed area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. labels Feb 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-devexp Developer Experience related issues (DevTools, IDEs, Analysis Server, completions, refactoring, etc) devexp-linter Issues with the analyzer's support for the linter package linter-lint-request P4 type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

8 participants