スタイルガイド（コーディング規約）
非公式の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/!= null(===/!==ではない)を使い、プリミティブにnull/undefinedをチェックします。これはnull/undefinedの両方に働きますが、他の_falsy_値(例:'',0,falseなど)では機能しません。
悪い
if (error !== null) // undefinedを除外しない
良い
if (error != null) // nullも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;
}
- そうでなければ、その日あなたを幸せにするものを使用してください。
最終更新 1mo ago