You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(eslint/arrow-body-style): clean up implementation and improve documentation (#13389)
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
``
```
---------
Co-authored-by: Cameron Clark <cameron.clark@hey.com>
ctx.diagnostic(arrow_body_style_diagnostic(body.span,"Unexpected block statement surrounding arrow body; move the returned value immediately after the `=>`."));
0 commit comments