Use single/double quotes consistently

[slikts]

The Handbook currently uses both single and double quotes, sometimes even in the same example:

var name: string = "bob";
name = 'smith';

Settling on just one style would look better.

[mhegazy]

A PR would be appreciated. Also we should add a linter rule for it.

[DanielRosenwasser]

Tagging @wanderer06 because he asked on Gitter.

It was used in the same example because the point was that you can use either type of string literal. If you see other locations, we'll take a PR, but I'm going to close this unless you've found others.

[wanderer06]

I'd say it depends on the level of consistency you'd like to achieve. Generally the quoting style is consistent within an example, but not across multiple chunks of code.

One example I can think of is the Writing declaration files page, where it uses single quotes in one example:

// Super-chainable library for eagles
import Eagle = require('./eagle');

// Call directly
Eagle('bald').fly();

// Invoke with new
var eddie = new Eagle('Mille');

// Set properties
eddie.kind = 'golden';

But switches to double just down below:

import sayHello = require("say-hello");
sayHello("Travis");

Then there are cases where using a string literal in code description seems at random:

/**
 * Takes a string and adds "padding" to the left.
 * If 'padding' is a string, then 'padding' is appended to the left side.
 * If 'padding' is a number, then that number of spaces is added to the left side.
 */

Sometimes a return value, type or variable will be quoted in some comments, but not in others:

Variable Declaration.md
function f() {
    var a = 10;
    return function g() {
        var b = a + 1;
        return b;
    }
}

var g = f();
g(); // returns 11;

Down below:

function f(shouldInitialize: boolean) {
    if (shouldInitialize) {
        var x = 10;
    }

    return x;
}

f(true);  // returns '10'
f(false); // returns 'undefined'

Or

function foo() {
    // okay to capture 'a'
    return a;
}

// illegal call 'foo' before 'a' is declared
// runtimes should throw an error here
foo();

let a;

let animal = new Animal("Goat");
let rhino = new Rhino();
let employee = new Employee("Bob");

animal = rhino;
animal = employee; // Error: Animal and Employee are not compatible

There are cases where this will be quoted as md quote inside a code block, making it use neither quoting style:

//...
    createCardPicker: function() {
        // Notice: the line below is now a lambda, allowing us to capture `this` earlier
        return () => {
//...

Interfaces.md includes some reversed quotes:

In the above example, ‘SelectableControl’ contains all of the members of ‘Control’, including the private ‘state’ property. Since ‘state’ is a private member it is only possible for descendants of ‘Control’ to implement ‘SelectableControl’. This is because only descendants of ‘Control’ will have a ‘state’ private member that originates in the same declaration, which is a requirement for private members to be compatible.

Should the docs use single or double quotes consistently throughout all examples?
Does this apply to the text outside the code blocks as well?
ie this is called 'Declaration Merging' vs this is called "Declaration Merging".

What about getting started file examples?

var browserify = require("browserify");
var tsify = require("tsify");

browserify()
    .add('main.ts')
    .plugin('tsify', { noImplicitAny: true })
    .bundle()
    .pipe(process.stdout);

[DanielRosenwasser]

In code samples

• We use single quotes in comments to refer to entities.
• All strings should be double-quoted unless as part of the example.

Outside of code samples

• References to code should use backticks (```).
• New terms should be in italics, though I could see double-quotes being acceptable in some contexts.

[DanielRosenwasser]

/**
 * Takes a string and adds "padding" to the left.
 * If 'padding' is a string, then 'padding' is appended to the left side.
 * If 'padding' is a number, then that number of spaces is added to the left side.
 */

This was to basically indicate that "padding" is a kind of wishy-washy term, and other uses of "padding" refer to the parameter name.