非公式のTypeScriptスタイルガイド

スタイルガイドについて意見を求められることはよくあります。個人的には、私は自分のチームやプロジェクトにコーディングスタイルをあまり強制してはいませんが、コードに一貫性が必要だと思う人がいるような状況において、スタイルを寄せる基準として以下で述べるようなスタイルガイドに言及することが役立つのは確かです。私はスタイルよりもはるかに強い意見を持っている観点があり、それについてはヒントの章で扱っています（例えば、型アサーションはよくない、プロパティーsetterはよくない、など）🌹

主要セクション：

• ​変数​

• ​クラス​

• ​インタフェース​

• ​タイプ​

• ​名前空間​

• ​Enum​

• ​nullとundefined​

• ​書式設定​

• ​一重引用符と二重引用符​

• ​Tabs vs. Spaces​

• ​セミコロンを使用​

• ​配列​

• ​ファイル名​

• ​type vs interface​

変数と関数

• 変数と関数名には camelCaseを使います

理由：従来のJavaScript

悪い

var FooVar;
function BarFunc() { }

良い

var fooVar;
function barFunc() { }

クラス

• クラス名には PascalCaseを使います。

理由：これは実際には標準のJavaScriptではかなり一般的です。

悪い

class foo { }

良い

class Foo { }

• クラスメンバーとメソッドの camelCaseを使う

理由：当然のことながら、変数と関数の命名規則に従います。

悪い

class Foo {
    Bar: number;
    Baz() { }
}

良い

class Foo {
    bar: number;
    baz() { }
}

インタフェース

• 名前にはPascalCaseを使います。

理由：クラスに似ています

• メンバーにはcamelCaseを使います。

理由：クラスに似ています

• プレフィックスにIをつけないでください

Reason： 慣例的ではないため。lib.d.tsはIのない重要なインターフェース(例えば、Window、Documentなど)を定義します。

悪い

interface IFoo {
}

良い

interface Foo {
}

タイプ

• 名前にはPascalCaseを使います。

理由：クラスに似ています

• メンバーにはcamelCaseを使います。

理由：クラスに似ています

名前空間

• 名前にPascalCaseを使用する

理由：TypeScriptチームに続くコンベンション。名前空間は事実上静的メンバーを持つクラスです。クラス名はPascalCase=>名前空間名はPascalCaseです

悪い

namespace foo {
}

良い

namespace Foo {
}

Enum

• enum名にはPascalCaseを使います

理由：クラスに似ています。タイプです。

悪い

enum color {
}

良い

enum Color {
}

• enumメンバーに PascalCaseを使用する

理由：言語作成者、TypeScriptチームに従った慣例です。例えばSyntaxKind.StringLiteralです。他の言語からTypeScriptへの翻訳(コード生成)にも役立ちます。

悪い

enum Color {
    red
}

良い

enum Color {
    Red
}

Null対Undefined

• 明示的に使用不可能にするためにどちらも使用しないことを推奨します。

理由：これらの値は、値間の一貫した構造を維持するためによく使用されます。TypeScriptでは型を使用して構造を表します

悪い

let foo = {x:123,y:undefined};

良い

let foo:{x:number,y?:number} = {x:123};

• 一般的に undefinedを使用してください(代わりに{valid:boolean,value?:Foo}のようなオブジェクトを返すことを検討してください)

悪い

return null;

良い

return undefined;

• APIまたは従来のAPIの一部である場合はnullを使用します

理由：Node.jsの慣例通りです。NodeBackスタイルコールバックのerrorはnullです。

悪い

cb(undefined)

良い

cb(null)

• truthyを使用すると、オブジェクトが nullまたはundefinedであるかどうかをチェックできます。

悪い

if (error === null)

良い

if (error)

• プリミティブにnull/undefinedをチェックするには、== undefined/!= undefinedを使います。これはnull/undefinedの両方に働きます。しかし、他のfalsy値には使わないでください(例:'',0,false)。

悪い

if (error !== null)

良い

if (error != undefined)

フォーマット

TypeScriptコンパイラには、非常に優れた言語フォーマットのサービスが付属しています。デフォルトで出力される出力は、チームの認知負荷を軽減するのに十分です。

コマンドラインでコードを自動的にフォーマットするには、 tsfmt を使います。また、あなたのIDE(atom/ vscode/vs/sublime)には、すでにフォーマットサポートが組み込まれています。

例：

// Space before type i.e. foo:<space>string
const foo: string = "hello";

引用符

• エスケープしない限り、シングルクォート(')を使用することをお勧めします。

理由：他のJavaScriptチームがこれを行っています(airbnb、標準、npm、NodeJS、google/angular、facebook/react)。入力が簡単です(ほとんどのキーボードでシフトが必要ありません)。Prettierチームもシングルクォートを勧めています​

ダブルクォートはメリットがないわけではありません: オブジェクトをJSONに簡単にコピーできます。ユーザーが他の言語を使用して、引用文字を変更せずに作業できるようにします。たとえばアポストロフィを使用できます。例えば、He's not going.。しかし、私は、JSコミュニティが公正に決定したものから逸脱することはありません。

• ダブルクォートを使用できない場合は、バックティック(`)を使用してみてください。

理由：これらは一般に、十分複雑な文字列の意図を表しています。

スペース

• 2スペースを使います。タブではありません。

理由：他のJavaScriptチームがこれを行っています(airbnb、idiomatic、標準、npm、node、google/angular、facebook/reactを参照してください)。 TypeScript/VSCodeチームは4つのスペースを使用しますが、間違いなくエコシステムの例外です。

セミコロン

• セミコロンを使用してください。

理由：明示的なセミコロンは、言語書式設定ツールで一貫した結果を得るのに役立ちます。Missing ASI(Automatic semicolon insertion: 自動セミコロン挿入)は、例えばfoo() \n (function(){})を単一の文(2つではなく)と間違えます。TC39でも同様に勧められています。

配列

• 配列にfoos:Array<Foo>の代わりにfoos:Foo[]として配列にアノテーションをつけます。

理由：読みやすい。TypeScriptチームによって使用されています。脳が[]を検出するように訓練されているので、何かが配列であることを知りやすくなります。

ファイル名

camelCaseを使ってファイルに名前を付けます。例えばaccordian.tsx、myControl.tsx、utils.ts、map.tsなどです。

理由：多くのJSチームで慣習的です。

type vs interface

• ユニオン型や交差型が必要な場合にはtypeを使います：

type Foo = number | { someProperty: number }

• extendやimplementsをしたいときはinterfaceを使います。

interface Foo {
  foo: string;
}
interface FooBar extends Foo {
  bar: string;
}
class X implements FooBar {
  foo: string;
  bar: string;
}

• そうでなければ、その日あなたを幸せにするものを使用してください。