Use consistent names for all components following a pattern that describes the component’s feature then (optionally) its type. My recommended pattern is feature.type.js. There are 2 names for most assets:
avengers.controller.js)AvengersController)Why?: Naming conventions help provide a consistent way to find content at a glance. Consistency within the project is vital. Consistency with a team is important. Consistency across a company provides tremendous efficiency.
Why?: The naming conventions should simply help you find your code faster and make it easier to understand.
Use consistent names for all components following a pattern that describes the component’s feature then (optionally) its type. My recommended pattern is feature.type.js.
Why?: Provides a consistent way to quickly identify components.
Why?: Provides pattern matching for any automated tasks.
/**
* common options
*/
// Controllers
avengers.js
avengers.controller.js
avengersController.js
// Services/Factories
logger.js
logger.service.js
loggerService.js
/**
* recommended
*/
// controllers
avengers.controller.js
avengers.controller.spec.js
// services/factories
logger.service.js
logger.service.spec.js
// constants
constants.js
// module definition
avengers.module.js
// routes
avengers.routes.js
avengers.routes.spec.js
// configuration
avengers.config.js
// directives
avenger-profile.directive.js
avenger-profile.directive.spec.js
Note: Another common convention is naming controller files without the word controller in the file name such as avengers.js instead of avengers.controller.js. All other conventions still hold using a suffix of the type. Controllers are the most common type of component so this just saves typing and is still easily identifiable. I recommend you choose 1 convention and be consistent for your team. My preference is avengers.controller.js identifying the AvengersController.
/**
* recommended
*/
// Controllers
avengers.js
avengers.spec.js
Name test specifications similar to the component they test with a suffix of spec.
Why?: Provides a consistent way to quickly identify components.
Why?: Provides pattern matching for karma or other test runners.
/**
* recommended
*/
avengers.controller.spec.js
logger.service.spec.js
avengers.routes.spec.js
avenger-profile.directive.spec.js
Use consistent names for all controllers named after their feature. Use UpperCamelCase for controllers, as they are constructors.
Why?: Provides a consistent way to quickly identify and reference controllers.
Why?: UpperCamelCase is conventional for identifying object that can be instantiated using a constructor.
/**
* recommended
*/
// avengers.controller.js
angular
.module
.controller('HeroAvengersController', HeroAvengersController);
function HeroAvengersController() { }
Append the controller name with the suffix Controller.
Why?: The Controller suffix is more commonly used and is more explicitly descriptive.
/**
* recommended
*/
// avengers.controller.js
angular
.module
.controller('AvengersController', AvengersController);
function AvengersController() { }
Use consistent names for all factories and services named after their feature. Use camel-casing for services and factories. Avoid prefixing factories and services with $. Only suffix service and factories with Service when it is not clear what they are (i.e. when they are nouns).
Why?: Provides a consistent way to quickly identify and reference factories.
Why?: Avoids name collisions with built-in factories and services that use the $ prefix.
Why?: Clear service names such as logger do not require a suffix.
Why?: Service names such as avengers are nouns and require a suffix and should be named avengersService.
/**
* recommended
*/
// logger.service.js
angular
.module
.factory('logger', logger);
function logger() { }
/**
* recommended
*/
// credit.service.js
angular
.module
.factory('creditService', creditService);
function creditService() { }
// customer.service.js
angular
.module
.service('customerService', customerService);
function customerService() { }
Use consistent names for all directives using camelCase. Use a short prefix to describe the area that the directives belong (some example are company prefix or project prefix).
Why?: Provides a consistent way to quickly identify and reference components.
/**
* recommended
*/
// avenger-profile.directive.js
angular
.module
.directive('xxAvengerProfile', xxAvengerProfile);
// usage is <xx-avenger-profile> </xx-avenger-profile>
function xxAvengerProfile() { }
When there are multiple modules, the main module file is named app.module.js while other dependent modules are named after what they represent. For example, an admin module is named admin.module.js. The respective registered module names would be app and admin.
Why?: Provides consistency for multiple module apps, and for expanding to large applications.
Why?: Provides easy way to use task automation to load all module definitions first, then all other angular files (for bundling).
Separate configuration for a module into its own file named after the module. A configuration file for the main app module is named app.config.js (or simply config.js). A configuration for a module named admin.module.js is named admin.config.js.
Why?: Separates configuration from module definition, components, and active code.
Why?: Provides an identifiable place to set configuration for a module.
app.route.js for the main module and admin.route.js for the admin module. Even in smaller apps I prefer this separation from the rest of the configuration.