Element-web: JS SDK should have a max line length of 90 chars

Created on 24 Aug 2020  路  8Comments  路  Source: vector-im/element-web

With the new ESLint shared repo, we should have a line length of 120 everywhere. We want 120 for React / JSX usage, but we still prefer 90 for JS only things like the JS SDK.

bug maintenance p2

Most helpful comment

Ah I see... 馃槩 Well, I guess a larger discussion is needed then...

All 8 comments

I think @turt2live and I are eager to see this go away especially with the introduction of TypeScript into the repo with which a 90 length limit makes things less readable if anything

Ah I see... 馃槩 Well, I guess a larger discussion is needed then...

I guess with TypeScript you need to fit the types in as well, but I am surprised to hear that longer lines are the solution, given that many typed languages (Rust, C++, etc) are often used with lower line lengths.

I feel very strongly that line length limits are an artificial requirement to encourage the over-use of the Enter key. If we do have a length limit, it should be one of a recommendation/goal and not a build-breaking requirement. It should also be around 120 characters because typescript is more verbose as a typed language than others.

I guess I should represent my perspective more concretely then...

I find it much easier to work with lower line lengths, such as 80 - 90 chars, as it's much easier to fit two files side by side on a laptop screen without scrolling at these lengths.

I also find it very distracting when line wrapping suddenly changes or is not applied consistently, so that's why I would prefer to keep it as a linting error.

we can probably still solve that with general practices and policies rather than enforced linting. With a high length limit the intention is to allow for function definitions, console logging, etc and less so to encourage developers to make use of all 120 characters all the time. The majority of actual code should still be as least-nested as possible for readability and comparison. Most IDEs also have ways of peeking longer lines for the rare cases actual code runs over.

At code review time we'd have a check to make sure the formatting is legible and doesn't require too much side scrolling, much like how we already implicitly check to make sure we're not adding code that nests itself unreasonably.

js-sdk has its own issue tracker too fwiw

js-sdk has its own issue tracker too fwiw

Hmm, it does, but we don't commonly use it as a team at least, in my experience... That seems like a meta / retro point to discuss I guess.

Was this page helpful?
0 / 5 - 0 ratings