Style often doesn’t have absolute right or wrong, but in a project or a team, having too many diverse styles is definitely wrong. For individuals, in actual programming, you will gradually develop your own style. Here’s a summary of what I know to throw some light on this topic.
Common case styles
- PascalCase (Upper Camel Case)
UserType - camelCase (Lower Camel Case)
userType - kebab-case (Hyphen-Separated Case)
user-type - snake_case (Lower Snake Case)
user_type - SNAKE_CASE (Upper Snake Case)
USER_TYPE - dot.annotation (Dot Notation)
user.type
Practice
Component names
kebab case (also known as hyphen-separated case)
TS/JS constants
upper snake case
Classes and interfaces
PascalCase
CSS class names
kebab case
Static asset files
lower snake case, such as images, Excel download templates, etc.
JS/TS filenames
kebab case (also known as hyphen-separated case)
i18n keys
dot annotation
URLs
kebab case
Final Thoughts
Regarding practice, I personally think:
- Learn industry-standard specifications and respect the experience contributed by predecessors through trials and tribulations. For example, why URLs don’t use underscores, why constants use upper snake case, etc. These are all details with reasons.
- Some issues that seem irrelevant but constantly reveal their importance in actual development, such as naming. After standardizing and getting used to it, you will benefit continuously.
- Some things and rules don’t have absolute right or wrong. Appropriately develop a style that suits yourself.
Let’s encourage each other.
