microsoft/TypeScript
1
0
Fork 0
mirror of https://github.com/microsoft/TypeScript.git synced 2026-07-08 14:28:19 -05:00
Code Issues Packages Projects Releases 212 Wiki Activity

Updated Coding guidelines (markdown)

DanielRosenwasser
2014-12-03 17:33:37 -08:00
parent fd193809d8
commit 6470aaa553
1 changed files with 27 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
Coding guidelines.md

@@ -1,50 +1,51 @@
## Names
1. Use PascalCase for type names
2. Do not use "I" as a prefix for interface names
3. Use PascalCase for enum values
4. Use camelCase for function names
5. Use camelCase for property names and local variables
6. Do not use "_" as a prefix for private properties
1. Use PascalCase for type names.
2. Do not use "I" as a prefix for interface names.
3. Use PascalCase for enum values.
4. Use camelCase for function names.
5. Use camelCase for property names and local variables.
6. Do not use "_" as a prefix for private properties.
## Components
1. 1 file per logical component (e.g. parser, scanner, emitter, checker)
2. Do not add new files :)
3. files with ".generated" suffix are auto-generated, do not hand edit them
1. 1 file per logical component (e.g. parser, scanner, emitter, checker).
2. Do not add new files. :)
3. files with ".generated" suffix are auto-generated, do not hand edit them.
## Types
1. Do not export types/functions unless you need to share it across multiple components
2. Do not introduce new types/values to the global namespace
3. Shared types should be defined in 'types.ts'
4. Within a file, type definitions should come first
1. Do not export types/functions unless you need to share it across multiple components.
2. Do not introduce new types/values to the global namespace.
3. Shared types should be defined in 'types.ts'.
4. Within a file, type definitions should come first.
## Null and undefined:
1. Use **undefined**, do not use null
1. Use **undefined**, do not use null.
## General Assumptions
1. Consider objects like Nodes, Symbols, etc.. as immutable outside the component that created them. Do not change them
2. Consider arrays as immutable by default
1. Consider objects like Nodes, Symbols, etc.. as immutable outside the component that created them. Do not change them.
2. Consider arrays as immutable by default.
## Classes
1. For consistency Do not use classes in the core compiler pipeline. Use function closure instead
1. For consistency. do not use classes in the core compiler pipeline. Use function closures instead.
## Flags
1. More than 2 Boolean properties on a type should be turned into flags
1. More than 2 Boolean properties on a type should be turned into flags.
## Comments
1. Use JSDoc style comments
1. Use JSDoc style comments.
## Strings
1. Use double quotes for strings
2. All strings visible to the user need to be localized (have an entry in diagnosticMessages.json)
1. Use double quotes for strings.
2. All strings visible to the user need to be localized (make an entry in diagnosticMessages.json).
## Diagnostic Messages
1. Use a period at the end of a sentence
2. Use indefinite articles for indefinite entities
3. Definite entities should be named (this is for a variable name, type name, etc..)
4. When stating a rule, the subject should be in the singular (e.g. "An external module cannot..." instead of "External modules cannot...")
5. Use present tense
1. Use a period at the end of a sentence.
2. Use indefinite articles for indefinite entities.
3. Definite entities should be named (this is for a variable name, type name, etc..).
4. When stating a rule, the subject should be in the singular (e.g. "An external module cannot..." instead of "External modules cannot...").
5. 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