Skip to content

Commit 67c740e

Browse files
authored
Create CODING_STANDARDS.md
1 parent d91e3df commit 67c740e

1 file changed

Lines changed: 61 additions & 0 deletions

File tree

CODING_STANDARDS.md

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
# Coding Standards for this Project
2+
3+
## Coding guidelines for TypeScript
4+
5+
- The following standards are inspired from [Coding guidelines for TypeScript](https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines) (which you should follow when something is not specified in this document, although any pre-existing practices in a file being edited trump either style guide).
6+
7+
### Names
8+
9+
- Use `PascalCase` for type names.
10+
- Use `I` as a prefix for interface names only when an interface is implemented by a class.
11+
- Use `PascalCase` for enum values.
12+
- Use `camelCase` for function names.
13+
- Use `camelCase` for property names and local variables.
14+
- Do not use `_` as a prefix for private properties (unless used as backing properties).
15+
- Use whole words in names when possible.
16+
17+
### Types
18+
19+
- Do not export types/functions unless you need to share it across multiple components.
20+
- Do not introduce new types/values to the global namespace.
21+
- Shared types should be defined in `types.ts`.
22+
Within a file, type definitions should come first.
23+
24+
### null and undefined
25+
26+
Use undefined. Do not use null.
27+
28+
### Comments
29+
30+
- Comments must end with a period.
31+
- Use JSDoc style comments for functions, interfaces, enums, and classes.
32+
33+
### Strings
34+
35+
Use single quotes for strings.
36+
37+
### Imports
38+
39+
- Use ES6 module imports.
40+
- Do not use bare `import *`; all imports should either explicitly pull in an object or import an entire module, otherwise you're implicitly polluting the global namespace and making it difficult to figure out from code examination where a name originates from.
41+
42+
### Style
43+
44+
- Use `prettier` to format `TypeScript` and `JavaScript` code.
45+
- Use arrow functions over anonymous function expressions.
46+
- Always surround loop and conditional bodies with curly braces. Statements on the same line are allowed to omit braces.
47+
- Open curly braces always go on the same line as whatever necessitates them.
48+
- Parenthesized constructs should have no surrounding whitespace.
49+
- A single space follows commas, colons, and semicolons in those constructs. For example:
50+
51+
- `for (var i = 0, n = str.length; i < 10; i++) { }`
52+
- `if (x < 10) { }`
53+
- `function f(x: number, y: string): void { }`
54+
55+
- `else` goes on the same line from the closing curly brace.
56+
- Use 4 spaces per indentation.
57+
- All files must end with an empty line.
58+
59+
## Coding Standards for Python
60+
61+
Please follow the [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html).

0 commit comments

Comments
 (0)