非公式のTypeScriptスタイルガイド
スタイルガイドについて意見を求められることはよくあります。個人的には、私は自分のチームやプロジェクトにコーディングスタイルをあまり強制してはいませんが、コードに一貫性が必要だと思う人がいるような状況において、基準として以下で述べるようなスタイルガイドがあることが役に立つのは確かです。個人的にはスタイルよりもはるかに強い意見を持っている観点があり、それについてはヒントの章で説明しています(例えば、型アサーションはよくない、プロパティーsetterはよくない、など)🌹
主要セクション:
変数と関数名には 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名にはPascalCase
を使います
理由:クラスに似ています。タイプです。
悪い
enum color {}
良い
enum Color {}
enumメンバに PascalCase
を使用する
理由:言語作成者、TypeScriptチームに従った慣例です。例えば
SyntaxKind.StringLiteral
です。他の言語からTypeScriptへの翻訳(コード生成)にも役立ちます。
悪い
enum Color {red}
良い
enum Color {Red}
明示的に使用不可能にするために、どちらも使用しないことを推奨します。
理由:これらの値は、値間の一貫した構造を維持するためによく使用されます。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)には、すでにフォーマットのサポートが組み込まれています。
例:
// 型の前にスペースを入れます。つまり、 foo:<スペース>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
を使ってファイルに名前を付けます。例えばaccordion.tsx
、myControl.tsx
、utils.ts
、map.ts
などです。
理由:多くのJSチームで慣習的です。
ユニオン型や交差型が必要な場合には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;}
そうでなければ、その日あなたを幸せにするものを使用してください。