loopbackio / loopbackio/loopback-next
eslint: forbid boolean function arguments
@achrinza ci sta già lavorando.
Dal 2/12/2021.
- Lingua principale
- TypeScript
- Stelle
- 5.1k
- Fork
- 1.1k
- Merge medio
- 2g 21h
- PR unite (30g)
- 27
Descrizione
Function arguments of type `boolean` are considered as a bad practice because they make the code difficult to read and reason about.
Consider the following code:
```ts
ctx.getBinding('repositories.todo', true);
```
What does the `true` flag mean? There is no way to tell when reading the code using the function, we have to look up the API definition and/or implementation to understand.
Compare with the current implementation which is following the best practices:
```ts
ctx.getBinding('repositories.todo', {optional: true});
```
Now it's more clear that we want to treat the binding as optional and don't trigger an error when it's not found.
Let's improve our [eslint configuration]() to automatically detect and reject boolean arguments. Eslint rule to use: [no-inferrable-types](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-inferrable-types.md)
Further reading:
- [Martin Fowler on Flag Arguments](https://martinfowler.com/bliki/FlagArgument.html)
- [Is it wrong to use a boolean parameter to determine behavior](https://softwareengineering.stackexchange.com/a/370801/18241)
## Acceptance criteria
- [ ] A commit modifying our eslint configuration to enable the new check. This is a breaking change, see [Describe incompatibilites for release notes](https://github.com/strongloop/loopback-next/blob/7fe694865b337c99beb25afc581c5429fb758746/docs/site/DEVELOPING.md#describe-incompatibilites-for-release-notes)
- [ ] One or more commits fixing any violations of this new rule in our existing code. For functions (methods) that are part our public API, decide whether to disable this rule via a code comment, change the method signature in a breaking (semver-major) change or implement both variants (with an options arg, with a boolean arg for backwards compatibility) to avoid a breaking change.
Breaking changes must be committed in such way that they don't trigger semver-major release of packages that are not affected.
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Valutazione
Questa issue non è ancora stata valutata.