Merge pull request #97 from mkwtys/fix-code

fix code

Author: yottahmd

docs/classes-emit.md

@@ -55,20 +55,20 @@ var __extends = this.__extends || function (d, b) {
 ここで `d`は派生クラスを指し、`b`はベースクラスを指します。この関数は2つのことを行います：
 
 1. 親クラスの静的メンバを子クラスにコピーする:`for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];`
-1. 子クラス関数のプロトタイプを準備し、任意に親の`proto`のメンバを検索できるようにする。つまり、`d.prototype.__ proto__ = b.prototype`を実現する
+1. 子クラス関数のプロトタイプを準備し、任意に親の`proto`のメンバを検索できるようにする。つまり、`d.prototype.__proto__ = b.prototype`を実現する
 
 1を理解するのに苦労する人はほとんどいませんが、2については多くの人が理解に苦労します。なので順番に説明します。
 
-#### `d.prototype .__ proto__ = b.prototype`
+#### `d.prototype.__proto__ = b.prototype`
 
-これについて多くの人を教えた結果、次のような説明が最もシンプルだと分かりました。まず、`__extends`のコードが、単純な`d.prototype .__ proto__ = b.prototype`とどうして同じなのか、そしてなぜ、この行それ自体が重要であるのかを説明します。これをすべて理解するためには、これらのことを理解する必要があります:
+これについて多くの人を教えた結果、次のような説明が最もシンプルだと分かりました。まず、`__extends`のコードが、単純な`d.prototype.__proto__ = b.prototype`とどうして同じなのか、そしてなぜ、この行それ自体が重要であるのかを説明します。これをすべて理解するためには、これらのことを理解する必要があります:
 
 1. `__proto__`
 1. `prototype`
 1. `new`の関数の内側の`this`に対する効果
 1. `new`の`prototype`と`__proto__`に対する効果
 
-JavaScriptのすべてのオブジェクトは `__proto__`メンバを含んでいます。このメンバは古いブラウザではアクセスできないことがよくあります(ドキュメントでは、この魔法のプロパティを `[[prototype]]`と呼ぶことがあります)。それは1つの目的を持っています：検索しているプロパティがオブジェクトに見つからない場合(例えば `obj.property`)、`obj .__ proto __.property`を検索します。それでもまだ見つからなければ、 `obj .__ proto __.__ proto __.property`を検索します： それが見つかるか、最後の`.__ proto__`自体が`null`となるまで続きます。これは、JavaScriptが*プロトタイプ継承*(prototypal inheritance)をサポートしていることを説明しています。次の例でこれを示します。chromeコンソールまたはNode.jsで実行することが可能です。
+JavaScriptのすべてのオブジェクトは `__proto__`メンバを含んでいます。このメンバは古いブラウザではアクセスできないことがよくあります(ドキュメントでは、この魔法のプロパティを `[[prototype]]`と呼ぶことがあります)。それは1つの目的を持っています：検索しているプロパティがオブジェクトに見つからない場合(例えば `obj.property`)、`obj.__proto__.property`を検索します。それでもまだ見つからなければ、 `obj.__proto__.__proto__.property`を検索します： それが見つかるか、最後の`.__proto__`自体が`null`となるまで続きます。これは、JavaScriptが*プロトタイプ継承*(prototypal inheritance)をサポートしていることを説明しています。次の例でこれを示します。chromeコンソールまたはNode.jsで実行することが可能です。
 
 ```ts
 var foo = {}
@@ -121,11 +121,11 @@ console.log(foo.__proto__ === Foo.prototype); // True!
 3   d.prototype = new __();
 ```
 
-この関数を逆から見ると、3行目の`d.prototype = new __()`は、 `d.prototype = {__proto__：__.prototype}`を意味します(`prototype`と`__proto__`に対する`new`の効果によるものです)。それを2行目(`__.prototype = b.prototype;`)と組み合わせると、`d.prototype = {__proto__：b.prototype}`となります。
+この関数を逆から見ると、3行目の`d.prototype = new __()`は、 `d.prototype = {__proto__ : __.prototype}`を意味します(`prototype`と`__proto__`に対する`new`の効果によるものです)。それを2行目(`__.prototype = b.prototype;`)と組み合わせると、`d.prototype = {__proto__ : b.prototype}`となります。
 
-しかし、待ってください。私達は、単に`d.prototype.__proto__`が変更され、`d.prototype.constructor`は、それまで通り維持されることを望んでいました。そこで重要な意味があるのが、最初の行(`function __(){this.constructor = d;}`)です。これは`d.prototype = {__proto__：__.prototype, constructor：d}`を実現できます(これは関数の内側の`this`に対する`new`による効果のためです)。したがって`d.prototype.constructor`を復元しているので、我々が変更したものは、`__proto__`たった1つだけであり、それゆえ`d.prototype.__proto__ = b.prototype`となります。
+しかし、待ってください。私達は、単に`d.prototype.__proto__`が変更され、`d.prototype.constructor`は、それまで通り維持されることを望んでいました。そこで重要な意味があるのが、最初の行(`function __() { this.constructor = d; }`)です。これは`d.prototype = {__proto__ : __.prototype, constructor : d}`を実現できます(これは関数の内側の`this`に対する`new`による効果のためです)。したがって`d.prototype.constructor`を復元しているので、我々が変更したものは、`__proto__`たった1つだけであり、それゆえ`d.prototype.__proto__ = b.prototype`となります。
 
-#### `d.prototype.__ proto__ = b.prototype`の意味
+#### `d.prototype.__proto__ = b.prototype`の意味
 
 これを行うことによって、子クラスにメンバ関数を追加しつつ、その他のメンバは基本クラスから継承することができます。次の簡単な例で説明します:
 
@@ -141,4 +141,4 @@ var bird = new Bird();
 bird.walk();
 bird.fly();
 ```
-基本的に`bird.fly`は`bird.__ proto __.fly`(`new`は`bird.__proto__`が`Bird.prototype`を指すようにすることを思い出してください)から検索され、`bird.walk`(継承されたメンバー)は`bird.__proto__.__proto__.walk`から検索されます(`bird.__proto__ == Bird.prototype`、そして、`bird.__proto __.__proto__` == `Animal.prototype`です)。
+基本的に`bird.fly`は`bird.__proto__.fly`(`new`は`bird.__proto__`が`Bird.prototype`を指すようにすることを思い出してください)から検索され、`bird.walk`(継承されたメンバー)は`bird.__proto__.__proto__.walk`から検索されます(`bird.__proto__ == Bird.prototype`、そして、`bird.__proto__.__proto__` == `Animal.prototype`です)。

docs/classes.md

@@ -142,7 +142,7 @@ class Foo {
     }
 }
 ```
-これはTypeScriptの省略形を使うことができる一般的なパターンです。メンバにアクセス修飾子を付けることができ、それが自動的にクラス内に宣言され、コンストラクタからコピーされます。なので、前の例は次のように書き直すことが可能です(`public x：number`に注目してください)：
+これはTypeScriptの省略形を使うことができる一般的なパターンです。メンバにアクセス修飾子を付けることができ、それが自動的にクラス内に宣言され、コンストラクタからコピーされます。なので、前の例は次のように書き直すことが可能です(`public x:number`に注目してください)：
 
 ```ts
 class Foo {

docs/compiler/ast.md

@@ -5,7 +5,7 @@ ASTノードのドキュメントを構成するものは、２つのキーと
 
 いくつかの主要な `interface Node`のメンバがあります：
 * ソースファイル内のノードの`start`と`end`を識別する`TextRange`メンバ
-* ASTの中でノードの親となる`parent ?: Node`
+* ASTの中でノードの親となる`parent?: Node`
 
 `Node`のフラグと修飾子のために、いくつか他のメンバがあります。あなたはソースコード中で`interface Node`を検索することで見つけることができます。しかし、上記で言及したものは、ノードトラバーサル(node traversal)のために不可欠です。
 

docs/compiler/binder-declarations.md

@@ -1,7 +1,7 @@
 ### SymbolとDeclaration
 `node`と`symbol`の間のリンクは、いくつかの関数によって実行されます。ある1つの関数は、`SourceFile`NodeをSource File Symbolにバインドするために使われます。それは、`addDeclarationToSymbol`関数です。
 
-注：外部モジュールソースファイルの`Symbol`は`flags ： SymbolFlags.ValueModule`と`name： '"' + removeFileExtension(file.fileName) + '"'`)としてセットアップされています。
+注：外部モジュールソースファイルの`Symbol`は`flags : SymbolFlags.ValueModule`と`name: '"' + removeFileExtension(file.fileName) + '"'`)としてセットアップされています。
 
 ```ts
 function addDeclarationToSymbol(symbol: Symbol, node: Declaration, symbolFlags: SymbolFlags) {

docs/compiler/checker-global.md

@@ -10,4 +10,4 @@ forEach(host.getSourceFiles(), file => {
 });
 ```
 
-これは基本的にすべての`global`Symbolを`let globals：SymbolTable = {};`(`createTypeChecker`にあります)SymbolTableにマージします。`mergeSymbolTable`は主に`mergeSymbol`を呼び出します。
+これは基本的にすべての`global`Symbolを`let globals: SymbolTable = {};`(`createTypeChecker`にあります)SymbolTableにマージします。`mergeSymbolTable`は主に`mergeSymbol`を呼び出します。

docs/compiler/overview.md

@@ -52,7 +52,7 @@ TypeScriptコンパイラには、これらの主要部分にユーティリテ
 ## File: Utilities
 `core.ts`：TypeScriptコンパイラが使うコアユーティリティ。いくつか重要なもの：
 
-* `let objectAllocator：ObjectAllocator`：シングルトンのグローバルとして定義された変数です。それは、`getNodeConstructor`(Nodeは`parser`/`AST`を見るときに扱います)、`getSymbolConstructor`(シンボルは`binder`のときに扱います)、`getTypeConstructor`(型は`checker`で扱います)、 `getSignatureConstructor`(シグネチャはインデックス、シグネチャの呼び出しと構成物です)。
+* `let objectAllocator: ObjectAllocator`：シングルトンのグローバルとして定義された変数です。それは、`getNodeConstructor`(Nodeは`parser`/`AST`を見るときに扱います)、`getSymbolConstructor`(シンボルは`binder`のときに扱います)、`getTypeConstructor`(型は`checker`で扱います)、 `getSignatureConstructor`(シグネチャはインデックス、シグネチャの呼び出しと構成物です)。
 
 ## File： 主要なデータ構造
 `types.ts`には、コンパイラ全体で使用される、主要なデータ構造とインタフェースがあります。いくつかの重要なサンプルの抜粋です：

docs/compiler/parser-functions.md

@@ -24,10 +24,10 @@ function parseEmptyStatement(): Statement {
 これは、3つの重要な関数`createNode`、`parseExpected`と`finishNode`を示しています。
 
 #### `createNode`
-Parserの`createNode`関数`function createNode(kind：SyntaxKind、pos ?: number)：Node`はノードの作成、渡されたときの`SyntaxKind`のセットアップ、渡された場合の初期位置の設定(または、現在のスキャナの位置を使います)を行います。
+Parserの`createNode`関数`function createNode(kind: SyntaxKind, pos?: number): Node`はノードの作成、渡されたときの`SyntaxKind`のセットアップ、渡された場合の初期位置の設定(または、現在のスキャナの位置を使います)を行います。
 
 #### `parseExpected`
-Parserの`parseExpected`関数`function parseExpected(kind：SyntaxKind、diagnosticMessage ?: DiagnosticMessage)：boolean`は、Parserの状態に含まれる現在のトークンが目的の`SyntaxKind`と一致することをチェックします。そうでなければ、送られた`diagnosticMessage`を報告するか、`foo expected`の形式の一般的なものを作成します。これは内部的に`parseErrorAtPosition`関数(スキャン位置を使用します)を使用して良いエラー報告を行います。
+Parserの`parseExpected`関数`function parseExpected(kind: SyntaxKind, diagnosticMessage?: DiagnosticMessage): boolean`は、Parserの状態に含まれる現在のトークンが目的の`SyntaxKind`と一致することをチェックします。そうでなければ、送られた`diagnosticMessage`を報告するか、`foo expected`の形式の一般的なものを作成します。これは内部的に`parseErrorAtPosition`関数(スキャン位置を使用します)を使用して良いエラー報告を行います。
 
 ### `finishNode`
-Parserの`finishNode`関数`function finishNode <T extends Node>(node：T、end ?:: number)：T`はNodeの`end`位置や、`parserContextFlags`のように便利なモノを設定します。これは、このNodeを解析する前にエラーがあったとしても、同じようにパースされます(その場合、インクリメンタルパーシングでこのASTノードを再利用できません)。
+Parserの`finishNode`関数`function finishNode<T extends Node>(node: T, end?: number): T`はNodeの`end`位置や、`parserContextFlags`のように便利なモノを設定します。これは、このNodeを解析する前にエラーがあったとしても、同じようにパースされます(その場合、インクリメンタルパーシングでこのASTノードを再利用できません)。

docs/compiler/program.md

@@ -14,4 +14,4 @@ OEとの相互作用メカニズムを示します：
 
 ### ソースファイル
 
-programは、ソースファイルを取得するためのAPI`getSourceFiles()：SourceFile [];`を提供します。それぞれは、ASTのルートレベルのノード(`SourceFile`と呼ばれます)として表されます。
+programは、ソースファイルを取得するためのAPI`getSourceFiles(): SourceFile[];`を提供します。それぞれは、ASTのルートレベルのノード(`SourceFile`と呼ばれます)として表されます。

docs/generators.md

@@ -22,7 +22,7 @@ while (true) {
 }
 ```
 
-もちろんイテレータが終了した場合は、以下に示すように`{done：true}`の結果を得られます。
+もちろんイテレータが終了した場合は、以下に示すように`{ done: true }`の結果を得られます。
 
 ```ts
 function* idMaker(){

docs/jsx/others.md

@@ -2,16 +2,16 @@
 
 TypeScriptは、React with JSX以外のものをタイプセーフな方法で使用する機能を提供します。以下は、カスタマイズ可能なポイントを示していますが、これは高度なUIフレームワークの作成者向けです。
 
-* `"jsx" ： "preserve"`オプションを使って`react`形式の出力を無効にすることができます。これは、JSXが*そのままの状態で*出力されることを意味します。そして、あなた自身のカスタムトランスパイラを使用してJSX部分をトランスパイルすることができます
+* `"jsx" : "preserve"`オプションを使って`react`形式の出力を無効にすることができます。これは、JSXが*そのままの状態で*出力されることを意味します。そして、あなた自身のカスタムトランスパイラを使用してJSX部分をトランスパイルすることができます
 * `JSX`グローバルモジュールを使う：
     * `JSX.IntrinsicElements`インターフェースのメンバをカスタマイズすることで、どのHTMLタグが利用可能で、どのように型チェックされるかを制御することができます。
     * コンポーネントを使用する場合：
-        *デフォルトの`Interface ElementClass extends React.Component <any any> {}`宣言をカスタマイズすることによって、どのクラスがコンポーネントによって継承されなければならないかを制御できます
-        * どのプロパティが属性(デフォルトは`props`)の型チェックに使われるかを制御できます。`declare module JSX {interface ElementAttributesProperty {props：{};}`の宣言をカスタマイズすることで行います。
+        *デフォルトの`interface ElementClass extends React.Component<any, any> { }`宣言をカスタマイズすることによって、どのクラスがコンポーネントによって継承されなければならないかを制御できます
+        * どのプロパティが属性(デフォルトは`props`)の型チェックに使われるかを制御できます。`declare module JSX { interface ElementAttributesProperty { props: {}; } }`の宣言をカスタマイズすることで行います。
 
 ## `jsxFactory`
 
-`--jsxFactory <JSX factory name>`と `--jsx react`を一緒に渡すことで、デフォルトの`React`とは別のJSXファクトリを使うことができます。
+`--jsxFactory <JSX factory Name>`と `--jsx react`を一緒に渡すことで、デフォルトの`React`とは別のJSXファクトリを使うことができます。
 
 新しいファクトリ名は`createElement`関数を呼び出すために使われます。
 

docs/jsx/react.md

@@ -7,7 +7,7 @@
 私たちの[ブラウザ向けのクイックスタートに、すでにReactアプリケーションの開発のセットアップの仕方を説明しています](../quick/browser.md)。主なハイライトは次の通りです。
 
 * ファイル拡張子`.tsx`(`.ts`の代わりに)を使用してください。
-* あなたの`tsconfig.json`の`compilerOptions`で `"jsx" ： "react"を使ってください。
+* あなたの`tsconfig.json`の`compilerOptions`で `"jsx" : "react"`を使ってください。
 * JSXとReactの定義をあなたのプロジェクトにインストールします：(`npm i -D @types/react @types/react-dom`)。
 * reactを`.tsx`ファイルにインポートします(`import * as React from "react"`となります)。
 

docs/jsx/tsx.md

@@ -8,6 +8,6 @@ JSXの背景にある動機は、ユーザーがHTMLのようなビューをJava
 
 * あなたのJavaScriptと同じようにビューの型チェックをすること
 * ビューを操作するコンテキストを認識させる(つまり、従来のMVCでの*controller-view*の接続を強化する)。
-* HTMLのメンテナンスに、JavaScriptパターン(`Array.prototype.map`、`？： `、`switch`など)を(新しい代替(おそらくほとんど型付けされない)を作成する代わりに)再利用する。
+* HTMLのメンテナンスに、JavaScriptパターン(`Array.prototype.map`、`?:`、`switch`など)を(新しい代替(おそらくほとんど型付けされない)を作成する代わりに)再利用する。
 
 これにより、エラーの可能性が減り、ユーザーインターフェースの保守性が向上します。現時点でのJSXの主なユーザは[ReactJS from facebook](http://facebook.github.io/react/)です。ここではJSXの使い方について説明します。

docs/options/strictNullChecks.md

@@ -26,7 +26,7 @@ interface Member {
 }
 ```
 
-全ての`メンバー`が彼らの年齢を提供するわけではないので、`age`はオプションのプロパティです。 `age`の値は`undefined`かもしれません。
+全ての`Member`が彼らの年齢を提供するわけではないので、`age`はオプションのプロパティです。 `age`の値は`undefined`かもしれません。
 
 `undefined`はすべての悪の根です。ランタイムエラーが発生することがよくあります。実行時に`Error`をスローするコードを書くのは簡単です：