eslint-plugin-code-style 1.1.2 → 1.2.0

package/README.md

@@ -18,7 +18,7 @@
 
 **A powerful ESLint plugin for enforcing consistent code formatting and style rules in React/JSX projects.**
 
-*47 auto-fixable rules to keep your codebase clean and consistent*
+*56 auto-fixable rules to keep your codebase clean and consistent*
 
 </div>
 
@@ -26,7 +26,7 @@
 
 ## 🎯 Why This Plugin?
 
-This plugin provides **47 custom auto-fixable rules** for code formatting. Built for **ESLint v9 flat configs**.
+This plugin provides **56 custom auto-fixable rules** for code formatting. Built for **ESLint v9 flat configs**.
 
 > **Note:** ESLint [deprecated 79 formatting rules](https://eslint.org/blog/2023/10/deprecating-formatting-rules/) in v8.53.0. Our recommended configs use `@stylistic/eslint-plugin` as the replacement for these deprecated rules.
 
@@ -35,7 +35,7 @@ This plugin provides **47 custom auto-fixable rules** for code formatting. Built
 - **Works alongside existing tools** — Complements ESLint's built-in rules and packages like eslint-plugin-react, eslint-plugin-import, etc
 - **Self-sufficient rules** — Each rule handles complete formatting independently
 - **Consistency at scale** — Reduces code-style differences between team members by enforcing uniform formatting across your projects
-- **Fully automated** — All 47 rules support auto-fix, eliminating manual style reviews
+- **Fully automated** — All 56 rules support auto-fix, eliminating manual style reviews
 
 When combined with ESLint's native rules and other popular plugins, this package helps create a complete code style solution that keeps your codebase clean and consistent.
 
@@ -59,17 +59,19 @@ We provide **ready-to-use ESLint flat configuration files** that combine `eslint
 
 ### 💡 Why Use These Configs?
 
-- **Complete Coverage** — Combines ESLint built-in rules, third-party plugins, and all 47 code-style rules
+- **Complete Coverage** — Combines ESLint built-in rules, third-party plugins, and all 56 code-style rules
 - **Ready-to-Use** — Copy the config file and start linting immediately
 - **Battle-Tested** — These configurations have been refined through real-world usage
 - **Fully Documented** — Each config includes detailed instructions and explanations
 
 ### 📋 Available Configurations
 
-| Configuration | Description | Link |
-|---------------|-------------|------|
+| Configuration | Description | Status |
+|---------------|-------------|--------|
 | **React** | React.js projects (JavaScript, JSX) | [View Config](./recommended-configs/react/) |
 | **React + TS + Tailwind** | React + TypeScript + Tailwind CSS | [View Config](./recommended-configs/react-ts-tw/) |
+| **React + TypeScript** | React + TypeScript projects | Coming Soon |
+| **React + Tailwind** | React + Tailwind CSS projects | Coming Soon |
 
 ### ⚡ Quick Start with Recommended Config
 
@@ -94,7 +96,7 @@ We provide **ready-to-use ESLint flat configuration files** that combine `eslint
 <td width="50%">
 
 ### 🔧 Auto-Fixable Rules
-All **47 rules** support automatic fixing with `eslint --fix`. No manual code changes needed.
+All **56 rules** support automatic fixing with `eslint --fix`. No manual code changes needed.
 
 </td>
 <td width="50%">
@@ -187,8 +189,12 @@ rules: {
     "code-style/assignment-value-same-line": "error",
     "code-style/block-statement-newlines": "error",
     "code-style/comment-format": "error",
+    "code-style/component-props-destructure": "error",
+    "code-style/react-code-order": "error",
+    "code-style/component-props-inline-type": "error",
     "code-style/function-call-spacing": "error",
     "code-style/function-naming-convention": "error",
+    "code-style/function-object-destructure": "error",
     "code-style/function-params-per-line": "error",
     "code-style/hook-callback-format": "error",
     "code-style/hook-deps-per-line": "error",
@@ -225,6 +231,11 @@ rules: {
     "code-style/single-argument-on-one-line": "error",
     "code-style/string-property-spacing": "error",
     "code-style/variable-naming-convention": "error",
+    "code-style/enum-format": "error",
+    "code-style/interface-format": "error",
+    "code-style/type-annotation-spacing": "error",
+    "code-style/type-format": "error",
+    "code-style/typescript-definition-location": "error",
 }
 ```
 
@@ -234,34 +245,54 @@ rules: {
 
 ## 📖 Rules Summary
 
-> All **47 rules** are auto-fixable. See detailed examples for each rule in the [Rules Reference](#-rules-reference) section below.
+> All **56 rules** are auto-fixable. See detailed examples for each rule in the [Rules Reference](#-rules-reference) section below.
 >
 > Rules marked with ⚙️ support customization options (e.g., extending default folder lists).
 
 | Rule | Description |
 |------|-------------|
+| **Array Rules** | |
 | `array-items-per-line` | Collapse arrays ≤ threshold to one line; expand larger arrays with each item on own line (default: ≤3) ⚙️ |
 | `array-objects-on-new-lines` | Each object in an array starts on its own line for better visual scanning |
+| **Arrow Function Rules** | |
 | `arrow-function-block-body` | Wrap multiline arrow function expressions in parentheses for clear boundaries |
 | `arrow-function-simple-jsx` | Collapse arrow functions returning simple single-element JSX to one line, remove unnecessary parens |
 | `arrow-function-simplify` | Convert block body with single return to implicit return: `() => { return x; }` → `() => x` |
 | `curried-arrow-same-line` | Curried arrow functions start on same line as `=>`, not on new line |
-| `assignment-value-same-line` | Assignment values start on same line as `=`, not on new line |
-| `block-statement-newlines` | Newline after `{` and before `}` in if/for/while/function blocks |
+| **Call Expression Rules** | |
+| `function-arguments-format` | Args ≥ threshold or multiline: first arg on new line, each on own line, closing `)` on new line (default: ≥2) ⚙️ |
+| `nested-call-closing-brackets` | Chain closing brackets on same line: `}));` not scattered across lines |
+| `no-empty-lines-in-function-calls` | No empty lines between arguments or after `(`/before `)` |
+| `opening-brackets-same-line` | Opening `{`, `[`, or `(` on same line as function call, not on new line |
+| `simple-call-single-line` | Collapse simple `fn(() => call())` patterns to single line |
+| `single-argument-on-one-line` | Single simple argument stays on one line: `fn(x)` not expanded |
+| **Comment Rules** | |
 | `comment-format` | Space after `//`, space inside `/* */`, convert single-line blocks to `//`, no blank lines between file-top comments |
+| **Component Rules** | |
+| `component-props-destructure` | Component props must be destructured `({ prop })` not received as `(props)` |
+| `component-props-inline-type` | Inline type annotation `} : {` with matching props, proper spacing, commas, no interface reference |
+| **Control Flow Rules** | |
+| `block-statement-newlines` | Newline after `{` and before `}` in if/for/while/function blocks |
+| `if-statement-format` | `{` on same line as `if`/`else if`, `else` on same line as `}`, proper spacing |
+| `multiline-if-conditions` | Conditions exceeding threshold get one operand per line with proper indentation (default: >3) ⚙️ |
+| `no-empty-lines-in-switch-cases` | No empty line after `case X:` before code, no empty lines between cases |
+| **Function Rules** | |
 | `function-call-spacing` | No space between function name and `(`: `fn()` not `fn ()` |
 | `function-naming-convention` | Functions use camelCase, start with verb (get/set/handle/is/has), handlers end with Handler |
+| `function-object-destructure` | Non-component functions: use typed params (not destructured), destructure in body; report dot notation access |
 | `function-params-per-line` | When multiline, each param on own line with consistent indentation |
+| `no-empty-lines-in-function-params` | No empty lines between parameters or after `(`/before `)` |
+| **Hook Rules** | |
 | `hook-callback-format` | React hooks: callback on new line, deps array on separate line, proper indentation |
 | `hook-deps-per-line` | Collapse deps ≤ threshold to one line; expand larger arrays with each dep on own line (default: >2) ⚙️ |
-| `if-statement-format` | `{` on same line as `if`/`else if`, `else` on same line as `}`, proper spacing |
-| `multiline-if-conditions` | Conditions exceeding threshold get one operand per line with proper indentation (default: >3) ⚙️ |
+| **Import/Export Rules** | |
 | `absolute-imports-only` | Use alias imports from index files only (not deep paths), no relative imports (default: `@/`) ⚙️ |
 | `export-format` | `export {` on same line; collapse ≤ threshold to one line; expand larger with each specifier on own line (default: ≤3) ⚙️ |
 | `import-format` | `import {` and `} from` on same line; collapse ≤ threshold; expand larger with each specifier on own line (default: ≤3) ⚙️ |
 | `import-source-spacing` | No leading/trailing spaces inside import path quotes |
 | `index-export-style` | Index files: no blank lines, enforce shorthand or import-export style; Regular files: require blank lines between exports (default: shorthand) ⚙️ |
 | `module-index-exports` | Index files must export all folder contents (files and subfolders) ⚙️ |
+| **JSX Rules** | |
 | `jsx-children-on-new-line` | Multiple JSX children: each on own line with proper indentation |
 | `jsx-closing-bracket-spacing` | No space before `>` or `/>` in JSX tags |
 | `jsx-element-child-new-line` | Nested JSX elements on new lines; text/expression children can stay inline |
@@ -271,21 +302,25 @@ rules: {
 | `jsx-simple-element-one-line` | Collapse simple JSX with single text/expression child to one line |
 | `jsx-string-value-trim` | No leading/trailing whitespace inside JSX string attribute values |
 | `jsx-ternary-format` | Simple ternaries on one line; complex branches get parens with proper indentation |
-| `member-expression-bracket-spacing` | No spaces inside brackets in computed member expressions: `arr[0]` not `arr[ 0 ]` |
-| `function-arguments-format` | Args ≥ threshold or multiline: first arg on new line, each on own line, closing `)` on new line (default: ≥2) ⚙️ |
-| `nested-call-closing-brackets` | Chain closing brackets on same line: `}));` not scattered across lines |
-| `no-empty-lines-in-function-calls` | No empty lines between arguments or after `(`/before `)` |
-| `no-empty-lines-in-function-params` | No empty lines between parameters or after `(`/before `)` |
 | `no-empty-lines-in-jsx` | No empty lines between children or after opening/before closing tags |
+| **Object Rules** | |
 | `no-empty-lines-in-objects` | No empty lines between properties or after `{`/before `}` |
-| `no-empty-lines-in-switch-cases` | No empty line after `case X:` before code, no empty lines between cases |
 | `object-property-per-line` | Collapse ≤ threshold to one line; expand larger with `{`/`}` on own lines and each property on own line (default: ≥2) ⚙️ |
 | `object-property-value-brace` | Opening `{` of object value on same line as `:`, not on new line |
 | `object-property-value-format` | Simple property values on same line as `:`, not on new line |
-| `opening-brackets-same-line` | Opening `{`, `[`, or `(` on same line as function call, not on new line |
-| `simple-call-single-line` | Collapse simple `fn(() => call())` patterns to single line |
-| `single-argument-on-one-line` | Single simple argument stays on one line: `fn(x)` not expanded |
 | `string-property-spacing` | No leading/trailing spaces inside string property keys |
+| **Spacing Rules** | |
+| `assignment-value-same-line` | Assignment values start on same line as `=`, not on new line |
+| `member-expression-bracket-spacing` | No spaces inside brackets in computed member expressions: `arr[0]` not `arr[ 0 ]` |
+| **TypeScript Rules** | |
+| `enum-format` | Enforce enum naming (PascalCase + Enum suffix), UPPER_CASE members, no empty lines, and trailing commas |
+| `interface-format` | Enforce interface naming (PascalCase + Interface suffix), camelCase properties, no empty lines, and trailing commas |
+| `type-annotation-spacing` | Enforce consistent spacing in type annotations: no space before colon/generic/array brackets, one space after colon |
+| `type-format` | Enforce type naming (PascalCase + Type suffix), camelCase properties, no empty lines, and trailing commas |
+| `typescript-definition-location` | Enforce TypeScript definitions (interfaces, types, enums) to be in designated folders ⚙️ |
+| **React Rules** | |
+| `react-code-order` | Enforce consistent ordering in components and hooks: props destructure → refs → state → redux → router → context → custom hooks → derived → memo → callback → handlers → effects → return |
+| **Variable Rules** | |
 | `variable-naming-convention` | camelCase for variables, UPPER_CASE for constants, PascalCase for components, `use` prefix for hooks |
 
 <br />
@@ -484,412 +519,363 @@ const mapDispatch = () =>
 
 <br />
 
-## 📐 Spacing & Formatting Rules
+## 📞 Call Expression Rules
 
-### `assignment-value-same-line`
+### `function-arguments-format`
 
-**What it does:** Ensures the assigned value starts on the same line as the `=` sign, not on a new line.
+**What it does:** Enforces consistent formatting for function call arguments:
+- Single simple argument stays on one line
+- 2+ arguments get one per line
+- Multiline arguments trigger full expansion
+- React hooks are skipped by default (they have their own rule)
 
-**Why use it:** Breaking after `=` creates awkward formatting and wastes vertical space. Keeping values on the same line as `=` is more readable.
+**Why use it:** Consistent argument formatting makes function calls scannable and diffs clean when adding/removing arguments.
 
 ```javascript
-// ✅ Good — value starts on same line as =
-const name = "John";
-const config = {
-    host: "localhost",
-    port: 3000,
-};
-const items = [
-    "first",
-    "second",
-];
-
-// ❌ Bad — value on new line after =
-const name =
-    "John";
-const config =
-    {
-        host: "localhost",
-        port: 3000,
-    };
-const items =
-    [
-        "first",
-        "second",
-    ];
-```
-
----
-
-### `block-statement-newlines`
-
-**What it does:** Enforces newlines after the opening brace `{` and before the closing brace `}` in block statements (if, for, while, etc.).
-
-**Why use it:** Consistent block formatting improves readability. Single-line blocks are harder to scan and edit.
+// ✅ Good — single argument stays compact
+fetchUser(userId);
+console.log(message);
+dispatch(action);
 
-```javascript
-// ✅ Good — proper block formatting
-if (condition) {
-    doSomething();
-}
+// ✅ Good — 2+ arguments get one per line
+setValue(
+    "email",
+    "user@example.com",
+);
 
-for (const item of items) {
-    process(item);
-}
+createUser(
+    name,
+    email,
+    password,
+);
 
-while (running) {
-    tick();
-}
+// ✅ Good — multiline argument triggers expansion
+processData(
+    {
+        id: 1,
+        name: "test",
+    },
+);
 
-// ❌ Bad — everything on one line
-if (condition) { doSomething(); }
+// ✅ Good — callback with body triggers expansion
+items.forEach(
+    (item) => {
+        process(item);
+        save(item);
+    },
+);
 
-// ❌ Bad — no space after brace
-if (condition) {doSomething();}
+// ❌ Bad — multiple arguments on same line
+setValue("email", "user@example.com");
+createUser(name, email, password);
 
 // ❌ Bad — inconsistent formatting
-for (const item of items) { process(item);
-}
+fn(arg1,
+    arg2, arg3);
 ```
 
----
-
-### `comment-format`
-
-**What it does:** Enforces proper comment formatting:
-- Space after `//` in line comments
-- Space after `/*` and before `*/` in block comments
-- Single-line block comments converted to line comments
-- No blank lines between consecutive comments at file top
+**Options:**
 
-**Why use it:** Consistent comment formatting improves readability and maintains a clean, professional codebase.
+| Option | Type | Default | Description |
+|--------|------|---------|-------------|
+| `minArgs` | `integer` | `2` | Minimum arguments to enforce multiline |
+| `skipHooks` | `boolean` | `true` | Skip React hooks (useEffect, etc.) |
+| `skipSingleArg` | `boolean` | `true` | Skip calls with single complex argument |
 
 ```javascript
-// ✅ Good — proper spacing
-// This is a comment
-/* This is a block comment */
-
-/*
- * This is a multi-line
- * block comment
- */
-
-// ✅ Good — file-top comments without gaps
-// File: utils.js
-// Author: John Doe
-// License: MIT
-
-// ❌ Bad — missing space after //
-//This is a comment
-
-// ❌ Bad — no space in block comment
-/*No space*/
+// Example: Require multiline for 3+ arguments
+"code-style/function-arguments-format": ["error", { minArgs: 3 }]
 
-// ❌ Bad — single-line block should be line comment
-/* This should use // syntax */
+// Example: Don't skip React hooks
+"code-style/function-arguments-format": ["error", { skipHooks: false }]
 ```
 
 ---
 
-### `member-expression-bracket-spacing`
+### `nested-call-closing-brackets`
 
-**What it does:** Removes spaces inside brackets in computed member expressions (array access, dynamic property access).
+**What it does:** Ensures nested function calls (common in styled-components, HOCs) have closing brackets on the same line: `}));`
 
-**Why use it:** Consistent with JavaScript conventions. Spaces inside brackets look inconsistent with array literals and other bracket usage.
+**Why use it:** Scattered closing brackets (`}\n);\n` ) waste vertical space and make it harder to see where expressions end.
 
 ```javascript
-// ✅ Good — no spaces inside brackets
-const value = arr[0];
-const name = obj[key];
-const item = data[index];
-const nested = matrix[row][col];
+// ✅ Good — closing brackets together
+const StyledCard = styled(Card)(({ theme }) => ({
+    color: theme.palette.text.primary,
+    padding: theme.spacing(2),
+}));
 
-// ❌ Bad — spaces inside brackets
-const value = arr[ 0 ];
-const name = obj[ key ];
-const item = data[ index ];
+const StyledButton = styled("button")(({ theme }) => ({
+    backgroundColor: theme.colors.primary,
+}));
+
+// ✅ Good — multiple levels
+const Component = connect(
+    mapStateToProps,
+    mapDispatchToProps,
+)(withRouter(MyComponent));
+
+// ❌ Bad — closing brackets scattered
+const StyledCard = styled(Card)(({ theme }) => ({
+    color: theme.palette.text.primary,
+})
+);
+
+// ❌ Bad — each bracket on its own line
+const StyledCard = styled(Card)(({ theme }) => ({
+    color: theme.colors.primary,
+})
+)
+;
 ```
 
 ---
 
-### `no-empty-lines-in-function-params`
+### `no-empty-lines-in-function-calls`
 
-**What it does:** Removes empty lines within function parameter lists — between parameters and after opening/before closing parentheses.
+**What it does:** Removes empty lines within function call argument lists — between arguments and after opening/before closing parentheses.
 
-**Why use it:** Empty lines in parameter lists waste space and make parameters harder to scan as a group.
+**Why use it:** Empty lines between arguments break visual grouping. Arguments should flow as a cohesive list.
 
 ```javascript
 // ✅ Good — no empty lines
-function createUser(
+createUser(
     name,
     email,
+    password,
     role,
-) {}
+);
 
-const handler = (
-    event,
-    context,
-) => {};
+fetchData(
+    url,
+    {
+        method: "POST",
+        body: data,
+    },
+);
 
-// ❌ Bad — empty line between params
-function createUser(
+// ❌ Bad — empty line between arguments
+createUser(
     name,
 
     email,
 
-    role,
-) {}
+    password,
+);
 
 // ❌ Bad — empty line after opening paren
-const handler = (
+fetchData(
 
-    event,
-    context,
-) => {};
+    url,
+    options,
+);
+
+// ❌ Bad — empty line before closing paren
+fetchData(
+    url,
+    options,
+
+);
 ```
 
 ---
 
-### `variable-naming-convention`
+### `opening-brackets-same-line`
 
-**What it does:** Enforces naming conventions for variables:
-- **camelCase** for regular variables and functions
-- **UPPER_CASE** for constants (primitive values)
-- **PascalCase** for React components and classes
-- **camelCase with `use` prefix** for hooks
+**What it does:** Ensures opening brackets (`{`, `[`, `(`) in function arguments stay on the same line as the function call.
 
-**Why use it:** Consistent naming makes code predictable. You can tell what something is by how it's named.
+**Why use it:** Opening brackets on new lines create unnecessary indentation and vertical space.
 
 ```javascript
-// ✅ Good — correct conventions
-const userName = "John";           // camelCase for variables
-const itemCount = 42;              // camelCase for variables
-const MAX_RETRIES = 3;             // UPPER_CASE for constants
-const API_BASE_URL = "/api";       // UPPER_CASE for constants
-const UserProfile = () => <div />; // PascalCase for components
-const useAuth = () => {};          // camelCase with use prefix for hooks
+// ✅ Good — brackets on same line as call
+fn({ key: value });
+process([1, 2, 3]);
+items.map(({ id }) => id);
+configure({ debug: true });
 
-// ❌ Bad — wrong conventions
-const user_name = "John";          // snake_case
-const maxretries = 3;              // should be UPPER_CASE
-const userProfile = () => <div />; // should be PascalCase
-const UseAuth = () => {};          // hooks should be camelCase
-```
+// ✅ Good — multiline content is fine
+fn({
+    key: value,
+    other: data,
+});
 
-<br />
+items.map(({ id, name }) => (
+    <Item key={id} name={name} />
+));
 
-## ⚡ Function Rules
+// ❌ Bad — opening bracket on new line
+fn(
+    { key: value }
+);
 
-### `function-call-spacing`
+process(
+    [1, 2, 3]
+);
 
-**What it does:** Removes any space between a function name and its opening parenthesis.
+items.map(
+    ({ id }) => id
+);
+```
 
-**Why use it:** Standard JavaScript convention. `fn()` is correct, `fn ()` looks like a typo and can cause confusion.
+---
+
+### `simple-call-single-line`
+
+**What it does:** Collapses simple function calls with an arrow function containing a single call expression onto one line.
+
+**Why use it:** Common patterns like `lazy(() => import(...))` don't need multiline formatting. Single line is cleaner.
 
 ```javascript
-// ✅ Good — no space before parenthesis
-useDispatch();
-myFunction(arg);
-console.log("message");
-array.map((x) => x * 2);
-obj.method();
+// ✅ Good — simple patterns on one line
+const Page = lazy(() => import("./Page"));
+const Modal = lazy(() => import("./Modal"));
+setTimeout(() => callback(), 100);
+requestAnimationFrame(() => render());
+items.filter(() => isValid(item));
 
-// ❌ Bad — space before parenthesis
-useDispatch ();
-myFunction (arg);
-console.log ("message");
-array.map ((x) => x * 2);
+// ✅ Good — complex callbacks stay multiline
+const Page = lazy(() => {
+    console.log("Loading page");
+    return import("./Page");
+});
+
+// ❌ Bad — unnecessary multiline for simple pattern
+const Page = lazy(
+    () => import("./Page"),
+);
+
+setTimeout(
+    () => callback(),
+    100,
+);
 ```
 
 ---
 
-### `function-naming-convention`
+### `single-argument-on-one-line`
 
-**What it does:** Enforces naming conventions for functions:
-- **camelCase** required
-- **Verb prefix** recommended (get, set, handle, is, has, can, should, etc.)
-- **Event handlers** can use `handle` prefix or `Handler` suffix
+**What it does:** Ensures function calls with a single simple argument (literal, identifier, member expression) stay on one line.
 
-**Why use it:** Function names should describe actions. Verb prefixes make the purpose immediately clear.
+**Why use it:** Single-argument calls don't need multiline formatting. Expanding them wastes vertical space.
 
 ```javascript
-// ✅ Good — clear verb prefixes
-function getUserData() {}
-function setUserName(name) {}
-function handleClick() {}
-function handleSubmit() {}
-function isValidEmail(email) {}
-function hasPermission(user) {}
-function canAccess(resource) {}
-function shouldUpdate(props) {}
-const fetchUsers = async () => {};
-const submitHandler = () => {};
+// ✅ Good — single argument on one line
+fetchUser(userId);
+console.log(message);
+process(data.items);
+dispatch(action);
+setValue("key");
+getElement(document.body);
 
-// ❌ Bad — no verb, unclear purpose
-function userData() {}
-function userName(name) {}
-function click() {}
-function valid(email) {}
+// ✅ Good — complex single argument can be multiline
+processConfig({
+    key: value,
+    other: data,
+});
 
-// ❌ Bad — wrong case
-function GetUserData() {}
-function get_user_data() {}
+// ❌ Bad — simple argument expanded unnecessarily
+fetchUser(
+    userId,
+);
+
+console.log(
+    message,
+);
+
+dispatch(
+    action,
+);
 ```
 
----
+<br />
 
-### `function-params-per-line`
+## 💬 Comment Rules
 
-**What it does:** When function parameters span multiple lines, ensures each parameter is on its own line with consistent indentation.
+### `comment-format`
 
-**Why use it:** Mixed formatting (some params on same line, some on different lines) is confusing. One per line is scannable and easy to edit.
+**What it does:** Enforces proper comment formatting:
+- Space after `//` in line comments
+- Space after `/*` and before `*/` in block comments
+- Single-line block comments converted to line comments
+- No blank lines between consecutive comments at file top
+
+**Why use it:** Consistent comment formatting improves readability and maintains a clean, professional codebase.
 
 ```javascript
-// ✅ Good — each param on own line
-function createUser(
-    name,
-    email,
-    password,
-    role,
-) {}
+// ✅ Good — proper spacing
+// This is a comment
+/* This is a block comment */
 
-const handler = (
-    event,
-    context,
-    callback,
-) => {};
+/*
+ * This is a multi-line
+ * block comment
+ */
 
-// ✅ Good — short params can stay on one line
-function add(a, b) {}
+// ✅ Good — file-top comments without gaps
+// File: utils.js
+// Author: John Doe
+// License: MIT
 
-// ❌ Bad — mixed formatting
-function createUser(name,
-    email, password,
-    role) {}
+// ❌ Bad — missing space after //
+//This is a comment
 
-// ❌ Bad — some on same line, some not
-const handler = (event, context,
-    callback) => {};
+// ❌ Bad — no space in block comment
+/*No space*/
+
+// ❌ Bad — single-line block should be line comment
+/* This should use // syntax */
 ```
 
 <br />
 
-## 🪝 React Hooks Rules
+## 🔀 Control Flow Rules
 
-### `hook-callback-format`
+### `block-statement-newlines`
 
-**What it does:** Enforces consistent multi-line formatting for React hooks that take a callback and dependency array (useEffect, useCallback, useMemo, useLayoutEffect).
+**What it does:** Enforces newlines after the opening brace `{` and before the closing brace `}` in block statements (if, for, while, etc.).
 
-**Why use it:** Hooks with callbacks and dependencies are complex. Multi-line formatting makes the callback, return cleanup, and dependencies clearly visible.
+**Why use it:** Consistent block formatting improves readability. Single-line blocks are harder to scan and edit.
 
 ```javascript
-// ✅ Good — callback and deps clearly separated
-useEffect(
-    () => {
-        fetchData();
-    },
-    [userId],
-);
-
-useCallback(
-    () => {
-        handleSubmit(data);
-    },
-    [data, handleSubmit],
-);
+// ✅ Good — proper block formatting
+if (condition) {
+    doSomething();
+}
 
-useMemo(
-    () => expensiveCalculation(items),
-    [items],
-);
+for (const item of items) {
+    process(item);
+}
 
-// ✅ Good — cleanup function visible
-useEffect(
-    () => {
-        const subscription = subscribe();
+while (running) {
+    tick();
+}
 
-        return () => subscription.unsubscribe();
-    },
-    [subscribe],
-);
+// ❌ Bad — everything on one line
+if (condition) { doSomething(); }
 
-// ❌ Bad — everything crammed on one line
-useEffect(() => { fetchData(); }, [userId]);
+// ❌ Bad — no space after brace
+if (condition) {doSomething();}
 
-// ❌ Bad — hard to see dependencies
-useCallback(() => { handleSubmit(data); }, [data, handleSubmit]);
+// ❌ Bad — inconsistent formatting
+for (const item of items) { process(item);
+}
 ```
 
 ---
 
-### `hook-deps-per-line`
+### `if-statement-format`
 
-**What it does:** When a hook's dependency array exceeds the threshold (default: 2), each dependency goes on its own line.
+**What it does:** Enforces consistent if/else formatting:
+- Opening `{` on the same line as `if`/`else if`/`else`
+- `else` on the same line as the closing `}`
+- Proper spacing around keywords
 
-**Why use it:** Long dependency arrays are hard to scan and diff. One per line makes it easy to see what changed and catch missing/extra dependencies.
+**Why use it:** Consistent brace placement reduces visual noise and follows the most common JavaScript style (K&R / "one true brace style").
 
 ```javascript
-// ✅ Good — 2 or fewer deps stay inline
-useEffect(() => {}, [userId]);
-useEffect(() => {}, [userId, token]);
-
-// ✅ Good — 3+ deps get one per line
-useEffect(
-    () => {},
-    [
-        userId,
-        token,
-        refreshToken,
-    ],
-);
-
-useCallback(
-    () => handleSubmit(data),
-    [
-        data,
-        handleSubmit,
-        validateForm,
-        showError,
-    ],
-);
-
-// ❌ Bad — too many deps on one line
-useEffect(() => {}, [userId, token, refreshToken, apiUrl]);
-
-// ❌ Bad — deps should be one per line when expanded
-useEffect(() => {}, [
-    userId, token, refreshToken,
-]);
-```
-
-**Options:**
-
-| Option | Type | Default | Description |
-|--------|------|---------|-------------|
-| `maxDeps` | `integer` | `2` | Maximum dependencies to keep on single line |
-
-```javascript
-// Example: Allow up to 3 dependencies on single line
-"code-style/hook-deps-per-line": ["error", { maxDeps: 3 }]
-```
-
-<br />
-
-## 🔀 Control Flow Rules
-
-### `if-statement-format`
-
-**What it does:** Enforces consistent if/else formatting:
-- Opening `{` on the same line as `if`/`else if`/`else`
-- `else` on the same line as the closing `}`
-- Proper spacing around keywords
-
-**Why use it:** Consistent brace placement reduces visual noise and follows the most common JavaScript style (K&R / "one true brace style").
-
-```javascript
-// ✅ Good — consistent formatting
-if (condition) {
-    doSomething();
+// ✅ Good — consistent formatting
+if (condition) {
+    doSomething();
 
     doMore();
 }
@@ -1059,336 +1045,622 @@ switch (status) {
 
 <br />
 
-## 📥 Import/Export Rules
+## ⚡ Function Rules
 
-### `absolute-imports-only`
+### `function-call-spacing`
 
-**What it does:** Enforces importing from folder index files using absolute paths (aliases like `@/`) instead of relative paths or deep file imports.
+**What it does:** Removes any space between a function name and its opening parenthesis.
 
-**Why use it:**
-- Absolute imports are cleaner than `../../../components`
-- Index imports create a public API for each folder
-- Refactoring file locations doesn't break imports
-- Encourages proper module organization
+**Why use it:** Standard JavaScript convention. `fn()` is correct, `fn ()` looks like a typo and can cause confusion.
 
 ```javascript
-// ✅ Good — import from index files using alias
-import { Button, Input } from "@/components";
-import { useAuth, useUser } from "@/hooks";
-import { fetchUsers } from "@/apis";
-import { formatDate } from "@/utils";
-
-// ✅ Good — assets allow deep imports by default
-import logo from "@/assets/images/logo.png";
-
-// ❌ Bad — relative imports
-import { Button } from "../../components";
-import { useAuth } from "../../../hooks";
+// ✅ Good — no space before parenthesis
+useDispatch();
+myFunction(arg);
+console.log("message");
+array.map((x) => x * 2);
+obj.method();
 
-// ❌ Bad — deep imports into component internals
-import { Button } from "@/components/buttons/primary-button";
-import { useAuth } from "@/hooks/auth/useAuth";
-import { fetchUsers } from "@/apis/users/fetchUsers";
+// ❌ Bad — space before parenthesis
+useDispatch ();
+myFunction (arg);
+console.log ("message");
+array.map ((x) => x * 2);
 ```
 
-**Default Allowed Folders:**
-`actions`, `apis`, `assets`, `atoms`, `components`, `constants`, `contexts`, `data`, `hooks`, `layouts`, `middlewares`, `providers`, `reducers`, `redux`, `requests`, `routes`, `schemas`, `services`, `store`, `styles`, `theme`, `thunks`, `types`, `utils`, `views`
+---
 
-**Customization Options:**
+### `function-naming-convention`
 
-| Option | Type | Description |
-|--------|------|-------------|
-| `extraAllowedFolders` | `string[]` | Add extra folders to the default list |
-| `extraReduxSubfolders` | `string[]` | Add extra redux subfolders (default: `actions`, `reducers`, `store`, `thunks`, `types`) |
-| `extraDeepImportFolders` | `string[]` | Add extra folders that allow deep imports (default: `assets`) |
-| `aliasPrefix` | `string` | Change the import alias prefix (default: `@/`) |
-| `allowedFolders` | `string[]` | Replace default folders entirely |
-| `reduxSubfolders` | `string[]` | Replace default redux subfolders entirely |
-| `deepImportFolders` | `string[]` | Replace default deep import folders entirely |
+**What it does:** Enforces naming conventions for functions:
+- **camelCase** required
+- **Verb prefix** recommended (get, set, handle, is, has, can, should, etc.)
+- **Event handlers** can use `handle` prefix or `Handler` suffix
+
+**Why use it:** Function names should describe actions. Verb prefixes make the purpose immediately clear.
 
 ```javascript
-// Example: Add custom folders to the defaults
-"code-style/absolute-imports-only": ["error", {
-    extraAllowedFolders: ["features", "modules", "lib"],
-    extraDeepImportFolders: ["images", "fonts"]
-}]
+// ✅ Good — clear verb prefixes
+function getUserData() {}
+function setUserName(name) {}
+function handleClick() {}
+function handleSubmit() {}
+function isValidEmail(email) {}
+function hasPermission(user) {}
+function canAccess(resource) {}
+function shouldUpdate(props) {}
+const fetchUsers = async () => {};
+const submitHandler = () => {};
+
+// ❌ Bad — no verb, unclear purpose
+function userData() {}
+function userName(name) {}
+function click() {}
+function valid(email) {}
+
+// ❌ Bad — wrong case
+function GetUserData() {}
+function get_user_data() {}
 ```
 
 ---
 
-### `export-format`
+### `function-object-destructure`
 
-**What it does:** Formats export statements consistently:
-- `export {` always on the same line as `export` keyword
-- ≤3 specifiers stay on one line (collapsed)
-- 4+ specifiers get one per line (expanded)
-- Proper spacing and trailing commas
+**What it does:** Enforces that non-component functions should not destructure parameters in the function signature. Instead, use a typed parameter and destructure at the top of the function body. Also reports when parameters are accessed via dot notation (suggesting destructuring).
 
-**Why use it:** Consistent export formatting improves readability. Short exports stay compact, long exports become scannable.
+**Why use it:** Keeping function signatures clean and short improves readability. Destructuring in the body makes it clear what properties are being used. For React components, this rule does NOT apply — components should destructure props in the signature.
 
-```javascript
-// ✅ Good — 3 or fewer specifiers stay compact
-export { Button };
-export { Button, Input };
-export { Button, Input, Select };
+```typescript
+// ✅ Good — typed param with destructuring in body
+const createUserHandler = async (data: CreateUserParamsInterface) => {
+    const { age, email, isActive, name } = data;
 
-// ✅ Good — 4+ specifiers expand with one per line
-export {
-    Button,
-    Input,
-    Select,
-    Checkbox,
+    // Use age, email, isActive, name...
 };
 
-// ✅ Good — re-exports follow same rules
-export { Button, Input, Select } from "./components";
-export {
-    createUser,
-    updateUser,
-    deleteUser,
-    getUser,
-} from "./api";
+const updateUserHandler = (params: UpdateParamsInterface) => {
+    const { id, updates } = params;
 
-// ❌ Bad — no spaces
-export {Button,Input,Select};
-
-// ❌ Bad — keyword on different line
-export
-    { Button };
-
-// ❌ Bad — too many on one line
-export { Button, Input, Select, Checkbox, Radio };
-```
+    // Use id, updates...
+};
 
-**Options:**
+// ✅ Good — React components CAN destructure in signature
+const UserCard = ({
+    name,
+    email,
+} : {
+    name: string,
+    email: string,
+}) => (
+    <div>{name} - {email}</div>
+);
 
-| Option | Type | Default | Description |
-|--------|------|---------|-------------|
-| `maxSpecifiers` | `integer` | `3` | Maximum specifiers to keep on single line |
+// ❌ Bad — non-component function destructures in signature
+const createUserHandler = async ({
+    age,
+    email,
+    isActive,
+    name,
+}: CreateUserParamsInterface) => {
+    // ...
+};
 
-```javascript
-"code-style/export-format": ["error", { maxSpecifiers: 4 }]
+// ❌ Bad — accessing param via dot notation (should destructure)
+const processDataHandler = (data: DataInterface) => {
+    console.log(data.id);      // Bad: use destructuring
+    console.log(data.name);    // Bad: use destructuring
+    return data.value * 2;     // Bad: use destructuring
+};
 ```
 
 ---
 
-### `import-format`
+### `function-params-per-line`
 
-**What it does:** Formats import statements consistently:
-- `import {` on the same line as `import` keyword
-- `} from` on the same line as closing brace
-- ≤3 specifiers stay on one line (collapsed)
-- 4+ specifiers get one per line (expanded)
+**What it does:** When function parameters span multiple lines, ensures each parameter is on its own line with consistent indentation.
 
-**Why use it:** Consistent import formatting improves readability and makes diffs cleaner when adding/removing imports.
+**Why use it:** Mixed formatting (some params on same line, some on different lines) is confusing. One per line is scannable and easy to edit.
 
 ```javascript
-// ✅ Good — 3 or fewer specifiers stay compact
-import { useState } from "react";
-import { Button, Input } from "@/components";
-import { get, post, put } from "@/api";
+// ✅ Good — each param on own line
+function createUser(
+    name,
+    email,
+    password,
+    role,
+) {}
 
-// ✅ Good — 4+ specifiers expand with one per line
-import {
-    useState,
-    useEffect,
-    useCallback,
-    useMemo,
-} from "react";
+const handler = (
+    event,
+    context,
+    callback,
+) => {};
 
-import {
-    Button,
-    Input,
-    Select,
-    Checkbox,
-} from "@/components";
+// ✅ Good — short params can stay on one line
+function add(a, b) {}
 
-// ❌ Bad — no spaces
-import {useState,useEffect} from "react";
+// ❌ Bad — mixed formatting
+function createUser(name,
+    email, password,
+    role) {}
 
-// ❌ Bad — keyword on different line
-import
-    { Button } from "@/components";
+// ❌ Bad — some on same line, some not
+const handler = (event, context,
+    callback) => {};
+```
 
-// ❌ Bad — from on different line
-import { Button }
-    from "@/components";
+---
 
-// ❌ Bad — too many on one line
-import { useState, useEffect, useCallback, useMemo, useRef } from "react";
-```
+### `no-empty-lines-in-function-params`
 
-**Options:**
+**What it does:** Removes empty lines within function parameter lists — between parameters and after opening/before closing parentheses.
 
-| Option | Type | Default | Description |
-|--------|------|---------|-------------|
-| `maxSpecifiers` | `integer` | `3` | Maximum specifiers to keep on single line |
+**Why use it:** Empty lines in parameter lists waste space and make parameters harder to scan as a group.
 
 ```javascript
-"code-style/import-format": ["error", { maxSpecifiers: 4 }]
+// ✅ Good — no empty lines
+function createUser(
+    name,
+    email,
+    role,
+) {}
+
+const handler = (
+    event,
+    context,
+) => {};
+
+// ❌ Bad — empty line between params
+function createUser(
+    name,
+
+    email,
+
+    role,
+) {}
+
+// ❌ Bad — empty line after opening paren
+const handler = (
+
+    event,
+    context,
+) => {};
 ```
 
----
+<br />
 
-### `import-source-spacing`
+## 🪝 Hook Rules
 
-**What it does:** Removes any leading or trailing whitespace inside import path strings.
+### `hook-callback-format`
 
-**Why use it:** Spaces in module paths are almost always typos and can cause import resolution issues.
+**What it does:** Enforces consistent multi-line formatting for React hooks that take a callback and dependency array (useEffect, useCallback, useMemo, useLayoutEffect).
+
+**Why use it:** Hooks with callbacks and dependencies are complex. Multi-line formatting makes the callback, return cleanup, and dependencies clearly visible.
 
 ```javascript
-// ✅ Good — no extra spaces
-import { Button } from "@mui/material";
-import React from "react";
-import styles from "./styles.css";
+// ✅ Good — callback and deps clearly separated
+useEffect(
+    () => {
+        fetchData();
+    },
+    [userId],
+);
 
-// ❌ Bad — leading space
-import { Button } from " @mui/material";
+useCallback(
+    () => {
+        handleSubmit(data);
+    },
+    [data, handleSubmit],
+);
 
-// ❌ Bad — trailing space
-import React from "react ";
+useMemo(
+    () => expensiveCalculation(items),
+    [items],
+);
 
-// ❌ Bad — both
-import styles from " ./styles.css ";
+// ✅ Good — cleanup function visible
+useEffect(
+    () => {
+        const subscription = subscribe();
+
+        return () => subscription.unsubscribe();
+    },
+    [subscribe],
+);
+
+// ❌ Bad — everything crammed on one line
+useEffect(() => { fetchData(); }, [userId]);
+
+// ❌ Bad — hard to see dependencies
+useCallback(() => { handleSubmit(data); }, [data, handleSubmit]);
 ```
 
 ---
 
-### `index-export-style`
+### `hook-deps-per-line`
 
-**What it does:** Enforces different export formatting rules for index files vs regular files:
-- **Index files**: No blank lines between exports, use shorthand or import-export style
-- **Regular files**: Require blank lines between exports
+**What it does:** When a hook's dependency array exceeds the threshold (default: 2), each dependency goes on its own line.
 
-**Why use it:** Index files are re-export aggregators and should be compact. Regular files benefit from spacing between exports for readability.
+**Why use it:** Long dependency arrays are hard to scan and diff. One per line makes it easy to see what changed and catch missing/extra dependencies.
 
-**Regular files (non-index):**
 ```javascript
-// ✅ Good — blank lines between exports
-export const API_URL = "/api";
-
-export const MAX_RETRIES = 3;
-
-export const fetchData = async () => {};
+// ✅ Good — 2 or fewer deps stay inline
+useEffect(() => {}, [userId]);
+useEffect(() => {}, [userId, token]);
 
-// ❌ Bad — no blank lines in regular file
-export const API_URL = "/api";
-export const MAX_RETRIES = 3;
-export const fetchData = async () => {};
-```
+// ✅ Good — 3+ deps get one per line
+useEffect(
+    () => {},
+    [
+        userId,
+        token,
+        refreshToken,
+    ],
+);
 
-**Index files — Style: "shorthand" (default):**
-```javascript
-// ✅ Good — shorthand re-exports, no blank lines
-export { Button } from "./button";
-export { Input, Select } from "./form";
-export { Modal } from "./modal";
-export { useAuth, useUser } from "./hooks";
-```
+useCallback(
+    () => handleSubmit(data),
+    [
+        data,
+        handleSubmit,
+        validateForm,
+        showError,
+    ],
+);
 
-**Index files — Style: "import-export":**
-```javascript
-// ✅ Good — imports grouped, single export at bottom
-import { Button } from "./button";
-import { Input, Select } from "./form";
-import { Modal } from "./modal";
+// ❌ Bad — too many deps on one line
+useEffect(() => {}, [userId, token, refreshToken, apiUrl]);
 
-export {
-    Button,
-    Input,
-    Modal,
-    Select,
-};
+// ❌ Bad — deps should be one per line when expanded
+useEffect(() => {}, [
+    userId, token, refreshToken,
+]);
 ```
 
 **Options:**
 
 | Option | Type | Default | Description |
 |--------|------|---------|-------------|
-| `style` | `"shorthand"` \| `"import-export"` | `"shorthand"` | Export style for index files |
+| `maxDeps` | `integer` | `2` | Maximum dependencies to keep on single line |
 
 ```javascript
-"code-style/index-export-style": ["error", { style: "import-export" }]
+// Example: Allow up to 3 dependencies on single line
+"code-style/hook-deps-per-line": ["error", { maxDeps: 3 }]
 ```
 
----
+<br />
 
-### `module-index-exports`
+## 📥 Import/Export Rules
 
-**What it does:** Ensures module folders have index files that export all their contents, creating a proper public API for each module.
+### `absolute-imports-only`
 
-**Why use it:** Index files allow importing from the folder level (`@/components`) instead of deep paths (`@/components/Button/Button`). This enforces proper module boundaries.
+**What it does:** Enforces importing from folder index files using absolute paths (aliases like `@/`) instead of relative paths or deep file imports.
+
+**Why use it:**
+- Absolute imports are cleaner than `../../../components`
+- Index imports create a public API for each folder
+- Refactoring file locations doesn't break imports
+- Encourages proper module organization
 
 ```javascript
-// ✅ Good — components/index.js exports everything
-export { Button } from "./Button";
-export { Input } from "./Input";
-export { Select } from "./Select";
-export { Modal } from "./Modal";
+// ✅ Good — import from index files using alias
+import { Button, Input } from "@/components";
+import { useAuth, useUser } from "@/hooks";
+import { fetchUsers } from "@/apis";
+import { formatDate } from "@/utils";
 
-// Then consumers can import cleanly:
-import { Button, Input, Select } from "@/components";
+// ✅ Good — assets allow deep imports by default
+import logo from "@/assets/images/logo.png";
 
-// ❌ Bad — missing exports in index.js
-// If Button exists but isn't exported from index.js,
-// consumers have to use deep imports:
-import { Button } from "@/components/Button/Button"; // Avoid this!
-```
+// ❌ Bad — relative imports
+import { Button } from "../../components";
+import { useAuth } from "../../../hooks";
 
-**Default Module Folders:**
-`apis`, `assets`, `atoms`, `components`, `constants`, `contexts`, `data`, `hooks`, `layouts`, `middlewares`, `providers`, `redux`, `requests`, `routes`, `schemas`, `services`, `styles`, `theme`, `utils`, `views`
+// ❌ Bad — deep imports into component internals
+import { Button } from "@/components/buttons/primary-button";
+import { useAuth } from "@/hooks/auth/useAuth";
+import { fetchUsers } from "@/apis/users/fetchUsers";
+```
 
-**Default Ignore Patterns:**
-`index.js`, `index.jsx`, `index.ts`, `index.tsx`, `.DS_Store`, `__tests__`, `__mocks__`, `*.test.js`, `*.test.jsx`, `*.test.ts`, `*.test.tsx`, `*.spec.js`, `*.spec.jsx`, `*.spec.ts`, `*.spec.tsx`
+**Default Allowed Folders:**
+`actions`, `apis`, `assets`, `atoms`, `components`, `config`, `configs`, `constants`, `contexts`, `data`, `enums`, `helpers`, `hooks`, `interfaces`, `layouts`, `lib`, `middlewares`, `providers`, `reducers`, `redux`, `requests`, `routes`, `schemas`, `services`, `store`, `styles`, `theme`, `thunks`, `types`, `ui`, `utils`, `utilities`, `views`
 
 **Customization Options:**
 
 | Option | Type | Description |
 |--------|------|-------------|
-| `extraModuleFolders` | `string[]` | Add extra module folders to the default list |
-| `extraLazyLoadFolders` | `string[]` | Add extra lazy load folders (default: `views`) |
-| `extraIgnorePatterns` | `string[]` | Add extra ignore patterns (supports wildcards) |
-| `moduleFolders` | `string[]` | Replace default module folders entirely |
-| `lazyLoadFolders` | `string[]` | Replace default lazy load folders entirely |
-| `ignorePatterns` | `string[]` | Replace default ignore patterns entirely |
+| `extraAllowedFolders` | `string[]` | Add extra folders to the default list |
+| `extraReduxSubfolders` | `string[]` | Add extra redux subfolders (default: `actions`, `reducers`, `store`, `thunks`, `types`) |
+| `extraDeepImportFolders` | `string[]` | Add extra folders that allow deep imports (default: `assets`) |
+| `aliasPrefix` | `string` | Change the import alias prefix (default: `@/`) |
+| `allowedFolders` | `string[]` | Replace default folders entirely |
+| `reduxSubfolders` | `string[]` | Replace default redux subfolders entirely |
+| `deepImportFolders` | `string[]` | Replace default deep import folders entirely |
 
 ```javascript
-// Example: Add custom folders and patterns
-"code-style/module-index-exports": ["error", {
-    extraModuleFolders: ["features", "modules", "lib"],
-    extraLazyLoadFolders: ["pages"],
-    extraIgnorePatterns: ["*.stories.js", "*.mock.js"]
+// Example: Add custom folders to the defaults
+"code-style/absolute-imports-only": ["error", {
+    extraAllowedFolders: ["features", "modules", "lib"],
+    extraDeepImportFolders: ["images", "fonts"]
 }]
 ```
 
-<br />
-
-## ⚛️ JSX Rules
+---
 
-### `jsx-children-on-new-line`
+### `export-format`
 
-**What it does:** When a JSX element has multiple children, ensures each child is on its own line with proper indentation.
+**What it does:** Formats export statements consistently:
+- `export {` always on the same line as `export` keyword
+- ≤3 specifiers stay on one line (collapsed)
+- 4+ specifiers get one per line (expanded)
+- Proper spacing and trailing commas
 
-**Why use it:** Multiple children on one line are hard to scan. Individual lines make the component structure clear.
+**Why use it:** Consistent export formatting improves readability. Short exports stay compact, long exports become scannable.
 
 ```javascript
-// ✅ Good — each child on its own line
-<Container>
-    <Header />
-    <Content />
-    <Footer />
-</Container>
-
-<Form>
-    <Input name="email" />
-    <Input name="password" />
-    <Button type="submit">Login</Button>
-</Form>
-
-// ✅ Good — single child can stay inline
-<Button><Icon /></Button>
+// ✅ Good — 3 or fewer specifiers stay compact
+export { Button };
+export { Button, Input };
+export { Button, Input, Select };
 
-// ❌ Bad — multiple children crammed together
+// ✅ Good — 4+ specifiers expand with one per line
+export {
+    Button,
+    Input,
+    Select,
+    Checkbox,
+};
+
+// ✅ Good — re-exports follow same rules
+export { Button, Input, Select } from "./components";
+export {
+    createUser,
+    updateUser,
+    deleteUser,
+    getUser,
+} from "./api";
+
+// ❌ Bad — no spaces
+export {Button,Input,Select};
+
+// ❌ Bad — keyword on different line
+export
+    { Button };
+
+// ❌ Bad — too many on one line
+export { Button, Input, Select, Checkbox, Radio };
+```
+
+**Options:**
+
+| Option | Type | Default | Description |
+|--------|------|---------|-------------|
+| `maxSpecifiers` | `integer` | `3` | Maximum specifiers to keep on single line |
+
+```javascript
+"code-style/export-format": ["error", { maxSpecifiers: 4 }]
+```
+
+---
+
+### `import-format`
+
+**What it does:** Formats import statements consistently:
+- `import {` on the same line as `import` keyword
+- `} from` on the same line as closing brace
+- ≤3 specifiers stay on one line (collapsed)
+- 4+ specifiers get one per line (expanded)
+
+**Why use it:** Consistent import formatting improves readability and makes diffs cleaner when adding/removing imports.
+
+```javascript
+// ✅ Good — 3 or fewer specifiers stay compact
+import { useState } from "react";
+import { Button, Input } from "@/components";
+import { get, post, put } from "@/api";
+
+// ✅ Good — 4+ specifiers expand with one per line
+import {
+    useState,
+    useEffect,
+    useCallback,
+    useMemo,
+} from "react";
+
+import {
+    Button,
+    Input,
+    Select,
+    Checkbox,
+} from "@/components";
+
+// ❌ Bad — no spaces
+import {useState,useEffect} from "react";
+
+// ❌ Bad — keyword on different line
+import
+    { Button } from "@/components";
+
+// ❌ Bad — from on different line
+import { Button }
+    from "@/components";
+
+// ❌ Bad — too many on one line
+import { useState, useEffect, useCallback, useMemo, useRef } from "react";
+```
+
+**Options:**
+
+| Option | Type | Default | Description |
+|--------|------|---------|-------------|
+| `maxSpecifiers` | `integer` | `3` | Maximum specifiers to keep on single line |
+
+```javascript
+"code-style/import-format": ["error", { maxSpecifiers: 4 }]
+```
+
+---
+
+### `import-source-spacing`
+
+**What it does:** Removes any leading or trailing whitespace inside import path strings.
+
+**Why use it:** Spaces in module paths are almost always typos and can cause import resolution issues.
+
+```javascript
+// ✅ Good — no extra spaces
+import { Button } from "@mui/material";
+import React from "react";
+import styles from "./styles.css";
+
+// ❌ Bad — leading space
+import { Button } from " @mui/material";
+
+// ❌ Bad — trailing space
+import React from "react ";
+
+// ❌ Bad — both
+import styles from " ./styles.css ";
+```
+
+---
+
+### `index-export-style`
+
+**What it does:** Enforces different export formatting rules for index files vs regular files:
+- **Index files**: No blank lines between exports, use shorthand or import-export style
+- **Regular files**: Require blank lines between exports
+
+**Why use it:** Index files are re-export aggregators and should be compact. Regular files benefit from spacing between exports for readability.
+
+**Regular files (non-index):**
+```javascript
+// ✅ Good — blank lines between exports
+export const API_URL = "/api";
+
+export const MAX_RETRIES = 3;
+
+export const fetchData = async () => {};
+
+// ❌ Bad — no blank lines in regular file
+export const API_URL = "/api";
+export const MAX_RETRIES = 3;
+export const fetchData = async () => {};
+```
+
+**Index files — Style: "shorthand" (default):**
+```javascript
+// ✅ Good — shorthand re-exports, no blank lines
+export { Button } from "./button";
+export { Input, Select } from "./form";
+export { Modal } from "./modal";
+export { useAuth, useUser } from "./hooks";
+```
+
+**Index files — Style: "import-export":**
+```javascript
+// ✅ Good — imports grouped, single export at bottom
+import { Button } from "./button";
+import { Input, Select } from "./form";
+import { Modal } from "./modal";
+
+export {
+    Button,
+    Input,
+    Modal,
+    Select,
+};
+```
+
+**Options:**
+
+| Option | Type | Default | Description |
+|--------|------|---------|-------------|
+| `style` | `"shorthand"` \| `"import-export"` | `"shorthand"` | Export style for index files |
+
+```javascript
+"code-style/index-export-style": ["error", { style: "import-export" }]
+```
+
+---
+
+### `module-index-exports`
+
+**What it does:** Ensures module folders have index files that export all their contents, creating a proper public API for each module.
+
+**Why use it:** Index files allow importing from the folder level (`@/components`) instead of deep paths (`@/components/Button/Button`). This enforces proper module boundaries.
+
+```javascript
+// ✅ Good — components/index.js exports everything
+export { Button } from "./Button";
+export { Input } from "./Input";
+export { Select } from "./Select";
+export { Modal } from "./Modal";
+
+// Then consumers can import cleanly:
+import { Button, Input, Select } from "@/components";
+
+// ❌ Bad — missing exports in index.js
+// If Button exists but isn't exported from index.js,
+// consumers have to use deep imports:
+import { Button } from "@/components/Button/Button"; // Avoid this!
+```
+
+**Default Module Folders:**
+`actions`, `apis`, `assets`, `atoms`, `components`, `config`, `configs`, `constants`, `contexts`, `data`, `enums`, `helpers`, `hooks`, `interfaces`, `layouts`, `lib`, `middlewares`, `providers`, `reducers`, `redux`, `requests`, `routes`, `schemas`, `services`, `store`, `styles`, `theme`, `thunks`, `types`, `ui`, `utils`, `utilities`, `views`
+
+**Default Ignore Patterns:**
+`index.js`, `index.jsx`, `index.ts`, `index.tsx`, `.DS_Store`, `__tests__`, `__mocks__`, `*.test.js`, `*.test.jsx`, `*.test.ts`, `*.test.tsx`, `*.spec.js`, `*.spec.jsx`, `*.spec.ts`, `*.spec.tsx`
+
+**Customization Options:**
+
+| Option | Type | Description |
+|--------|------|-------------|
+| `extraModuleFolders` | `string[]` | Add extra module folders to the default list |
+| `extraLazyLoadFolders` | `string[]` | Add extra lazy load folders (default: `views`) |
+| `extraIgnorePatterns` | `string[]` | Add extra ignore patterns (supports wildcards) |
+| `moduleFolders` | `string[]` | Replace default module folders entirely |
+| `lazyLoadFolders` | `string[]` | Replace default lazy load folders entirely |
+| `ignorePatterns` | `string[]` | Replace default ignore patterns entirely |
+
+```javascript
+// Example: Add custom folders and patterns
+"code-style/module-index-exports": ["error", {
+    extraModuleFolders: ["features", "modules", "lib"],
+    extraLazyLoadFolders: ["pages"],
+    extraIgnorePatterns: ["*.stories.js", "*.mock.js"]
+}]
+```
+
+<br />
+
+## ⚛️ JSX Rules
+
+### `jsx-children-on-new-line`
+
+**What it does:** When a JSX element has multiple children, ensures each child is on its own line with proper indentation.
+
+**Why use it:** Multiple children on one line are hard to scan. Individual lines make the component structure clear.
+
+```javascript
+// ✅ Good — each child on its own line
+<Container>
+    <Header />
+    <Content />
+    <Footer />
+</Container>
+
+<Form>
+    <Input name="email" />
+    <Input name="password" />
+    <Button type="submit">Login</Button>
+</Form>
+
+// ✅ Good — single child can stay inline
+<Button><Icon /></Button>
+
+// ❌ Bad — multiple children crammed together
 <Container><Header /><Content /><Footer /></Container>
 
 // ❌ Bad — inconsistent formatting
@@ -1702,279 +1974,9 @@ function Card() {
 
 // ❌ Bad — empty line before closing tag
 <div>
-    <Content />
-
-</div>
-```
-
-<br />
-
-## 📞 Call Expression Rules
-
-### `function-arguments-format`
-
-**What it does:** Enforces consistent formatting for function call arguments:
-- Single simple argument stays on one line
-- 2+ arguments get one per line
-- Multiline arguments trigger full expansion
-- React hooks are skipped by default (they have their own rule)
-
-**Why use it:** Consistent argument formatting makes function calls scannable and diffs clean when adding/removing arguments.
-
-```javascript
-// ✅ Good — single argument stays compact
-fetchUser(userId);
-console.log(message);
-dispatch(action);
-
-// ✅ Good — 2+ arguments get one per line
-setValue(
-    "email",
-    "user@example.com",
-);
-
-createUser(
-    name,
-    email,
-    password,
-);
-
-// ✅ Good — multiline argument triggers expansion
-processData(
-    {
-        id: 1,
-        name: "test",
-    },
-);
-
-// ✅ Good — callback with body triggers expansion
-items.forEach(
-    (item) => {
-        process(item);
-        save(item);
-    },
-);
-
-// ❌ Bad — multiple arguments on same line
-setValue("email", "user@example.com");
-createUser(name, email, password);
-
-// ❌ Bad — inconsistent formatting
-fn(arg1,
-    arg2, arg3);
-```
-
-**Options:**
-
-| Option | Type | Default | Description |
-|--------|------|---------|-------------|
-| `minArgs` | `integer` | `2` | Minimum arguments to enforce multiline |
-| `skipHooks` | `boolean` | `true` | Skip React hooks (useEffect, etc.) |
-| `skipSingleArg` | `boolean` | `true` | Skip calls with single complex argument |
-
-```javascript
-// Example: Require multiline for 3+ arguments
-"code-style/function-arguments-format": ["error", { minArgs: 3 }]
-
-// Example: Don't skip React hooks
-"code-style/function-arguments-format": ["error", { skipHooks: false }]
-```
-
----
-
-### `nested-call-closing-brackets`
-
-**What it does:** Ensures nested function calls (common in styled-components, HOCs) have closing brackets on the same line: `}));`
-
-**Why use it:** Scattered closing brackets (`}\n);\n` ) waste vertical space and make it harder to see where expressions end.
-
-```javascript
-// ✅ Good — closing brackets together
-const StyledCard = styled(Card)(({ theme }) => ({
-    color: theme.palette.text.primary,
-    padding: theme.spacing(2),
-}));
-
-const StyledButton = styled("button")(({ theme }) => ({
-    backgroundColor: theme.colors.primary,
-}));
-
-// ✅ Good — multiple levels
-const Component = connect(
-    mapStateToProps,
-    mapDispatchToProps,
-)(withRouter(MyComponent));
-
-// ❌ Bad — closing brackets scattered
-const StyledCard = styled(Card)(({ theme }) => ({
-    color: theme.palette.text.primary,
-})
-);
-
-// ❌ Bad — each bracket on its own line
-const StyledCard = styled(Card)(({ theme }) => ({
-    color: theme.colors.primary,
-})
-)
-;
-```
-
----
-
-### `no-empty-lines-in-function-calls`
-
-**What it does:** Removes empty lines within function call argument lists — between arguments and after opening/before closing parentheses.
-
-**Why use it:** Empty lines between arguments break visual grouping. Arguments should flow as a cohesive list.
-
-```javascript
-// ✅ Good — no empty lines
-createUser(
-    name,
-    email,
-    password,
-    role,
-);
-
-fetchData(
-    url,
-    {
-        method: "POST",
-        body: data,
-    },
-);
-
-// ❌ Bad — empty line between arguments
-createUser(
-    name,
-
-    email,
-
-    password,
-);
-
-// ❌ Bad — empty line after opening paren
-fetchData(
-
-    url,
-    options,
-);
-
-// ❌ Bad — empty line before closing paren
-fetchData(
-    url,
-    options,
-
-);
-```
-
----
-
-### `opening-brackets-same-line`
-
-**What it does:** Ensures opening brackets (`{`, `[`, `(`) in function arguments stay on the same line as the function call.
-
-**Why use it:** Opening brackets on new lines create unnecessary indentation and vertical space.
-
-```javascript
-// ✅ Good — brackets on same line as call
-fn({ key: value });
-process([1, 2, 3]);
-items.map(({ id }) => id);
-configure({ debug: true });
-
-// ✅ Good — multiline content is fine
-fn({
-    key: value,
-    other: data,
-});
-
-items.map(({ id, name }) => (
-    <Item key={id} name={name} />
-));
-
-// ❌ Bad — opening bracket on new line
-fn(
-    { key: value }
-);
-
-process(
-    [1, 2, 3]
-);
-
-items.map(
-    ({ id }) => id
-);
-```
-
----
-
-### `simple-call-single-line`
-
-**What it does:** Collapses simple function calls with an arrow function containing a single call expression onto one line.
-
-**Why use it:** Common patterns like `lazy(() => import(...))` don't need multiline formatting. Single line is cleaner.
-
-```javascript
-// ✅ Good — simple patterns on one line
-const Page = lazy(() => import("./Page"));
-const Modal = lazy(() => import("./Modal"));
-setTimeout(() => callback(), 100);
-requestAnimationFrame(() => render());
-items.filter(() => isValid(item));
-
-// ✅ Good — complex callbacks stay multiline
-const Page = lazy(() => {
-    console.log("Loading page");
-    return import("./Page");
-});
-
-// ❌ Bad — unnecessary multiline for simple pattern
-const Page = lazy(
-    () => import("./Page"),
-);
-
-setTimeout(
-    () => callback(),
-    100,
-);
-```
-
----
-
-### `single-argument-on-one-line`
-
-**What it does:** Ensures function calls with a single simple argument (literal, identifier, member expression) stay on one line.
-
-**Why use it:** Single-argument calls don't need multiline formatting. Expanding them wastes vertical space.
-
-```javascript
-// ✅ Good — single argument on one line
-fetchUser(userId);
-console.log(message);
-process(data.items);
-dispatch(action);
-setValue("key");
-getElement(document.body);
-
-// ✅ Good — complex single argument can be multiline
-processConfig({
-    key: value,
-    other: data,
-});
-
-// ❌ Bad — simple argument expanded unnecessarily
-fetchUser(
-    userId,
-);
-
-console.log(
-    message,
-);
+    <Content />
 
-dispatch(
-    action,
-);
+</div>
 ```
 
 <br />
@@ -2200,6 +2202,611 @@ const styles = {
 
 <br />
 
+## 📐 Spacing Rules
+
+### `assignment-value-same-line`
+
+**What it does:** Ensures the assigned value starts on the same line as the `=` sign, not on a new line.
+
+**Why use it:** Breaking after `=` creates awkward formatting and wastes vertical space. Keeping values on the same line as `=` is more readable.
+
+```javascript
+// ✅ Good — value starts on same line as =
+const name = "John";
+const config = {
+    host: "localhost",
+    port: 3000,
+};
+const items = [
+    "first",
+    "second",
+];
+
+// ❌ Bad — value on new line after =
+const name =
+    "John";
+const config =
+    {
+        host: "localhost",
+        port: 3000,
+    };
+const items =
+    [
+        "first",
+        "second",
+    ];
+```
+
+---
+
+### `member-expression-bracket-spacing`
+
+**What it does:** Removes spaces inside brackets in computed member expressions (array access, dynamic property access).
+
+**Why use it:** Consistent with JavaScript conventions. Spaces inside brackets look inconsistent with array literals and other bracket usage.
+
+```javascript
+// ✅ Good — no spaces inside brackets
+const value = arr[0];
+const name = obj[key];
+const item = data[index];
+const nested = matrix[row][col];
+
+// ❌ Bad — spaces inside brackets
+const value = arr[ 0 ];
+const name = obj[ key ];
+const item = data[ index ];
+```
+
+<br />
+
+## 🧩 Component Rules
+
+### `component-props-destructure`
+
+**What it does:** Enforces that React component props must be destructured in the function parameter, not received as a single `props` object.
+
+**Why use it:** Destructured props make it immediately clear what props a component uses. It improves readability and helps catch unused props.
+
+```typescript
+// ✅ Good — props are destructured
+export const Button = ({ label, onClick, variant = "primary" }) => (
+    <button onClick={onClick} type="button">
+        {label}
+    </button>
+);
+
+export const Card = ({
+    children,
+    className = "",
+    title,
+} : {
+    children: ReactNode,
+    className?: string,
+    title: string,
+}) => (
+    <div className={className}>
+        <h2>{title}</h2>
+        {children}
+    </div>
+);
+
+// ❌ Bad — props received as single object
+export const Button = (props) => (
+    <button onClick={props.onClick} type="button">
+        {props.label}
+    </button>
+);
+
+export const Card = (props: CardPropsInterface) => (
+    <div className={props.className}>
+        <h2>{props.title}</h2>
+        {props.children}
+    </div>
+);
+```
+
+---
+
+### `component-props-inline-type`
+
+**What it does:** Enforces that React component props must use inline type annotation instead of referencing an interface or type alias. Also enforces:
+- Exactly one space before and after colon: `} : {`
+- Props in type must match exactly with destructured props (no missing or extra)
+- Each prop type on its own line when there are multiple props
+- First prop type must be on new line after `{` when multiple props
+- No empty lines after opening brace or before closing brace
+- No space before `?` in optional properties (`prop?: type` not `prop ?: type`)
+- Trailing commas (not semicolons) for each prop type
+- No empty lines between prop types
+
+**Why use it:** Inline types keep the prop definitions colocated with the component, making it easier to understand and modify the component without jumping to separate interface definitions. Enforcing prop matching ensures type safety and prevents unused type properties.
+
+```typescript
+// ✅ Good — inline type annotation with matching props
+export const Button = ({ label } : { label: string }) => (
+    <button type="button">{label}</button>
+);
+
+export const Card = ({
+    className = "",
+    description,
+    title,
+} : {
+    className?: string,
+    description?: string,
+    title: string,
+}) => (
+    <div className={className}>
+        <h1>{title}</h1>
+        {description && <p>{description}</p>}
+    </div>
+);
+
+// ❌ Bad — interface reference instead of inline type
+interface ButtonPropsInterface {
+    label: string,
+}
+export const Button = ({ label }: ButtonPropsInterface) => (
+    <button type="button">{label}</button>
+);
+
+// ❌ Bad — missing space before and after colon
+export const Button = ({ label }:{ label: string }) => (
+    <button type="button">{label}</button>
+);
+
+// ❌ Bad — props don't match (extra 'flag' in type, missing in destructured)
+export const Card = ({
+    title,
+} : {
+    flag: boolean,
+    title: string,
+}) => (
+    <div>{title}</div>
+);
+
+// ❌ Bad — semicolons instead of commas
+export const Card = ({ title } : { title: string; }) => (
+    <div>{title}</div>
+);
+
+// ❌ Bad — first prop on same line as opening brace
+export const Card = ({
+    title,
+} : { title: string,
+    className?: string,
+}) => (
+    <div>{title}</div>
+);
+
+// ❌ Bad — space before ? in optional property
+export const Card = ({ title } : { title ?: string }) => (
+    <div>{title}</div>
+);
+
+// ❌ Bad — props on same line when multiple
+export const Card = ({ a, b } : { a: string, b: string }) => (
+    <div>{a}{b}</div>
+);
+```
+
+<br />
+
+## 🔷 TypeScript Rules
+
+### `enum-format`
+
+**What it does:** Enforces consistent formatting for TypeScript enums:
+- Enum names must be PascalCase and end with `Enum` suffix
+- Enum members must be UPPER_CASE (for string enums) or PascalCase (for numeric enums)
+- No empty lines between enum members
+- Members must end with commas, not semicolons
+
+**Why use it:** Consistent enum naming makes enums instantly recognizable. UPPER_CASE members follow common conventions for constants.
+
+```typescript
+// ✅ Good — proper enum format
+export enum StatusEnum {
+    ACTIVE = "active",
+    INACTIVE = "inactive",
+    PENDING = "pending",
+}
+
+export enum HttpMethodEnum {
+    DELETE = "DELETE",
+    GET = "GET",
+    POST = "POST",
+    PUT = "PUT",
+}
+
+// ❌ Bad — wrong naming
+export enum Status {           // Missing Enum suffix
+    active = "active",         // Should be UPPER_CASE
+    inactive = "inactive";     // Should use comma, not semicolon
+}
+
+// ❌ Bad — empty lines between members
+export enum UserStatusEnum {
+    ACTIVE = "active",
+
+    INACTIVE = "inactive",
+}
+```
+
+---
+
+### `interface-format`
+
+**What it does:** Enforces consistent formatting for TypeScript interfaces:
+- Interface names must be PascalCase and end with `Interface` suffix
+- Properties must be camelCase
+- No empty lines between properties
+- Properties must end with commas, not semicolons
+
+**Why use it:** Consistent interface naming makes interfaces instantly recognizable. The suffix clearly distinguishes interfaces from types and classes.
+
+```typescript
+// ✅ Good — proper interface format
+export interface UserInterface {
+    email: string,
+    id: string,
+    isActive: boolean,
+    name: string,
+}
+
+export interface ApiResponseInterface<T> {
+    data: T,
+    error: string | null,
+    status: number,
+    success: boolean,
+}
+
+// ❌ Bad — wrong naming
+export interface User {        // Missing Interface suffix
+    Email: string;             // Should be camelCase
+    ID: string;                // Should be camelCase
+    is_active: boolean;        // Should be camelCase, use comma
+}
+
+// ❌ Bad — semicolons and empty lines
+export interface UserInterface {
+    email: string;             // Should use comma
+
+    name: string;              // Empty line not allowed
+}
+```
+
+---
+
+### `type-format`
+
+**What it does:** Enforces consistent formatting for TypeScript type aliases:
+- Type names must be PascalCase and end with `Type` suffix
+- Properties must be camelCase
+- No empty lines between properties
+- Properties must end with commas, not semicolons
+
+**Why use it:** Consistent type naming makes types instantly recognizable. The suffix clearly distinguishes types from interfaces and classes.
+
+```typescript
+// ✅ Good — proper type format
+export type UserType = {
+    email: string,
+    id: string,
+    name: string,
+};
+
+export type ApiResponseType<T> = {
+    data: T,
+    error: string | null,
+    status: number,
+};
+
+// ❌ Bad — wrong naming
+export type User = {           // Missing Type suffix
+    Email: string;             // Should be camelCase
+    ID: string;                // Should use comma
+};
+
+// ❌ Bad — empty lines
+export type ConfigType = {
+    debug: boolean,
+
+    port: number,              // Empty line not allowed
+};
+```
+
+---
+
+### `type-annotation-spacing`
+
+**What it does:** Enforces consistent spacing in TypeScript type annotations:
+- No space before the colon in type annotations: `name: string` not `name : string`
+- One space after the colon: `name: string` not `name:string`
+- No space before generic type parameters: `Array<T>` not `Array <T>`
+- No space before array brackets: `string[]` not `string []`
+
+**Why use it:** Consistent type annotation spacing follows TypeScript conventions and improves code readability.
+
+```typescript
+// ✅ Good — proper spacing
+const name: string = "John";
+const items: string[] = [];
+const data: Array<number> = [];
+const handler = (value: string): boolean => true;
+
+function getData<T>(id: string): Promise<T> {
+    return fetch(id);
+}
+
+// ❌ Bad — space before colon
+const name : string = "John";
+const handler = (value : string) : boolean => true;
+
+// ❌ Bad — no space after colon
+const name:string = "John";
+const handler = (value:string):boolean => true;
+
+// ❌ Bad — space before generic
+const data: Array <number> = [];
+function getData <T>(id: string): Promise <T> {}
+
+// ❌ Bad — space before array brackets
+const items: string [] = [];
+```
+
+---
+
+### `typescript-definition-location`
+
+**What it does:** Enforces that TypeScript definitions are placed in their designated folders:
+- Interfaces must be in files inside the `interfaces` folder
+- Types must be in files inside the `types` folder
+- Enums must be in files inside the `enums` folder
+
+**Why use it:** Separating type definitions by category makes them easier to find, maintain, and share across the codebase. It promotes a clean and organized project structure.
+
+```typescript
+// ✅ Good — definitions in correct folders
+// src/interfaces/user.ts
+export interface UserInterface {
+    id: string,
+    name: string,
+}
+
+// src/types/config.ts
+export type ConfigType = {
+    apiUrl: string,
+    timeout: number,
+};
+
+// src/enums/status.ts
+export enum UserRoleEnum {
+    ADMIN = "admin",
+    USER = "user",
+}
+
+// ❌ Bad — definitions in wrong folders
+// src/components/user-card.tsx
+interface UserProps {          // Should be in interfaces folder
+    name: string,
+}
+
+// src/types/user.ts
+export interface UserInterface {   // Should be in interfaces folder, not types
+    id: string,
+}
+
+export enum StatusEnum {           // Should be in enums folder, not types
+    ACTIVE = "active",
+}
+```
+
+<br />
+
+## ⚛️ React Rules
+
+### `react-code-order`
+
+**What it does:** Enforces a consistent ordering of code blocks within React components and custom hooks. The order follows a logical dependency chain where declarations appear before their usage.
+
+**Order (top to bottom):**
+1. Props/params destructure (in function signature: `({ prop1, prop2 })`)
+2. Props/params destructure in body (`const { x } = propValue` where propValue is a prop)
+3. `useRef` declarations
+4. `useState` declarations
+5. `useReducer` declarations
+6. `useSelector` / `useDispatch` (Redux hooks)
+7. Router hooks (`useNavigate`, `useLocation`, `useParams`, `useSearchParams`)
+8. Context hooks (`useContext`, `useToast`, etc.)
+9. Custom hooks (`use*` pattern)
+10. Derived state / variables (computed from hooks above, e.g., `const isSearching = term.length > 0`)
+11. `useMemo` declarations
+12. `useCallback` declarations
+13. Handler functions (`const handleX = () => {}`)
+14. `useEffect` / `useLayoutEffect`
+15. Return statement
+
+**Why use it:** A consistent code structure makes components and hooks predictable and easier to navigate. Placing hooks before derived values ensures dependencies are defined before use. Effects come last because they typically depend on everything else.
+
+```typescript
+// ✅ Good — Component follows the correct order
+const UserDashboard = ({ title }) => {
+    // 1. useRef
+    const inputRef = useRef(null);
+
+    // 2. useState
+    const [count, setCount] = useState(0);
+    const [isLoading, setIsLoading] = useState(false);
+
+    // 3. Redux hooks
+    const dispatch = useDispatch();
+    const user = useSelector((state) => state.user);
+
+    // 4. Router hooks
+    const navigate = useNavigate();
+    const { id } = useParams();
+
+    // 5. Custom hooks
+    const { data, loading } = useFetchData(id);
+
+    // 6. Derived state
+    const isReady = !loading && data !== null;
+    const displayName = user?.name ?? "Guest";
+
+    // 7. useMemo
+    const filteredItems = useMemo(
+        () => data?.filter((item) => item.active),
+        [data],
+    );
+
+    // 8. useCallback
+    const handleSubmit = useCallback(
+        () => {
+            dispatch(submitAction());
+        },
+        [dispatch],
+    );
+
+    // 9. Handler functions
+    const resetHandler = () => {
+        setCount(0);
+        setIsLoading(false);
+    };
+
+    // 10. useEffect
+    useEffect(
+        () => {
+            inputRef.current?.focus();
+        },
+        [],
+    );
+
+    // 11. Return
+    return (
+        <div>
+            <h1>{title}</h1>
+            <span>{displayName}</span>
+        </div>
+    );
+};
+
+// ✅ Good — Custom hook follows the correct order
+const useCreateAccount = () => {
+    // 1. useState
+    const [loading, setLoading] = useState(false);
+    const [created, setCreated] = useState(false);
+
+    // 2. Redux hooks
+    const dispatch = useDispatch();
+
+    // 3. Context hooks
+    const { toast } = useToast();
+
+    // 4. Handler functions
+    const createAccountHandler = async (data: AccountData) => {
+        setLoading(true);
+        try {
+            await api.createAccount(data);
+            setCreated(true);
+        } catch (error) {
+            toast({ description: "Failed to create account" });
+        } finally {
+            setLoading(false);
+        }
+    };
+
+    // 5. useEffect
+    useEffect(
+        () => {
+            if (created) {
+                setTimeout(() => setCreated(false), 50);
+            }
+        },
+        [created],
+    );
+
+    // 6. Return
+    return { createAccountHandler, created, loading };
+};
+
+// ❌ Bad — useEffect before useState
+const BadComponent = ({ title }) => {
+    useEffect(() => {
+        console.log("mounted");
+    }, []);
+
+    const [count, setCount] = useState(0);
+
+    return <div>{title}</div>;
+};
+
+// ❌ Bad — context hook before useState in custom hook
+const useBadHook = () => {
+    const { toast } = useToast();          // Should come after useState
+    const [loading, setLoading] = useState(false);
+    return { loading };
+};
+
+// ❌ Bad — handler before hooks
+const AnotherBadComponent = ({ title }) => {
+    const handleClick = () => {
+        console.log("clicked");
+    };
+
+    const dispatch = useDispatch();
+    const [count, setCount] = useState(0);
+
+    return <div onClick={handleClick}>{title}</div>;
+};
+
+// ❌ Bad — derived state after handler
+const YetAnotherBad = ({ title }) => {
+    const [items, setItems] = useState([]);
+
+    const handleAdd = () => {
+        setItems([...items, "new"]);
+    };
+
+    const itemCount = items.length; // Should come before handleAdd
+
+    return <div>{itemCount}</div>;
+};
+```
+
+<br />
+
+## 📝 Variable Rules
+
+### `variable-naming-convention`
+
+**What it does:** Enforces naming conventions for variables:
+- **camelCase** for regular variables and functions
+- **UPPER_CASE** for constants (primitive values)
+- **PascalCase** for React components and classes
+- **camelCase with `use` prefix** for hooks
+
+**Why use it:** Consistent naming makes code predictable. You can tell what something is by how it's named.
+
+```javascript
+// ✅ Good — correct conventions
+const userName = "John";           // camelCase for variables
+const itemCount = 42;              // camelCase for variables
+const MAX_RETRIES = 3;             // UPPER_CASE for constants
+const API_BASE_URL = "/api";       // UPPER_CASE for constants
+const UserProfile = () => <div />; // PascalCase for components
+const useAuth = () => {};          // camelCase with use prefix for hooks
+
+// ❌ Bad — wrong conventions
+const user_name = "John";          // snake_case
+const maxretries = 3;              // should be UPPER_CASE
+const userProfile = () => <div />; // should be PascalCase
+const UseAuth = () => {};          // hooks should be camelCase
+```
+
+<br />
+
 ---
 
 ## 🔧 Auto-fixing