Angular-----代码风格指南！！！（很重要）

1. 简单函数促进代码重用；
2. 简单函数更易于阅读；
3. 简单函数更易于维护；
4. 小函数可避免易在大函数中产生的隐蔽性错误，例如与外界共享变量、创建意外的闭包或与依赖之间产生意外耦合等。

二：命名

       1）总体命名原则：所有符号使用一致的命名规则，遵循同一个模式来描述符号的特性和类型，推荐的模式为 feature.type.ts。

    @Component({
     selector: ‘toh-hero-button‘,
     templateUrl: ‘./hero-button.component.html‘
    })
    export class HeroButtonComponent {}

      5）为组件添加自定义前缀：使用带连字符的小写元素选择器值（例如 admin-users）；为组件选择器添加自定义前缀。 例如，toh 前缀表示 Tour of Heroes

          （英雄指南），而前缀 `admin 表示管理特性；使用前缀来识别特性区或者应用程序本身。      

三：应用程序结构与 NgModule

       1）LIFT:快速定位 (Locate) 代码、一眼识别 (Identify) 代码、 尽量保持扁平结构 (Flattest) 和尝试 (Try) 遵循 DRY (Do Not Repeat Yourself, 不重复自己) 原则;

             检查应用结构是否合理的方法是问问自己：我能快速打开与此特性有关的所有文件并开始工作吗？

        2）坚持直观、简单和快速地定位代码;要想高效的工作，就必须能迅速找到文件，特别是当不知道（或不记得）文件名时。 把相关的文件一起放在一个直观的

             位置可以节省时间，富有描述性的目录结构会让你和后面的维护者眼前一亮。

       3）命名文件到这个程度：看到名字立刻知道它包含了什么，代表了什么。文件名要具有说明性，确保文件中只包含一个组件。避免创建包含多个组件、服务

             或者混合体的文件。花费更少的时间来查找和琢磨代码，就会变得更有效率。 较长的文件名远胜于较短却容易混淆的缩写名。

四：组件

      1）内联输入和输出属性装饰器：使用 @Input() 和 @Output()，而非 @Directive 和 @Component 装饰器的 inputs 和 outputs 属性；把 @Input() 或者 @Output()

            放到所装饰的属性的同一行。

        3）把逻辑放到服务里：在组件中只包含与视图相关的逻辑。所有其它逻辑都应该放到服务中；把可重用的逻辑放到服务中，保持组件简单，聚焦于它们预期

            目的。

五：指令

       1）使用指令来增强已有元素：当你需要有表现层逻辑，但没有模板时，使用属性型指令；一个元素可以使用多个属性型指令

六：服务

       1）服务总是单例的：在同一个注入器内，把服务当做单例使用。用它们来共享数据和功能；服务是在特性范围或应用内共享方法的理想载体；服务是共享状

             态性内存数据的理想载体。

         2）单一职责：创建封装在上下文中的单一职责的服务；当服务成长到超出单一用途时，创建一个新服务。

   @Injectable({
      providedIn: ‘root‘,
   })
   export class Service {
   }