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

Increase flexibility of --noUnusedParameters #12149

Closed
JoshuaKGoldberg opened this issue Nov 10, 2016 · 2 comments
Closed

Increase flexibility of --noUnusedParameters #12149

JoshuaKGoldberg opened this issue Nov 10, 2016 · 2 comments
Labels
Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds

Comments

@JoshuaKGoldberg
Copy link
Contributor

JoshuaKGoldberg commented Nov 10, 2016

As per #9458 (comment): relying on _ prefixes as a naming convention can be suboptimal for a few reasons:

  • Libraries such as jQuery and Knockout often provide function interfaces whose first parameter(s) aren't necessary for all usages
  • We're binding compiler logic to the variable name
  • It's easy to forget to remove the prefix, such as during refactoring
  • Prefixed names clash with some existing coding styles

I jumped the gun a bit and sent PR #12139 :) that blindly allows unused parameters before used ones. Perhaps a more complete design would be to provide configurations for --noUnusedParameters?

  • No unused parameters in any situation: tsc --noUnusedParameters
  • "---" excluding _ prefixes: tsc --noUnusedParameters allow-prefixed
  • "---" excluding those before used ones: tsc --noUnusedParameters allow-before-used
  • "---" excluding both _ prefixes and those before used ones: tsc --noUnusedParameters allow-prefixed --noUnusedParameters allow-before-used
@mhegazy
Copy link
Contributor

mhegazy commented Nov 10, 2016

We're binding compiler logic to the variable name

Binding the order of parameters to which own is allowed to be unused seems equally troubling.

Libraries such as jQuery and Knockout often provide function interfaces whose first parameter(s) aren't necessary for all usages

This is true in cases where you are using a library, but not so in cases where these are your own functions. you want to know that they are unused, so that you can refactor your code, and change the call sites.

Perhaps a more complete design would be to provide configurations for

I do not think adding new options/configurations is a good solution in general. we have too many of them already. ideally we would reduce them or at least keep them the same.

I should add that this feature crosses the line between the checking (type system, assignment comparability, etc) and linting. I understand that for linter features, there is more room to style choices, where as this does not fit with the rest of the compiler behavior. I would recommend considering tslint for scenarios like these where you want to customize reporting.

@JoshuaKGoldberg
Copy link
Contributor Author

That makes sense. Thanks!

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds labels Nov 10, 2016
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds
Projects
None yet
Development

No branches or pull requests

3 participants