Formalize code styles

[ST-DDT]

Clear and concise description of the problem

Currently it is not clear how some features should be implemented.

Suggested solution

It would be nice if there was a document that explains the code styles/guidelines.

Alternative

No response

Additional context

No response

[ST-DDT]

Where would we put this information optimally?

CONTRIBUTING.md or our docs?

[ST-DDT]

See also: https://github.com/faker-js/faker/discussions/806 - Naming policy for boolean options

[import-brain]

Where would we put this information optimally?

CONTRIBUTING.md or our docs?

Perhaps both places?

[Shinigami92]

When docs are written in two places decoupled from each other, one will fast get outdated and ignored. I would like to have one source of truth.

[Shinigami92]

Started a G-Docs: https://docs.google.com/document/d/1rOevJnJcUi5wmjS1ZWMjmsQME9w5pj94oFriFH-9Fq0/edit# Access needs to be granted manually

[ST-DDT]

Where would we put this information optimally? CONTRIBUTING.md or our docs?

Perhaps both places?

Maybe we could generate/include the docs page from the CONTRIBUTING.md.

[ST-DDT]

@since is required now. #1337

[ST-DDT]

The jsdocs part will be handled here: https://github.com/faker-js/faker/pull/1397

[xDivisionByZerox]

What is missing for this issue to be considered "done"?

Most of our code styles are enforced by eslint anyway. If we want a mandatory code style, we should configure a rule that handles that.

[matthewmayer]

I agree this is too generic to be useful and should be closed