Each one of our feature folders will host a wide range of files, so we need a consistent naming convention to prevent filename collisions while we ensure that the different code units are easy to locate.

The following list summarizes the current conventions enforced by the community:

• Each file should contain a single code unit. Simply put, each component, directive, service, pipe, and so on should live in its own file. This way, we contribute to a better organization of code.
• Files and directories are named in lower-kebab-case.
• Files representing components, directives, pipes, and services should append a type suffix to their name: video-player.ts will become video-player.component.ts.
• Any component's external HTML template or CSS style sheet filename will match the component filename, including the suffix. Our video-player.component.ts might be accompanied by video-player.component.css and video-player.component.html.
• Directive selectors and pipe names are camelCased, while component selectors are lower-kebab-cased. Plus, it is strongly advised to add a custom prefix of our choice to prevent name collisions with other component libraries. For example, following up our video player component, it may be represented as <vp-video-player>, where vp- (which stands for video-player) is our custom prefix.
• Modules are named by following the rule of taking a PascalCased
  self-descriptive name, plus the type it represents. For example, if we see a module named VideoPlayerComponent, we can easily tell it is a component. The custom prefix in use for selectors (vp-, in our example) should not be part of the module name.
• Models and interfaces require special attention, though. Depending on your application architecture, model types will feature more or less relevance. Architectures such as MVC, MVVM, Flux, or Redux tackle models from different standpoints and grades of importance. Ultimately, it will be up to you and your architectural design pattern of choice to approach models and their naming convention in one way or another. This book will not be opinionated in that sense, although we do enforce interface models in our example application and will create modules for them.
• Each component and shared context of business logic in our application is intended to integrate with the other pieces of the puzzle in a simple and straightforward way. Clients of each subdomain are not concerned about the internal structure of the subdomain itself. If our timer feature, for example, evolves to the point of having two dozen components and directives that need to be reorganized into different folder levels, external consumers of its functionalities should remain unaffected.