refactor(eslint/arrow-body-style): clean up implementation and improve documentation

[antoinezanardi]

This is my first contribution to Oxc, aimed at improving code maintainability and standardizing documentation across rules.

This PR serves as a draft proposal for how I can contribute to rules, focusing on both code and documentation. Comments and suggestions are very welcome to refine the style in a way that satisfies everyone.

Note

This PR is focused solely on refactoring and documentation; no test behavior is modified.

🔩 Refactoring

Goals when refactoring rules:

• Make the code more idiomatic Rust (use ?, match, if let, Option/Result, Iterator, etc. naturally).
• Improve readability and maintainability through better structuring, naming, and relevant refactoring.
• Follow Rust best practices (borrowing management, clarity of signatures, use of &/Cow/From/Into where appropriate).
• Avoid adding complexity: prioritize clarity and conciseness.
• Prefer early returns to reduce nesting and improve flow.
• Prefer the functional programming style.

📚 Documentation

Main changes in the documentation:

• Add relevant content from the original ESLint rule for context.
• Move up the Options section and clarify all possibilities.
• Clarify the examples with detailed sections for each option, including correct and incorrect usage.

Next steps (if accepted):

• Apply this documentation format and refactoring approach to other rules in future PRs for consistency across the project.

📖 Rule documentation skeleton

# Rule Name

## What it does

_A concise description of what the rule enforces or prevents.  
Briefly mention the relevant language construct(s) and what aspects are controlled._

---

## Why is this bad?

_Explain why not following this rule can lead to issues such as readability, maintainability, or bugs._

---

## Options

**First option:**  
- Type: `string`  
- Enum: `"<option1>"`, `"<option2>"`, ...  
- Default: `"<defaultOption>"`  

_Possible values (add descriptions for each value):_
- `<option1>`: _Explain what this enforces or prevents._
- `<option2>`: _Explain what this enforces or prevents._
- ...

**Second option (if applicable):**  
- Type: `object`  
- Properties:  
    - `<propertyName>`: `<type>` (default: `<defaultValue>`) - _Explanation of what this property controls._  

_Note: Add any relevant caveats, such as when an option is only used with a particular mode/value._

**Example configuration:**

```json
{
    "<rule-name>": ["error", "<option>", { "<propertyName>": <value> }]
}
``
---

## Examples

_Organize examples under sections for each main option._

### `"<option>"`

#### Incorrect

```js
// Code that violates the rule with this option
``

#### Correct

```js
// Compliant code with this rule/option
``

_Repeat the above for each relevant option, such as:_

### `"<option>" with { "<propertyName>": true }`

#### Incorrect

```js
// Code sample
``

#### Correct

```js
// Code sample
``

[graphite-app]

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[Copilot]

Pull Request Overview

This PR refactors the arrow-body-style ESLint rule implementation to improve code organization and enhance documentation. The changes focus on making the code more idiomatic Rust while standardizing the documentation format.

Key Changes:

• Restructured the rule implementation by extracting logic into separate methods for better maintainability
• Enhanced documentation with detailed examples for each configuration option
• Improved code organization using pattern matching and early returns

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[camc314]

thanks!

I pushed another commit with a minor change.
In general it's preferable to have the file look like:

1. diagnostic functions
2. the rule struct + config
3. the rule's proc macro
4. the impl Rule for
5. any helper methods

keeping this same order helps consistency across all rules

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #13389 will not alter performance

_{Comparing antoinezanardi:refactor/arrow-body-style-cleanup (40eb553) with main (fd3233c)}

Summary

✅ 38 untouched benchmarks

[antoinezanardi]

thanks!

I pushed another commit with a minor change. In general it's preferable to have the file look like:

1. diagnostic functions
2. the rule struct + config
3. the rule's proc macro
4. the impl Rule for
5. any helper methods

keeping this same order helps consistency across all rules

Alright, I'll keep this in mind in my future rules refactors, thanks for the feedback