anchor.diff:  
   .l-main-section
   :marked
  +  ### <a id="05-13"></a>_input_ 과 _output_에 별칭을 피하세요.
     ### <a id="05-13"></a>Avoid aliasing _inputs_ and _outputs_
     #### <a href="#05-13">Style 05-13</a>
   
   .s-rule.avoid
     :marked
  +    **금지** _input_과 _output_에 별칭 사용하기. 중요한 용도로 사용될 때는 예외입니다.
  +
       **Avoid** _input_ and _output_ aliases except when it serves an important purpose.
   
   .s-why
     :marked
  +    **이유** 동일한 프로퍼티 (하나는 private, 하나는 public)에 대한 두 개의 이름은 본질적으로 혼란스럽습니다.
  +
       **Why?** Two names for the same property (one private, one public) is inherently confusing.
   
   .s-why.s-why-last
     :marked
  -     **Why?** You should use an alias when the directive name is also an _input_ property, 
  +     **이유** 지시자 이름이 _input_ 프로퍼티기도 하면서 지시자 이름이 해당 프로퍼티를 
  +     설명하지 않는 경우 별칭을 사용해야 합니다.
  +
  +     **Why?** You should use an alias when the directive name is also an _input_ property,
        and the directive name doesn't describe the property.
   
   +makeExample('style-guide/ts/05-13/app/heroes/shared/hero-button/hero-button.component.avoid.ts', 'example', 'app/heroes/shared/hero-button/hero-button.component.ts')(avoid=1)
  
positive.code: 
  .l-main-section
  :marked
    ### <a id="04-08"></a>App _root module_
    #### <a href="#04-08">Style 04-08</a>
  
  .s-rule.do
    :marked
      **Do** create an Angular module in the app's root folder (e.g., in `/app`).
  
  .s-why
    :marked
      **Why?** Every app requires at least one root Angular module.
  
  .s-rule.consider
    :marked
      **Consider** naming the root module `app.module.ts`.
  
  .s-why.s-why-last
    :marked
      **Why?** Makes it easier to locate and identify the root module.
  
  +makeExample('style-guide/ts/04-08/app/app.module.ts', 'example', 'app/app.module.ts')
  
negative.code: 
  .s-rule.consider
    :marked
      **권장(Consider)** 가이드라인은 일반적으로 따라야 하는 것입니다.
      만약 가이드라인 뒤에 있는 뜻을 완전히 이해하고 다른 방법을 사용할 타당한 이유가 있다면 그렇게 해도 됩니다. 부디 일관성을 유지하세요.
  
      **Consider** guidelines should generally be followed.
      If you fully understand the meaning behind the guideline and have a good reason to deviate, then do so. Please strive to be consistent.
  
  .s-rule.avoid
    :marked
      **금지(avoid)**는 거의 해서는 안되는 것을 나타냅니다. *금지*에 대한 코드 예제는 실수를 하지 않도록 빨간색 머리글로 표시했습니다.
  
      **Avoid** indicates something you should almost never do. Code examples to *avoid* have an unmistakeable red header.
  .l-main-section
  
  :marked
    ## 파일 구조 규칙
    ## File structure conventions
  
    어떤 코드 예제는 한 개 또는 한 개 이상의 비슷한 이름을 가진 동반 파일을 보여줍니다.
    예를 들어 `hero.component.ts`와 `hero.component.html`과 같은 것입니다.
  
    Some code examples display a file that has one or more similarly named companion files.
    For example, `hero.component.ts` and `hero.component.html`.
  
    가이드라인에서는 이러한 다양한 파일을 표시하기 위해 `hero.component.ts|html|css|spec` 단축표기법을 사용합니다. 이러한 단축표기법을 사용하여 가이드의 파일 구조를 보다 읽기 쉽고 보다 간결하게 합니다.
  
    The guideline will use the shortcut `hero.component.ts|html|css|spec` to represent those various files. Using this shortcut makes this guide's file structures easier to read and more terse.
  
  .l-main-section
  a(id='toc')
  
  :marked
    ## 목차
    ## Table of contents
  
      1. [단일 책임](#single-responsibility)
  
      1. [Single responsibility](#single-responsibility)
  
      1. [네이밍 규칙](#naming)
  
      1. [Naming](#naming)
  
      1. [코딩 컨벤션](#coding-conventions)
  
      1. [Coding conventions](#coding-conventions)
  
      1. [앱 구조와 Angular 모듈](#app-structure-and-angular-modules)
  
      1. [App structure and Angular modules](#app-structure-and-angular-modules)
  
      1. [컴포넌트](#components)
  
      1. [Components](#components)
  
      1. [지시자](#directives)
  
      1. [Directives](#directives)
  
      1. [서비스](#services)
  
      1. [Services](#services)
  
      1. [데이터 서비스](#data-services)
  
      1. [Data services](#data-services)
  
      1. [라이프사이클 훅](#lifecycle-hooks)
  
      1. [Lifecycle hooks](#lifecycle-hooks)
  
      1. [부록](#appendix)
  
      1. [Appendix](#appendix)
  
  .l-main-section
  :marked
    ## 단일 책임
    ## Single responsibility
  
    <a href="https://wikipedia.org/wiki/Single_responsibility_principle" target="_blank"><i>단일 책임 원칙</i> (SPR)</a>을
    모든 컴포넌트, 서비스, 다른 기호에 적용하세요.
    앱을 보다 깔끔하고, 읽고 관리하기 쉽고, 테스트하기 쉽게 도와줍니다.
  
    Apply the
    <a href="https://wikipedia.org/wiki/Single_responsibility_principle" target="_blank"><i>Single Responsibility Principle</i> (SPR)</a>
    to all components, services, and other symbols.
    This helps make the app cleaner, easier to read and maintain, and more testable.
  
    ### <a id="01-01"></a>_하나의 규칙_
    ### <a id="01-01"></a>_Rule of One_
    #### <a href="#01-01">Style 01-01</a>
  .s-rule.do
    :marked
      **필수** 파일 당 서비스나 컴포넌트 하나만 정의합니다.
  
      **Do** define one thing, such as a service or component, per file.
  
  .s-rule.consider
    :marked
      **권장** 파일에 코드는 400라인으로 제한합니다.
  
      **Consider** limiting files to 400 lines of code.
  
  .s-why
    :marked
      **이유** 파일 당 하나의 컴포넌트를 만들면 읽고, 관리하고, 팀에서 소스 제어 시
      충돌을 회피하기에 훨씬 쉽습니다.
  
      **Why?** One component per file makes it far easier to read, maintain, and avoid
      collisions with teams in source control.
  
  .s-why
    :marked
      **이유** 파일 당 하나의 컴포넌트를 만들면 숨겨진 버그를 회피할 수 있습니다. 한 파일에 여러 컴포넌트를 합칠 경우 변수를 공유하고, 원하지 않는 클로저를 만들거나, 원하지 않는 의존성에 묶이면서 숨겨진 버그가 발생할 수 있습니다.
  
      **Why?** One component per file avoids hidden bugs that often arise when combining components in a file where they may share variables, create unwanted closures, or unwanted coupling with dependencies.
  
  .s-why.s-why-last
    :marked
      **이유** 단일 컴포넌트는 라우터에서 지연 로딩을 활용할 수 있는 파일의 기본 익스포트가 될 수 있습니다.
  
      **Why?** A single component can be the default export for its file which facilitates lazy loading with the router.
  :marked
    요점은 보다 재사용성이 높고, 읽기 쉽고, 실수를 유발할 가능성이 적은 코드를 만드는 것입니다.
  
    The key is to make the code more reusable, easier to read, and less mistake prone.
  
    다음 *부정적인* 예제는 `AppComponent`를 정의하고, 앱을 실행(bootstrap)하고, `Hero` 모델 객체를 정의하고, 서버에서 히어로를 로드합니다 ... 모두 같은 파일에서요. *이렇게 하지 마세요*.
  
    The following *negative* example defines the `AppComponent`, bootstraps the app, defines the `Hero` model object, and loads heroes from the server ... all in the same file. *Don't do this*.
  
  +makeExample('style-guide/ts/01-01/app/heroes/hero.component.avoid.ts', '', 'app/heroes/hero.component.ts')(avoid=1)
  :marked
    컴포넌트와 지원 클래스를 자신만의 지정된 파일로 배포하는 것이
    보다 좋은 습관입니다.
  
    It is a better practice to redistribute the component and its
    supporting classes into their own, dedicated files.
  
  +makeTabs(
  