# Airbnb JavaScript Style Guide - Summary

## Types
  - Primitives: access by value (`string`, `number`, `boolean`, `null`, `undefined`, `symbol`, `bigint`)
  - Complex: access by reference (`object`, `array`, `function`)

## References
  - Use `const` for all references; avoid `var`
  - Use `let` only if reassigning references
  - Both `const` and `let` are block-scoped, unlike function-scoped `var`

## Objects
  - Use literal syntax for object creation
  - Use computed property names when creating objects with dynamic properties
  - Use object method and property value shorthand
  - Group shorthand properties at the beginning
  - Only quote invalid identifier properties
  - Don't call `Object.prototype` methods directly
  - Prefer object spread (`{...obj}`) over `Object.assign`

## Arrays
  - Use literal syntax for array creation
  - Use `Array#push` instead of direct assignment
  - Use array spreads `...` to copy arrays
  - Use `...` for iterable conversion; `Array.from` for array-like objects
  - Use return statements in array method callbacks
  - Use line breaks after opening and before closing array brackets for multiline arrays

## Destructuring
  - Use object destructuring when accessing multiple properties
  - Use array destructuring
  - Use object destructuring for multiple return values, not array destructuring

## Strings
  - Use single quotes (`''`) for strings
  - Don't write strings that cause line breaks over 100 characters
  - Use template literals for string composition
  - Never use `eval()` on strings
  - Don't unnecessarily escape characters

## Functions
  - Use named function expressions instead of function declarations
  - Wrap IIFEs in parentheses
  - Never declare functions in non-function blocks
  - Never name a parameter `arguments`
  - Use rest syntax (`...`) instead of `arguments`
  - Use default parameter syntax rather than mutating function arguments
  - Avoid side effects with default parameters
  - Always put default parameters last
  - Never use the Function constructor

## Arrow Functions
  - Use arrow functions for anonymous functions
  - Omit braces and use implicit return when function body is a single expression
  - Wrap expressions over multiple lines in parentheses
  - Always include parentheses around arguments
  - Avoid confusing arrow function syntax with comparison operators

## Classes & Constructors
  - Use `class` syntax; avoid manipulating `prototype` directly
  - Use `extends` for inheritance
  - Methods can return `this` for method chaining
  - Don't use empty constructors or ones that just delegate to parent
  - Avoid duplicate class members
  - Class methods should use `this` or be static

## Modules
  - Always use ES modules (`import`/`export`) over non-standard module systems
  - Don't use wildcard imports
  - Don't export directly from an import
  - Only import from a path in one place
  - Don't export mutable bindings
  - Prefer default export for single exports
  - Put all imports above non-import statements
  - Multi-line imports should follow proper indentation

## Iterators and Generators
  - Prefer JavaScript's higher-order functions over loops
  - Don't use generators for now (poor ES5 transpilation)

## Properties
  - Use dot notation when accessing properties
  - Use bracket notation `[]` when accessing properties with a variable
  - Use exponentiation operator (`**`) when calculating exponentiations

## Variables
  - Always use `const` or `let`, never undeclared variables
  - Use one declaration per variable or assignment
  - Group all `const`s and then all `let`s
  - Assign variables where you need them in a reasonable place
  - Don't chain variable assignments
  - Avoid unary increments and decrements (`++`, `--`)
  - Avoid linebreaks before or after `=` in assignments

## Comparison Operators & Equality
  - Use `===` and `!==` over `==` and `!=`
  - Use shortcuts for booleans, but explicit comparisons for strings and numbers
  - Use braces for case/default clauses with lexical declarations
  - Keep ternaries simple and on single lines when possible
  - Avoid unneeded ternary statements
  - Use parentheses when mixing operators
  - Use nullish coalescing (`??`) only for `null`/`undefined` cases

## Blocks
  - Use braces with multiline blocks
  - Put `else` on same line as closing brace of `if`
  - Avoid unnecessary `else` blocks when `if` contains a return

## Control Statements
  - Break long conditions onto multiple lines with operators at the start of lines
  - Don't use selection operators in place of control statements

## Comments
  - Use `/** ... */` for multiline comments
  - Use `//` for single line comments above the subject
  - Start comments with a space for readability
  - Prefix comments with `FIXME:` or `TODO:` for actionable items

## Whitespace
  - Use soft tabs (2 spaces)
  - Place 1 space before leading braces
  - Place 1 space before parentheses in control statements
  - Set off operators with spaces
  - End files with a single newline
  - Use indentation for long method chains with leading dots
  - Leave a blank line after blocks and before statements
  - Don't pad blocks with blank lines or use multiple blank lines

## Commas
  - Use trailing commas, not leading
  - Include additional trailing commas for cleaner diffs

## Semicolons
  - Use semicolons at the end of statements

## Type Casting & Coercion
  - Perform type coercion at the beginning of statements
  - Use explicit conversion functions: `String()`, `Number()`, `parseInt()`, `Boolean()`

## Naming Conventions
  - Be descriptive; avoid single letter names
  - Use camelCase for objects, functions, and instances
  - Use PascalCase for classes and constructors
  - Don't use leading/trailing underscores
  - Don't save references to `this`; use arrow functions or bind
  - Filename should match default export name
  - Acronyms should be all uppercase or all lowercase

## Accessors
  - Accessor functions aren't required but be consistent if used
  - Use verb prefixes like `get`, `set`, `is`, `has` appropriately

## Events
  - Pass objects with data rather than raw values when triggering events

## jQuery
  - Prefix jQuery objects with `$`
  - Cache jQuery lookups
  - Use optimal selectors and scoping for DOM queries

## Testing
  - Write tests for all code
  - Aim for high test coverage
  - Write regression tests when fixing bugs

# Airbnb React/JSX Style Guide - Summary

- **Component Structure**
  - One React component per file (multiple stateless components allowed)
  - Always use JSX syntax instead of `React.createElement`
  - Use `class extends React.Component` for stateful components
  - Use function declarations for stateless components
  - Don't use mixins

- **Naming & Files**
  - Use `.jsx` extension for React components
  - Use PascalCase for component filenames and references
  - Use camelCase for component instances
  - Use composite names for HOCs (e.g., `withFoo(Bar)`)

- **Syntax & Formatting**
  - Use double quotes for JSX attributes, single quotes for JS
  - Include a space in self-closing tags
  - Don't pad JSX curly braces with spaces
  - Wrap multiline JSX in parentheses
  - Always self-close tags without children

- **Props**
  - Use camelCase for prop names
  - Omit value when prop is explicitly `true`
  - Always include `alt` attributes on `<img>` tags
  - Don't use array index as `key` prop
  - Define defaultProps for all non-required props
  - Use spread props sparingly

- **Methods & Events**
  - Use arrow functions to close over local variables
  - Bind event handlers in the constructor
  - Don't use underscore prefix for internal methods
  - Always return a value in render methods

- **Component Organization**
  - Follow specific ordering for lifecycle methods
  - Follow specific patterns for defining propTypes and defaultProps
  - Don't use `isMounted` (anti-pattern)

# Node.js Style Guide
- **Formatting**
  - Use 2 spaces for indentation (no tabs)
  - Use UNIX-style newlines (`\n`)
  - No trailing whitespace
  - Use semicolons
  - Limit lines to 80 characters
  - Use single quotes (except for JSON)
  - Opening braces go on the same line
  - Declare one variable per `var` statement

- **Naming Conventions**
  - Use `lowerCamelCase` for variables, properties and function names
  - Use `UpperCamelCase` for class names
  - Use `UPPERCASE` for constants
  - Use descriptive names (avoid single characters and uncommon abbreviations)

- **Variables**
  - Use trailing commas in multiline object and array literals
  - Put short declarations on a single line
  - Only quote object keys when necessary

- **Conditionals**
  - Always use the `===` operator
  - Use multi-line format for ternary operators
  - Use descriptive variables for non-trivial conditions

- **Functions**
  - Write small functions (aim for ~15 lines or less)
  - Return early from functions to avoid deep nesting
  - Name your closures for better debugging
  - Avoid nested closures
  - For method chaining, use one method per line with indentation

- **Comments**
  - Use slashes for both single line and multi-line comments
  - Write comments that explain higher-level mechanisms
  - Don't comment on obvious code

- **Best Practices**
  - Avoid `Object.freeze`, `Object.preventExtensions`, `Object.seal`, `with`, and `eval`
  - Put all requires at the top of file
  - Avoid using getters and setters with side effects
  - Never extend built-in prototypes

- Follow Node.js and React patterns, use app router and correctly use server and client components.
- Use Express.
- Use ES6.
- Use React.
- Use React Hook Form for form handling.
- Use React Context for state management.
- Follow AirBnB style guide for code formatting.
- Use PascalCase when creating new React files. UserCard, not user-card.
- Use named exports when creating new react components.
- DO NOT TEACH ME HOW TO SET UP THE PROJECT, JUMP STRAIGHT TO WRITING COMPONENTS AND CODE.

- Optimize indexes to improve query execution speed.
- Avoid N+1 queries and suggest more efficient alternatives.
- Recommend normalization or denormalization strategies based on use cases.
- Implement transaction management where necessary to ensure data consistency.
- Suggest methods for monitoring database performance.

## Language

Tu répondras **toujours en français** quoi qu'il arrive.

# File system MCP usage
Analyze user request, if they ask for file(s) creation, then use
the according tools to make change to project folder.

Always create files/sub folder inside /projects folder, no exeption.

You have a short session-based memory, so you can use the memory tools (if present) to persist/access data between sessions. Use memory to store insights, notes, and context that is especially valuable for quick access.