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

Ensure use of block body for arrow functions #1006

Merged
merged 4 commits into from
May 13, 2024

Conversation

Cruikshanks
Copy link
Member

@Cruikshanks Cruikshanks commented May 12, 2024

DEFRA/water-abstraction-team#115

Just like parens in arrow functions how you write an arrow function can differ.

const materials = [
  'Hydrogen',
  'Helium',
  'Lithium',
  'Beryllium'
]

// Block body
materials.forEach((material) => {
  console.log(`${material} - ${material.length}`)
})

// Concise body
materials.forEach((material) => console.log(`${material} - ${material.length}`))

The block-body version can be applied in all cases. But like with parens where devs will often drop the parens when there is only 1 param, they'll use concise for simple arrow functions and block-body for the rest.

To us though, the argument is the same. For those new or inexperienced with JavaScript, this inconsistency can be confusing and a blocker to progressing with the language. The more we can do to keep the code base simple and consistent, the easier new folks will find working with it.

So, this change enables the rule in ESLint that requires all arrow functions to use the block-body.


The ESLint stylistic plugin we use has a related rule; https://eslint.style/rules/js/implicit-arrow-linebreak#when-not-to-use-it which suggests it should not be used when arrow-body-style is set to 'always'. This is why it is disabled as part of this change.

@Cruikshanks Cruikshanks added the conventions Changes to tools that enforce our conventions label May 12, 2024
@Cruikshanks Cruikshanks self-assigned this May 12, 2024
@Cruikshanks Cruikshanks force-pushed the ensure-block-body-for-arrow-functions branch from b98d469 to 563dc72 Compare May 12, 2024 22:10
@Cruikshanks
Copy link
Member Author

This will mean the exception in our conventions will have to go. But if consistency was the name of the game we probably shouldn't have had the exception in the first place 😬

@Cruikshanks Cruikshanks marked this pull request as ready for review May 12, 2024 22:17
Copy link
Contributor

@Jozzey Jozzey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. You seem to have upset SonarCloud a bit though.

DEFRA/water-abstraction-team#115

Just like [parens in arrow functions](#1004) how you write an [arrow function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions) can differ.

```javascript
const materials = [
  'Hydrogen',
  'Helium',
  'Lithium',
  'Beryllium'
]

// Block body
materials.forEach((material) => {
  console.log(`${material} - ${material.length}`)
})

// Concise body
materials.forEach((material) => console.log(`${material} - ${material.length}`))
```

The _block-body_ version can be applied in all cases. But like with parens where devs will often drop the parens when there is only 1 param, they'll use _concise_ for simple arrow functions and _block-body_ for the rest.

To us though, the argument is the same. For those new or inexperienced with JavaScript this inconsistency can be confusing and a blocker to progressing with the language. The more we can do to keep the code base simple and consistent, the easier new folks will find working with it.

So, this change enables [the rule in ESLint](https://eslint.org/docs/latest/rules/arrow-body-style) that requires all arrow-functions to use the block-body.
@Cruikshanks Cruikshanks force-pushed the ensure-block-body-for-arrow-functions branch from 018dbe5 to f9bfed9 Compare May 13, 2024 15:12
@Cruikshanks Cruikshanks force-pushed the ensure-block-body-for-arrow-functions branch from f9bfed9 to c47f473 Compare May 13, 2024 15:15
@Cruikshanks Cruikshanks merged commit e88d651 into main May 13, 2024
6 checks passed
@Cruikshanks Cruikshanks deleted the ensure-block-body-for-arrow-functions branch May 13, 2024 15:31
Cruikshanks added a commit to DEFRA/water-abstraction-team that referenced this pull request May 13, 2024
#115

We have been working on using ESLint to help highlight coding convention infractions instead of folks either having to remember them when submitting or reviewing PRs. In [Ensure use of block body for arrow functions](DEFRA/water-abstraction-system#1006) we managed to figure out how to have the tool highlight when someone has used concise over block-body format for an arrow function.

However, the rule cannot distinguish between when it was being used normally, or just to check if something is 'truthy'. That was the one exception we had and there is no point in keeping it documented here if the tool won't allow. We also didn't think it was worth the effort to try and 'hack' ESLint or develop a custom rule just to support this. On balance, its goes against one of our guiding principle of consistency anyway.

So, this change removes the exceptions from our docs.
Cruikshanks added a commit to DEFRA/water-abstraction-team that referenced this pull request May 15, 2024
#115

We have been working on using ESLint to help highlight coding convention infractions instead of folks either having to remember them when submitting or reviewing PRs. In [Ensure use of block body for arrow functions](DEFRA/water-abstraction-system#1006) we managed to figure out how to have the tool highlight when someone has used concise over block-body format for an arrow function.

However, the rule cannot distinguish between when it was being used normally, or just to check if something is 'truthy'. That was the one exception we had and there is no point in keeping it documented here if the tool won't allow it. We also didn't think it was worth the effort to try and 'hack' ESLint or develop a custom rule just to support this. On balance, it goes against one of our guiding principles of consistency anyway.

So, this change removes the exceptions from our docs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conventions Changes to tools that enforce our conventions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants