Angular Styleguide notes from https://angular.io/styleguide

Angular-Styleguide-Notes.md

Single Responsibility

Applies to everything: components, services, directives, etc.

Rule of One

• One thing per file
• Max 400 lines of code per file

Small Functions

• Keep functions small
• Limit to 75 lines of code
• Seeing the entire function code without having to scroll improves readability

Naming

Helps readability and maintainability.

General

• Use consistent names for symbols (What does the author mean by "symbols" in this context?)
• The symbol's name consists first of the feature and then its type: feature.type.ts

Filenames

• Use dashes to separate words in the descriptive part or feature of a file name: my-feature
• Use dots to separate the feature and type: my-feature.component
• Use conventional type names such as:
  • component
  • service
  • pipe
  • spec
  • module
  • directive

Symbols and Filenames

• You should be able to derive the symbol in a file by the file's name: app.component.ts contains AppComponent
• Filenames are lowercase, symbol names are upper camel case
• Symbol names contain FeatureType, eg. MyAppComponent
• Filenames contain feature.type.ts, eg. my-app.component.ts (including the file extension)

Service Names

• Upper camel case
• Use Service suffix if the name is not clear. Eg. Logger is a clear service name, Credit is not, hence it needs to be suffixed with Service and end up as CreditService.

Bootstrapping (see)

• Include bootstrapping and platform sources in main.ts file.
• Include error handling in bootstrap logic
• Refrain from adding any other logic. Use Component and Services for additional logic instead.

Directive Selectors (see)

• use lower camel case

Component custom prefix (see)

• Use a custom prefix for component to prevent name collison and allow for re-use
• Instead of just users use myprefix-users

Directive custom prefix (see)

• Use a custom prefix for directive to prevent name collison and allow for re-use
• Use lower camel case for non-element selectors such as attributes

Pipe Names (see)

• Use lower camel case for pipe names
• The feature in the file name should reflect the pipe name

Unit Test File Names (see)

• Name the file the same as the component that is being tested
• Use .spec type in file name

E2E Test File Names (see)

• Use .e2e-spec type in file name

Angular NgModule Names (see)

• Use Module type in name
• Use .module type in file name
• A routing module should be suffixed with RoutingModule and .routing-module.ts respectively

Coding Conventions

Classes (see)

• Use upper camel case

Constants (see)

• Use const
• Use lower camel case instead of ALL_CAPS_WITH_UNDERSCORE

Interfaces (see)

• Use upper camel case
• Avoid starting the name with I. Try to use a class instead of interface where possible.

Properties and Methods (see)

• Use lower camel case
• Avoid underscore prefix

Import Line Spacing (see)

• Keep a line space between 3rd party imports and local or application imports
• Sort imports alphabetically
• Sort destructured assets alphabetically

App Structure and Angular Modules

• All the application code goes into the app directory
• 3rd party code does not belong in the app directory
• All features are in their own folder.
• One asset per file. Each pipe, service and component goes in its own file
• Strive for LIFT:
  • Easy to Locate code quickly
  • Easy to Identify code
  • Keep hierarchy and structure Flat
  • Try to be DRY

Compliant folder and file structure (Source)

• project root
  • app
    • core
      • core.module.ts
      • exception.service.ts|spec.ts
      • user-profile.service.ts|spec.ts
    • heroes
      • hero
        • hero.component.ts|html|css|spec.ts
      • hero-list
        • hero-list.component|html|css|spec.ts
      • shared
        • hero-button.component.ts|html|css|spec.ts
        • hero.model.ts
        • hero.service.ts|spec|ts
    • shared
      • ...
    • app.component.ts|html|css|spec.ts
    • app.module.ts
    • app-routing.module.ts
  • main.ts
  • index.html
  • ...