Disable the unicorn/prevent-abbreviations rule

[leroykorterink]

There is a proposal to disable the unicorn/prevent-abbreviations rule.

unicorn/prevent-abbreviations: another huge contender for the most annoying rule.
- @edgardz

Please see the documentation

[leroykorterink]

It is important to not use abbreviations in code because it can make the code harder to understand and maintain. Abbreviations can be ambiguous and may not be immediately clear to other developers who are reading the code, especially to developers that are not familiar with a project. Using descriptive and meaningful names for variables, functions, and classes helps improve code readability and reduces the chances of misunderstandings.

function myFunction(res: Response, e: Error) {
  ...

Imagine the function signature is not visible because the function body has many lines of code.

• e could for example be an instance of an Error or Event, it's a guessing game to understand what e is without hovering the character to see the type or scrolling to the function signature.

• res could be an abbreviation for "result" but the abbreviation is also often used for the word "response". Again, the abbreviation makes the code harder to maintain because it'll take more effort to understand what it means.

[ThaNarie]

There are still cases we can choose to allow in our config (e.g. props vs properties, or params vs parameters). Mainly because these are conventions when working with certain frameworks/libraries.

The names are auto-fixed, so it shouldn't really be in the way most of the time (and when they are in the way, it's likely an exception can be configured).

[edgardz]

The main issue with this rule is sometimes you end up with conflicting names in your components.
For instance you can have an error prop and on the internals you need to handle another error.

With this rule you cannot just write something like:

catch (e) { ... }

You would have to write it like:

catch (error) { ... }

Now causing another error because @typescript-eslint/no-shadow rule will be triggered.

Then you will endup with

catch (error_) { ... }

This introduces verbosity. Breaks the development flow. And consider devs to be like babies.

Honestly, if a dev doesn't know that src means source, or env means environment, or an e variable inside a catch doesn't mean error, and an e inside a event listener means event ....

[ThaNarie]

You would have to write it like:

You don't, it's auto-fixed for you.
So you can write the e, res, etc that you like, the rule will expand it for you, so that others have an easier time reading your code.

---

Now causing another error because @typescript-eslint/no-shadow rule will be triggered.
Then you will endup with

catch (error_) { ... }

What would you have written? catch (e_) { ... } :D

This is not an issue with the abbreviations rule.

But to offer my opinion, if you have nested errors, I would give them proper names:

try {
  // do something
} catch (error) {
  try {
    await fetch(....);
  } catch (fetchError) {
    // do something with fetchError
  }
}

Having these called e and e2 doesn't make it more readable in my opinion.

---

Honestly, if a dev doesn't know that src means source, or env means environment,

I agree that they should know, but it doesn't mean that having them auto-fixed is a bad thing.

or an e variable inside a catch doesn't mean error, and an e inside a event listener means event

I think in this case it's more about not having to scan upwards for context, but just immediately seeing what it is.

And additionally, this rule isn't only about those conventions. As said, we can easily allow common ones.

It's more about people being discouraged from using all kinds of abbreviations all around the code, and having all function and variable names being clearly readable.

---

Having said that all, I think this boils down to writing code vs reading code.

I hope you can agree that for reading, this rule is indeed useful.
Or would you argue that seeing error or event instead of e makes it more verbose, thus harder to read?

And for writing, again, this is auto-fixable, so should not impact you much, or at all (when properly configured for our conventions).