diff --git a/aio/content/guide/styleguide.md b/aio/content/guide/styleguide.md index a5ae0c8b5e..fcc61a653a 100644 --- a/aio/content/guide/styleguide.md +++ b/aio/content/guide/styleguide.md @@ -1749,447 +1749,6 @@ A consistent class and file name convention make these modules easy to spot and - -Back to top - - -## Coding conventions - -Have a consistent set of coding, naming, and whitespace conventions. - - - -{@a 03-01} - -### Classes - -#### Style 03-01 - -
- - - -**Do** use upper camel case 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. - - -
- - - - - - - - - - - - - - - - - -Back to top - - -{@a 03-02} - -### Constants - -#### Style 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. - - -
- - - - - - - - - -Back to top - - -{@a 03-03} - -### Interfaces - -#### Style 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. - - -
- - - - - - - - - - - - - - - - - -Back to top - -{@a 03-04} - -### Properties and methods - -#### Style 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. - - -
- - - - - - - - - - - - - - - - - -Back to top - -{@a 03-06} - -### Import line spacing - -#### Style 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. - - -
- - - - - - - - - - - - - - - - - Back to top