Object literal properties
- Selector:
objectLiteralProperty - Allows:
camelCase,snake_case,PascalCase,UPPER_CASE.
Why This Rule
Object literal properties need flexibility to handle diverse use cases:
- Interoperability: External APIs often use different conventions (snake_case from Python/Ruby APIs, PascalCase from .NET)
- Data transformation: When mapping between different systems, forcing a single convention creates unnecessary friction
- Domain modeling: Sometimes property names represent external concepts that have established conventions
- Constant objects: Global constant objects often use UPPER_CASE for their properties (e.g.,
HTTP_STATUS.OK,ERROR_CODES.NOT_FOUND)
By allowing all four common conventions, we respect real-world constraints while maintaining internal consistency within each object. Mixed naming in the same object is still bad (see examples below), but you can choose the convention that matches your context.
References:
✅ Good
ts
const obj = {
fooBar: 1, // WHY: camelCase — standard JS style for object properties
foo_bar: 2, // WHY: snake_case — allowed for interop with external APIs
FooBar: 3, // WHY: PascalCase — allowed when mirroring .NET/other external schemas
};
// Global constant objects with UPPER_CASE properties
export const HTTP_STATUS = {
OK: 200, // WHY: UPPER_CASE for constant values
NOT_FOUND: 404,
INTERNAL_SERVER_ERROR: 500,
} as const;
// Choosing a single convention per object is recommended for readability❌ Bad
ts
const obj = {
Foo_bar: 1, // WHY: Mixed casing within a single property name is confusing and inconsistent
};
const mixed = {
userName: 'Alice', // WHY: camelCase
user_id: 42, // WHY: snake_case in same object - mixing conventions reduces readability
};Notes
If a property requires quotes (e.g. headers), it is ignored. See Quoted Members.