Parameters (destructured)

• Selector: parameter with destructured modifier
• Allowed: camelCase, snake_case
• Leading underscore: allowed

Why This Rule

Destructured parameters often come from external sources where you don't control the naming convention. Enforcing a specific format would force you to:

1. Rename immediately: ({ user_name: userName }) - adds noise
2. Not use destructuring: defeats the purpose of the feature
3. Compromise on interoperability with external APIs

By allowing flexibility, we honor the "respect real-world interoperability" principle. If an API returns { first_name, last_name }, your function can naturally accept ({ first_name, last_name }) => ...

This is consistent with our approach to destructured variables and object literal properties: when dealing with external shapes, flexibility beats forced consistency.

References:

• MDN - Destructuring Assignment
• TypeScript Handbook - Destructuring

✅ Good

function greet({ firstName, last_name }: { firstName: string; last_name: string }) {
  // WHY: Mixed allowed — preserves external naming while permitting camelCase
  return `${firstName} ${last_name}`;
}

❌ Bad

function greet({ Foo_bar }: { Foo_bar: string }) {
  // WHY: Mixed-internally inconsistent casing (capitalized + underscore) is confusing
  return Foo_bar;
}