Code conventions were dropped in Angular 8 with this PR angular/angular#30334
If you still need them to reference (because you based your style guide on it) here they are
Have a consistent set of coding, naming, and whitespace conventions.
{@a 03-01}
Do use upper camel case, also known as PascalCase, when naming classes.
Why? Follows conventional thinking for class names.
Why? Classes can be instantiated and construct an instance. By convention, upper camel case indicates a constructable asset.
{@a 03-02}
Do declare variables with const if their values should not change during the application lifetime.
Why? Conveys to readers that the value is invariant.
Why? TypeScript helps enforce that intent by requiring immediate initialization and by preventing subsequent re-assignment.
Consider spelling const variables in lower camel case.
Why? Lower camel case variable names (heroRoutes) are easier to read and understand
than the traditional UPPER_SNAKE_CASE names (HERO_ROUTES).
Why? The tradition of naming constants in UPPER_SNAKE_CASE reflects
an era before the modern IDEs that quickly reveal the const declaration.
TypeScript prevents accidental reassignment.
Do tolerate existing const variables that are spelled in UPPER_SNAKE_CASE.
Why? The tradition of UPPER_SNAKE_CASE remains popular and pervasive, especially in third party modules. It is rarely worth the effort to change them at the risk of breaking existing code and documentation.
{@a 03-03}
Do name an interface using upper camel case.
Consider naming an interface without an I prefix.
Consider using a class instead of an interface for services and declarables (components, directives, and pipes).
Consider using an interface for data models.
Why? TypeScript guidelines
discourage the I prefix.
Why? A class alone is less code than a class-plus-interface.
Why? A class can act as an interface (use implements instead of extends).
Why? An interface-class can be a provider lookup token in Angular dependency injection.
{@a 03-04}
Do use lower camel case to name properties and methods.
Avoid prefixing private properties and methods with an underscore.
Why? Follows conventional thinking for properties and methods.
Why? JavaScript lacks a true private property or method.
Why? TypeScript tooling makes it easy to identify private vs. public properties and methods.
{@a 03-06}
Consider leaving one empty line between third party imports and application imports.
Consider listing import lines alphabetized by the module.
Consider listing destructured imported symbols alphabetically.
Why? The empty line separates your stuff from their stuff.
Why? Alphabetizing makes it easier to read and locate symbols.