Explicit coding rules

[fflorent]

Context

Some coding styles are unwritten and not covered by eslint.

Proposed solution

Explicit them for now, let's discuss on them.

Once this PR is merged, we will be able to later work on writing Eslint rules when possible and remove the associated coding styles from the documentation.

Has this been tested?

• 👍 yes, I added tests to the test suite
• 💭 no, because this PR is a draft and still needs work
• 🙅 no, because this is not relevant here
• 🙋 no, because I need help

[manuhabitela]

Hey :)

I see great value in having conventions that help us avoid mistakes, and trying to automate them if we can. Like the i18n strings, it's a perfect example.

About the other formatting conventions you mention, imports order and spacing, I don't have any strong opinion.

Personally I don't follow any of these as of today, I just follow the eslint rules.

You say Some coding styles are unwritten and not covered by eslint., but on my side I think I never had any feedback on my imports order, something I really don't specifically care much about. So maybe that is something on its own to solve: why is there sometimes attention given to this, and sometimes not.

I agree with this PR in the sense that I think any strictly-formatting convention agreed upon, should be automated by eslint. Non-automated, strictly formatting rules, often result in nitpick comments in PRs, and are globally tiresome rules to follow and enforce as a whole. So while I see value in having to be "manually" careful in how we write i18n strings, I don't see value in having to be careful with the imports order.

[hexaltation]

Thanks for the job

[fflorent]

Just to clarify regarding @manuhabitela's comment above, my intent is to be descriptive about the unwritten rules, not normative (or at least I am prescriptive when willing to have those rules written down and not having to discover styling rules during PRs).

There are rules I don't personally like (especially local conventions, I don't know whether we will one day have a suitable Eslint rule for that).

About the other formatting conventions you mention, imports order and spacing, I don't have any strong opinion.

Personally I don't follow any of these as of today, I just follow the eslint rules.

For these ones, I see values: when imports are ordered, we can more easily avoid duplication of imports when rebasing branches.
When imports are otherwise not ordered, you may not see a library or a module is being imported twice.

So maybe that is something on its own to solve: why is there sometimes attention given to this, and sometimes not.

Agree.

[paulfitz]

These rules look accurate to me. I am probably the most picky about some of them? I don't think the individual rules are that important, they are just trying to keep the codebase coherent over time while avoiding disruptive changes that has everyone rebasing and cursing. But we could do a big lint change one of these days if someone were up for leading it.

[hexaltation]

Hello @paulfitz ,

But we could do a big lint change one of these days if someone were up for leading it.

We are up to take the lead on this task.
Can you please merge the doc, so that we do not loose tack of the rules between now and the "big lint change"?

Tkanks in advance.