Updated Coding guidelines (markdown)

Coding-guidelines.md

@@ -1,42 +1,40 @@
 # ***STOP READING IMMEDIATELY***
 
-# THIS PAGE PROBABLY DOES **NOT** PERTAIN TO YOU
+## THIS PAGE PROBABLY DOES **NOT** PERTAIN TO YOU.
 
-# These are Coding Guidelines for ***Contributors to TypeScript***
+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
+--------------------
 
-# 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.**
+## **Please do not file issues about these guidelines.**
 
 ## Names
 
 1. Use PascalCase for type names.
-2. Do not use "I" as a prefix for interface 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.
+6. Do not use `_` as a prefix for private properties.
 7. Use whole words in names when possible.
 
-## Components 
+## 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.
+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'.
+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.
@@ -44,7 +42,7 @@
 
 ## Classes
 1. For consistency, do not use classes in the core compiler pipeline. Use function closures instead.
-	
+
 ## Flags
 1. More than 2 related Boolean properties on a type should be turned into a flag.
 
@@ -82,15 +80,15 @@ For a variety of reasons, we avoid certain constructs, and use some of our own.
 
 1. Use arrow functions over anonymous function expressions.
 2. Only surround arrow function parameters when necessary. <br />For example, `(x) => x + x` is wrong but the following are correct:
-   1. `x => x + x`
-   2. `(x,y) => x + y`
-   3. `<T>(x: T, y: T) => x === y`
+   - `x => x + x`
+   - `(x,y) => x + y`
+   - `<T>(x: T, y: T) => x === y`
 3. Always surround loop and conditional bodies with curly braces. Statements on the same line are allowed to omit braces.
 4. Open curly braces always go on the same line as whatever necessitates them.
 5. Parenthesized constructs should have no surrounding whitespace. <br />A single space follows commas, colons, and semicolons in those constructs. For example:
-   1. `for (var i = 0, n = str.length; i < 10; i++) { }`
-   2. `if (x < 10) { }`
-   3. `function f(x: number, y: string): void { }`
+   - `for (var i = 0, n = str.length; i < 10; i++) { }`
+   - `if (x < 10) { }`
+   - `function f(x: number, y: string): void { }`
 6. Use a single declaration per variable statement <br />(i.e. use `var x = 1; var y = 2;` over `var x = 1, y = 2;`).
 7. `else` goes on a separate line from the closing curly brace.
 8. Use 4 spaces per indentation.