Revisit configuration defaults

[dsherret]

Would be good to revist some of the defaults. For example, I don't like the switching between ' and "" for quotes (preferDouble)... I think it should be alwaysDouble.

Also, perhaps semiColons should be always by default and arrowFunction.useParentheses should be always.

[resolritter]

I really dislike not having spaces after keywords which precede a paren.

The first argument is: it creates assimetry between language constructs. Declaring an anonymous function can be

function(...)

but declaring a named function always requires a space after the keyword

function named(...)

which means sometimes you'd read "function space" and sometimes you'd read "function parens", even though the intent of declaring a new function is the same.

Mind you, "once" functions can also be named. I sometimes do that for readability's sake. For instance, suppose your method creates a returns a callback to unsubscribe. That can be

function createSubscription(...) {

  return function unsubscribe() {
    ...
  }
}

meaning you can't even have the discernment of "once functions never have space after the function keyword, but named functions always do" (which is pointless discernment in the first place).

---

Second argument is that "function" is a noun and "function(" isn't. Again, it goes against readability.

---

Third argument is that it also helps further differentiate between function application and function declaration. i.e. if one reads

someFunction(...)

he can easily differentiate that from declaration, which always start with a space before the paren.

Given that Prettier works this way by default, there's probably some previous discussion which you could take a look at for making the decision.

Finally, I'd use this same argumentation for all keywords which precede a paren. All of them should always have a space after it. Having the same construct start in different ways feels bad for readability.

[dsherret]

@resolritter thanks for your input! Defaults are important, but I know people are really passionate about how their code looks so these kind of things will always be configurable in dprint-plugin-typescript.

Point 1: I don't believe there's an inconsistency if it's viewed as a function expression name always having a leading space. Point 2: The same could be said about function calls, which goes against point 3. Point 3: I've personally never had a problem differentiating between them because of syntax highlighting. I could see this being a problem if someone didn't have syntax highlighting in their editor.

Side note, prettier has an inconsistency with type params in class expressions:

// formats as-is
const test1 = class<T> {}; // this should probably have a space before the type params
const test2 = function <T>() {};

I also think this is considered inconsistent with the "add a space after the function keyword":

// prettier does not put a space after the function keyword here
const test1 = function* test() {};

...so I kind of feel like "always have a space before function expression identifier" is the most consistent thing here, though perhaps the star could be considered as part of the function keyword. Anyway, I've opened dprint/dprint-plugin-typescript#12 to revisit the current config option in dprint because the current prettier functionality of function_expression_space_after_function_keyword is not specific enough.