スタイルガイド(コーディング規約)
最終更新
役に立ちましたか?
最終更新
役に立ちましたか?
非公式のTypeScriptスタイルガイド
スタイルガイドについて意見を求められることはよくあります。個人的には、私は自分のチームやプロジェクトにコーディングスタイルをあまり強制してはいませんが、コードに一貫性が必要だと思う人がいるような状況において、基準として以下で述べるようなスタイルガイドがあることが役に立つのは確かです。個人的にはスタイルよりもはるかに強い意見を持っている観点があり、それについてはで説明しています(例えば、型アサーションはよくない、プロパティーsetterはよくない、など)🌹
主要セクション:
変数と関数名には camelCase
を使います
理由:従来のJavaScript
悪い
良い
クラス名には PascalCase
を使います。
理由:これは実際には標準のJavaScriptではかなり一般的です。
悪い
良い
クラスメンバとメソッドの camelCase
を使う
理由:当然のことながら、変数と関数の命名規則に従います。
悪い
良い
名前にはPascalCase
を使います。
理由:クラスに似ています
メンバにはcamelCase
を使います。
理由:クラスに似ています
プレフィックスにI
をつけないでください
Reason: 慣例的ではないため。
lib.d.ts
はI
のない重要なインターフェース(例えば、Window、Documentなど)を定義します。
悪い
良い
名前にはPascalCase
を使います。
理由:クラスに似ています
メンバにはcamelCase
を使います。
理由:クラスに似ています
名前にPascalCase
を使用する
理由:TypeScriptチームに続くコンベンション。名前空間は事実上静的メンバを持つクラスです。クラス名は
PascalCase
=>名前空間名はPascalCase
です
悪い
良い
enum名にはPascalCase
を使います
理由:クラスに似ています。タイプです。
悪い
良い
enumメンバに PascalCase
を使用する
理由:言語作成者、TypeScriptチームに従った慣例です。例えば
SyntaxKind.StringLiteral
です。他の言語からTypeScriptへの翻訳(コード生成)にも役立ちます。
悪い
良い
null
vs undefined
明示的に使用不可能にするために、どちらも使用しないことを推奨します。
理由:これらの値は、値間の一貫した構造を維持するためによく使用されます。TypeScriptでは型を使用して構造を表します
悪い
良い
一般的に undefined
を使用してください(代わりに{valid:boolean,value?:Foo}
のようなオブジェクトを返すことを検討してください)
悪い
良い
APIまたは従来のAPIの一部である場合はnull
を使用します
理由:Node.jsの慣例通りです。NodeBackスタイルコールバックの
error
はnull
です。
悪い
良い
_truthy_を使用すると、オブジェクトが null
またはundefined
であるかどうかをチェックできます。
悪い
良い
== null
/!= null
(===
/!==
ではない)を使い、プリミティブにnull
/undefined
をチェックします。これはnull
/undefined
の両方に働きますが、他の_falsy_値(例:''
,0
,false
など)では機能しません。
悪い
良い
TypeScriptコンパイラには、非常に優れた言語フォーマットのサービスが付属しています。デフォルトで出力される出力は、チームの認知負荷を軽減するのに十分です。
例:
エスケープしない限り、シングルクォート('
)を使用することをお勧めします。
ダブルクォートはメリットがないわけではありません: オブジェクトをJSONに簡単にコピーできます。ユーザーが他の言語を使用して、引用文字を変更せずに作業できるようにします。たとえばアポストロフィを使用できます。例えば、
He's not going.
。しかし、私は、JSコミュニティが公正に決定したものから逸脱することはありません。
ダブルクォートを使用できない場合は、バックティック(`)を使用してみてください。
理由:これらは一般に、十分複雑な文字列の意図を表しています。
2
つのスペースを使います。タブではありません。
セミコロンを使用してください。
理由:明示的なセミコロンは、言語書式設定ツールで一貫した結果を得るのに役立ちます。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
vs interface
ユニオン型や交差型が必要な場合にはtype
を使います:
extend
やimplements
をしたいときはinterface
を使います。
そうでなければ、その日あなたを幸せにするものを使用してください。
==
or ===
コマンドラインでコードを自動的にフォーマットするには、 を使います。また、あなたのIDE(atom/ vscode/vs/sublime)には、すでにフォーマットのサポートが組み込まれています。
理由:他のJavaScriptチームがこれを行っています(、、、、、)。入力が簡単です(ほとんどのキーボードでシフトが必要ありません)。
理由:他のJavaScriptチームがこれを行っています(、、、、、、を参照してください)。 TypeScript/VSCodeチームは4つのスペースを使用しますが、間違いなくエコシステムの例外です。
どちらも。私はTypeScriptのコードベースで使われている===
を使用しています。