Страница:
Coding guidelines
Страницы
'this' in TypeScript
API Breaking Changes
All The Bots
Architectural Overview
Blog Post Ideas
Breaking Changes
Cancellation Support in tsserver
Coding guidelines
Common Errors
Compiler Internals
Compiler Options
Configuring MSBuild projects to use NuGet
Contributing to TypeScript
Debugging Language Service in VS Code
Docker Quickstart
FAQ
FAQs for API Consumers
Getting logs from TS Server in VS Code
Home
How the User Tests Work
How to maintain Definitely Typed tests
Integrating with Build Tools
JSDoc support in JavaScript
JSX
JavaScript Language Service in Visual Studio
Nightly drops
No New Utility Types
Node Target Mapping
Performance Tracing
Performance
Preferred Issue Titles
Providing Visual Studio Repro Steps
README
Release Activities
Resources
Roadmap
SECURITY
Setting Compiler Options in MSBuild projects
Spec conformance testing
Standalone Server (tsserver)
Tooling On The Compiler Repo
Triage Instructions
Triggering TypeScript Bot
Type Checking JavaScript Files
TypeScript's Release Process
TypeScript Deployment
TypeScript Design Goals
TypeScript Editor Support
TypeScript MSBuild In Depth
Typings for npm packages
Updating TypeScript in Visual Studio 2017
Useful Links for TypeScript Issue Management
Using TypeScript With ASP.NET 5
Using the Compiler API (TypeScript 1.4)
Using the Compiler API
Using the Language Service API
Using the New Language Service in Visual Studio 15 Preview
What's new in TypeScript
Writing Good Design Proposals
Writing a Language Service Plugin
tsconfig.json
19
Coding guidelines
Eli Barzilay редактировал(а) эту страницу 2021-05-24 18:31:13 -04:00
Содержание
- STOP READING IMMEDIATELY
- THIS PAGE PROBABLY DOES NOT PERTAIN TO YOU.
- These are Coding Guidelines for Contributors to TypeScript.This is NOT a prescriptive guideline for the TypeScript community.These guidelines are meant for contributors to the TypeScript project's codebase.We have chosen many of them for team consistency. Feel free to adopt them for your own team. AGAIN: This is NOT a prescriptive guideline for the TypeScript community
- Please do not file issues about these guidelines.
- Names
- Components
- Types
- null and undefined
- General Assumptions
- Classes
- Flags
- Comments
- Strings
- Diagnostic Messages
- Diagnostic Message Codes
- General Constructs
- Style
STOP READING IMMEDIATELY
THIS PAGE PROBABLY DOES NOT PERTAIN TO YOU.
These are Coding Guidelines for Contributors to TypeScript.
This is NOT a prescriptive guideline for the TypeScript community.
These guidelines are meant for contributors to the TypeScript project's codebase.
We have chosen many of them for team consistency. Feel free to adopt them for your own team.
AGAIN: This is NOT a prescriptive guideline for the TypeScript community
Please do not file issues about these guidelines.
Names
- Use PascalCase for type names.
- Do not use
I
as a prefix for interface names. - Use PascalCase for enum values.
- Use camelCase for function names.
- Use camelCase for property names and local variables.
- Do not use
_
as a prefix for private properties. - Use whole words in names when possible.
Components
- 1 file per logical component (e.g. parser, scanner, emitter, checker).
- Do not add new files. :)
- files with
.generated.*
suffix are auto-generated, do not hand-edit them.
Types
- Do not export types/functions unless you need to share it across multiple components.
- Do not introduce new types/values to the global namespace.
- Shared types should be defined in
types.ts
. - Within a file, type definitions should come first.
null
and undefined
- Use
undefined
. Do not use null.
General Assumptions
- Consider objects like Nodes, Symbols, etc. as immutable outside the component that created them. Do not change them.
- Consider arrays as immutable by default after creation.
Classes
- For consistency, do not use classes in the core compiler pipeline. Use function closures instead.
Flags
- More than 2 related Boolean properties on a type should be turned into a flag.
Comments
- Use JSDoc style comments for functions, interfaces, enums, and classes.
Strings
- Use double quotes for strings.
- All strings visible to the user need to be localized (make an entry in diagnosticMessages.json).
Diagnostic Messages
- Use a period at the end of a sentence.
- Use indefinite articles for indefinite entities.
- Definite entities should be named (this is for a variable name, type name, etc..).
- When stating a rule, the subject should be in the singular (e.g. "An external module cannot..." instead of "External modules cannot...").
- Use present tense.
Diagnostic Message Codes
Diagnostics are categorized into general ranges. If adding a new diagnostic message, use the first integral number greater than the last used number in the appropriate range.
- 1000 range for syntactic messages
- 2000 for semantic messages
- 4000 for declaration emit messages
- 5000 for compiler options messages
- 6000 for command line compiler messages
- 7000 for noImplicitAny messages
General Constructs
For a variety of reasons, we avoid certain constructs, and use some of our own. Among them:
- Do not use
for..in
statements; instead, usets.forEach
,ts.forEachKey
andts.forEachValue
. Be aware of their slightly different semantics. - Try to use
ts.forEach
,ts.map
, andts.filter
instead of loops when it is not strongly inconvenient.
Style
- Use arrow functions over anonymous function expressions.
- Only surround arrow function parameters when necessary.
For example,(x) => x + x
is wrong but the following are correct:x => x + x
(x,y) => x + y
<T>(x: T, y: T) => x === y
- Always surround loop and conditional bodies with curly braces. Statements on the same line are allowed to omit braces.
- Open curly braces always go on the same line as whatever necessitates them.
- Parenthesized constructs should have no surrounding whitespace.
A single space follows commas, colons, and semicolons in those constructs. For example:for (var i = 0, n = str.length; i < 10; i++) { }
if (x < 10) { }
function f(x: number, y: string): void { }
- Use a single declaration per variable statement
(i.e. usevar x = 1; var y = 2;
overvar x = 1, y = 2;
). else
goes on a separate line from the closing curly brace.- Use 4 spaces per indentation.
User documentation
News
Debugging TypeScript
- Performance
- Performance-Tracing
- Debugging-Language-Service-in-VS-Code
- Getting-logs-from-TS-Server-in-VS-Code
- JavaScript-Language-Service-in-Visual-Studio
- Providing-Visual-Studio-Repro-Steps
Contributing to TypeScript
- Contributing to TypeScript
- TypeScript Design Goals
- Coding Guidelines
- Useful Links for TypeScript Issue Management
- Writing Good Design Proposals
- Compiler Repo Notes
- Deployment
Building Tools for TypeScript
- Architectural Overview
- Using the Compiler API
- Using the Language Service API
- Standalone Server (tsserver)
- TypeScript MSBuild In Depth
- Debugging Language Service in VS Code
- Writing a Language Service Plugin
- Docker Quickstart
FAQs
The Main Repo