Spaces for the code blocks that are not converted in GitHub pages correctly

Author: Ferie

Scripts/javascript.md

@@ -31,9 +31,11 @@
             - [Include blank line separator between imports and the rest of the code](#include-blank-line-separator-between-imports-and-the-rest-of-the-code)
 - [General best practices](../Generals/generals.md#general-best-practices)
 
+
 ---
 
 
+
 # JAVASCRIPT/TYPESCRIPT
 
 ## JAVASCRIPT
@@ -42,9 +44,12 @@
 
 When loading a script, the browser cannot continue until the entire file has been loaded. If we have JavaScript files in order to add functionality, we should place those files at the bottom, just before the closing body tag. This is a good performance practice and the results are quite noticeable.
 
+
+
 ### WHITESPACING AND FORMATTING
 
 #### ALWAYS USE BRACES
+
 ```TypeScript
 // Don't do this
 if (blah === "foo")
@@ -56,7 +61,10 @@ if (blah === "foo") {
 }
 ```
 
+
+
 #### SAME LINE BRACES
+
 ```TypeScript
 // Don't do this
 if (blah === "foo")
@@ -72,10 +80,13 @@ if (blah === "foo") {
 
 Main reason for this is simply that is a [JavaScript pitfall](https://stackoverflow.com/questions/3641519/why-do-results-vary-based-on-curly-brace-placement), but also it looks nicer.
 
+
+
 #### CHARACTER SPACING
 
 - Use a  single space between values, variables, and operators.
 - Use a single space after commas.
+
 ```TypeScript
 // Don't do this
 var x=123;
@@ -94,7 +105,10 @@ if (blah === "foo") {
 }
 ```
 
+
+
 #### USE 4 SPACES INDENTATION
+
 ```TypeScript
 // Don't do this
 if (blah === "foo") {
@@ -107,7 +121,10 @@ if (blah === "foo") {
 }
 ```
 
+
+
 #### ALWAYS USE SEMICOLON
+
 ```TypeScript
 // Don't do this
 var foo = true
@@ -124,7 +141,10 @@ if (foo) {
 }
 ```
 
+
+
 #### ALWAYS USE COMPARISON
+
 ```TypeScript
 // Don't do this
 if (blah == "foo") {
@@ -139,9 +159,11 @@ if (blah === "foo") {
 
 The use of the `==` equality operator allows frustrating bugs to slip through almost undetected while the use of the strict equality operator `===` does not run type coercion and therefore strictly evaluates the difference between two objects.
 
+
 ##### EXCEPTION
 
 Double equals comparison is allowed when comparing to `null`, because it will detect both `null` or `undefined` properties. [Here a great article about this exception](https://medium.com/javascript-in-plain-english/how-to-check-for-null-in-javascript-dffab64d8ed5#:~:text=One%20way%20to%20check,the%20double%20equality%20%3D%3D%20operator%3A&text=So%2C%20when%20programming%20to%20check,for%20either%20null%20or%20undefined%20.) and [here the MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness).
+
 ```TypeScript
 var foo = null;
 
@@ -151,7 +173,10 @@ if (foo == null && bar == null) {
 }
 ```
 
+
+
 #### AVOID COMPARING TO TRUE AND FALSE
+
 ```TypeScript
 // Don't do this as it's redundant
 if (foo === true) {
@@ -172,13 +197,18 @@ if (!bar) {
 }
 ```
 
+
+
 ### VARIABLES
 
 Use meaningful names when creating a variable: think about how the variable is going to serve your purpose. If the variable is caching a jQuery CSS selector, give it the name of the selector prefixed with `$`.
 
+
+
 #### CAMEL CASE VARIABLES
 
 The camel casing (or *camelCasing*) of JavaScript variables is accepted as the standard in most coding environments. The only exception is the use of uppercase to denote constants and underscores to denotate private variables (TypeScript).
+
 ```TypeScript
 // Don't do this
 let MyVar = "blah";
@@ -187,9 +217,12 @@ let MyVar = "blah";
 let myVar = "blah";
 ```
 
+
+
 #### BOOLEAN VARIABLES
 
 Booleans should be easily identifiable by the way they are named. Use prefixes like `is`, `can` or `has` to propose a question.
+
 ```TypeScript
 // Do this
 let isEditing = true;
@@ -199,7 +232,10 @@ obj.canEdit = true;
 user.hasPermission = true;
 ```
 
+
+
 ### USE TERNARY IF STATEMENT WHENEVER POSSIBLE AND EASY TO READ
+
 ```TypeScript
 // Don't do this
 if (foo) {
@@ -212,11 +248,16 @@ if (foo) {
 foo ? blah("foo") : blah("bar");
 ```
 
+
+
 ### AVOID POLLUTING THE GLOBAL NAMESPACE
 
 The chance of script and variable conflicts is increased, and both the source file and the namespace itself become littered with countless ambiguously named variables.
 
+
+
 ### CHECK EXISTANCE OF VARIABLES, ARRAYS AND OBJECTS
+
 ```TypeScript
 if (element) {
     // element exists
@@ -237,11 +278,14 @@ Please note that the same `if` statement is always returning `true` for all of
 - empty arrays `[]` and empty objects `{}`: because they are defined;
 - spaced string `'  '`: because it is a valid and defined object.
 
+
+
 ## TYPESCRIPT SPECIFIC STANDARDS
 
 ### WHITESPACING AND FORMATTING
 
 #### INCLUDE A SINGLE SPACE AFTER COLON AND BEFORE AND AFTER EQUAL
+
 ```TypeScript
 // Don't do this
 let str : string = 'This is a definition of a string';
@@ -254,7 +298,10 @@ let bool: boolean = false;
 let nr: number = 123;
 ```
 
+
+
 #### ALWAYS DEFINE STRICT TYPE WHEN DECLARING VARIABLES
+
 ```TypeScript
 // Don't do this
 let str = 'This is a definition of a string';
@@ -267,7 +314,10 @@ let bool: boolean = false;
 let nr: number = 123;
 ```
 
+
+
 #### INCLUDE A SINGLE SPACE BEFORE AND AFTER CURLY BRAKETS WHEN IMPORTING
+
 ```TypeScript
 // Don't do this
 import {ComponentName} from './path/to/component';
@@ -276,7 +326,10 @@ import {ComponentName} from './path/to/component';
 import { ComponentName } from './path/to/component';
 ```
 
+
+
 #### USE SINGLE QUOTES IN TYPESCRIPT FILES
+
 ```TypeScript
 // Don't do this
 import { ComponentName } from "./path/to/component";
@@ -289,7 +342,10 @@ import { ComponentName } from './path/to/component';
 let str: string = 'This is a definition of a string';
 ```
 
+
+
 #### INCLUDE BLANK LINE SEPARATOR BETWEEN IMPORTS AND THE REST OF THE CODE
+
 ```TypeScript
 // Don't do this
 import { ComponentName } from './path/to/component';