File Naming Convention
Context
The health-activity-ui repo has not landed on a consistent allfile naming convention. Currently, thereβs a mismatch of how files are named which leads to:
- Confusion among developers of how files should be named.
- A more arduous experience to search for and identify specific files.
- A lack of readability to understand the content of a file at a glance.
- Inconsistency.
By agreeing on a consistent file naming convention, we can adhere to a standard where:
- Meaningful names of files will communicate their intent. For example,
activity-list.component.tsx
states that the file contains a React component that manages a list of activities. - At a glance, engineers can search for code quickly by looking at the file name for context.
- We can provide readability and help with maintainability.
Decision
When it comes to naming files and directories, there are a few rules we need to follow.
- kebab-case: Uses lower case words separated by hyphens (dashes), e.g., foo-bar.
- All lowercase.
- Only letters, numbers, dashes (-), and
.
.
- Keep it descriptive and short. File names should be short and describe what the contents of the file are.
- Proper file extensions: Always use TypeScript (
.ts
) or TSX, React in TypeScript, (.tsx
). There are a few exceptions, such as config files can be in.js
or.json
. - File type suffix: The filename should include a suffix for the file type. Append the type of the file after the short and descriptive filename, e.g.,
.component.tsx
,.models.ts
, and etc. A list of file types:.component.tsx
: React component..styled.ts(x)
: Styled component..models.ts
: Interfaces, enums, types, or constants..class.ts
: TypeScript class..api.ts
: API functions..utils.ts
: Util functions..spec.ts(x)
: Tests
File name
β Good
foo-bar.ts
foo.ts
β Bad
FooBar.ts
Foo.ts
foo_bar.ts
React Components: .component.tsx
β Good
foo-bar.component.tsx
foo.component.tsx
β Bad
FooBar.tsx
foo-bar.component.ts // <-- React files should always have .tsx extension
FooBarComponent.tsx
Styled Components: .styled.ts(x)
β Good
foo-bar.styled.ts
foo.styled.ts
foo.styled.tsx
β Bad
FooStyled.ts
styled.ts
Models: .models.ts
Extract all related interfaces, enums, types, and constants into its own file.
Always TS.
β Good
foo-bar.models.ts
foo.models.ts
β Bad
foo-bar.interface.ts
FooModels.ts
foo.models.tsx
foo.models.js
Class: .class.ts
Always TS.
β Good
foo-bar.class.ts
foo.class.ts
β Bad
FooClass.ts
foo-bar.class.tsx
foo.class.js
API Functions: .api.ts
β Good
foo-bar.api.ts
foo.api.ts
β Bad
FooApi.ts
Data Providers: .provider.tsx
, .actions.ts
, and .reducer.ts
β Good
foo-bar.provider.tsx
foo-bar.actions.ts
foo-bar.reducer.ts
β Bad
FooProvider.tsx
FooActions.ts
FooReducer.ts
Utils: .utils.ts
β Good
foo-bar.utils.ts
foo.utils.ts
β Bad
FooUtils.ts
foo.utils.tsx
Test Files: .spec.ts(x)
β Good
foo-bar.spec.ts(x)
foo.spec.ts(x)
β Bad
foo-bar.test.ts(x)
FooBar.spec.ts(x)
Exceptions
With all rules, there are some exceptions that break our naming convention:
README.md
- markdown files should use ALL CAPS. Another example:CONTRIBUTING.md
- An exception to our exception. Our ADRs are kebab-case and numerically ordered, e.g.,
0001-foo-bar.md
. CODEOWNERS
- All caps.
Consequences
- Consistent file naming convention that engineers understand.
- Communicates what a file is about, making it easier for others to scan files and understand the purpose of the file.
- Provides a naming convention others can follow when creating a file.