Coding Style

This is a coding style guide for typescript monorepo's (2024)

Code style should follow the project’s eslint configuration.
Make sure your code is linted before pushing it.

You can also build your project locally to ensure it will pass in the CI’s lint & build stage.

  • This is an ongoing process, there’s a lot of broken conventions of old code, but its no excuse not to write new code the way we can love to own it. Please feel free to add more standards here.

Naming Conventions

  • We use a camelCase style for variables, and functions.
  • We use PascalCase for classes, jsx components, types and interfaces.
  • We use SNAKE_UPPERCASE for constants

You can find more info on the case types we use and why here:
JavaScript Naming Conventions

When naming, we must use self-descriptive names. It shouldn't be necessary to add a comment for additional documentation.

Naming best practices

Naming Things in Code

Naming a function that is exported

we must also describe what its responsible for

For example:
A service layer function would also describe its a service:
export const createOrderService = () ⇒ {};

Another example is a Rest API calling function, it should include its method type so that the caller knows its an api request:

postNewOrderApi is a good example for a Rest POST api function.

createOrder is a bad example for the same case. as you would have to dive in to the function code to realize its a rest api call.

  • Functions should describe their responsibility and what they are doing
  • Input parameters types should describe the function they are meant for, and the usecase of the parameters, example: params: PostNewOrderApiRequest
  • Functions return types should describe the function they are meant for, and the usecase of the returned object, example: response: PostNewOrderApiResponse

Exporting conventions

  • Follow eslint exporting convention
  • Don’t export something thats only meant to be used in the scope of its own file
  • You can use inline exports to write less code
  • Don’t do both inline and eof exports in the same file, choose one way and stick with it.
  • Avoid default exports at all costs! We want 1 way to export, 1 way to import.

More on that here:

Avoid ES6 default exports
Avoid Export Default

If you have a file with only 1 export, do the following workaround to avoid eslint issues:
export const example = 42;
export default {}

Research material

iTwin.js TypeScript Coding Guidelines - iTwin.jsBest practices for Typescript codingGoogle TypeScript Style GuideTypeScript Coding Style Guide?