Choose names and aliases that clearly communicate their purpose and meaning rather than optimizing for brevity or perceived elegance. Avoid abbreviated aliases that obscure the actual location or purpose of code elements, and resist adding premature complexity like numerical suffixes unless multiple variants actually exist.
Choose names and aliases that clearly communicate their purpose and meaning rather than optimizing for brevity or perceived elegance. Avoid abbreviated aliases that obscure the actual location or purpose of code elements, and resist adding premature complexity like numerical suffixes unless multiple variants actually exist.
For example, prefer explicit paths like @packages/frontend-shared/src/gql-components over cryptic aliases like @cy/components that require developers to mentally map the alias to its actual location. Similarly, use simple names like ci until you actually need ci1 and ci2 - don’t add complexity in anticipation of future needs that may never materialize.
The goal is to make code self-documenting where a developer can understand what something is and where it comes from without needing to look up aliases or decipher naming conventions.
Enter the URL of a public GitHub repository
