Exceeding maximum line length of 120 characters

[ilesar]

I think we should be less strict about this rule. Just to prove my point, I'm attaching a screenshot with proper class declaration where TSLint gives me an error. Maybe the class names are a bit long, but they they are named so code readability wouldn't suffer.

If we vote this through, I'll make a pull request.

[krukru]

I like how the rule is stated for PHP (PSR-2)
There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
We can apply the same rule to JS

[bonzzy]

Tslint supports ignore patterns, so i suggest we could add a few exclude patterns instead.
For example
"max-line-length": [true, {"limit": 120, "ignore-pattern": "^import |^export {(.*?)}"}]

[krukru]

I would not like to have exceptions.
The question is how bad is 1) compared to 2)

export class SnapshotResolver extends BaseResolver<PatchableOrderBook> implements ResolvableInterface<PatchableOrderBook> {
    const foo = this.bar();
} 

export class SnapshotResolver extends BaseResolver<PatchableOrderBook>
        implements ResolvableInterface<PatchableOrderBook> {
    const foo = this.bar();
} 

I would go with 2) for readability but we can bend the rule if you think it is too strict

[bonzzy]

I think we should avoid very long lines. But that is only my personal opinion.

I think 2) is easier to read.

[leovujanic]

What about tests and their descriptive names or long Error messages?

[krukru]

If we want all code to be visible without scrolling, then there should be no difference

On Fri, 30 Mar 2018 at 13:08, Leo Vujanić ***@***.***> wrote: What about tests and their descriptive names or long Error messages? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJmyNlsBtXRah2bmK7KXw6dGK_vJSXNFks5tjhIbgaJpZM4SwauY> .

-- *MARKO KRULJAC* #SOFTWARE_DEVELOPER_IN_TEST [email protected] +385 91 2493 136 www.degordian.com <http://www.degordian.com/?utm_source=signature&utm_medium=email&utm_content=marko.kruljac&utm_campaign=_d_email%20signature> www.facebook.com/Degordian

[leovujanic]

Yes, but code visibility is defined by screen size, font size etc. Also in the editor, you can set up to use a soft wrap option.
I think that lines should not be longer than 120 chars but that should be only the soft limit because I do not want to change this

throw new Error(`Invalid precision. Precision must be 0 or positive number less than ${maxSafeString.length - 1}`);

to this:

throw new Error(`Invalid precision. Precision must be 0 or positive number 
less than ${maxSafeString.length - 1}`);

or this:

const msg = `Invalid precision. Precision must be 0 or positive 
number less than ${maxSafeString.length - 1}`;
throw new Error(msg);

Sometimes I think we are making idiots from people because there should be a minimum dose of responsibility and behavior manners to respect the rule and not to write everything in one line only in exceptional cases.

[krukru]

@leovujanic I am sorry if you think someone is making a fool of people. The idea is to have a consistent code style that is readable from any platform (github included) and not to make a fool of anyone.
Detecting when is it ok to have more then 120 characters is a difficult problem for humans, and even harder for linters. This is why we are either always strict or always permissive.

We could modify the rule to ignore strings, multiline broken strings are difficult to search and some style guides with fixed line length allow for long strings.

If you can write the rule for it in tslint, we can discuss about including it

[leovujanic]

No, I don't think that someone is making a fool of people intentionally, but I don't understand why can't we just say "Please keep your lines under 120 chars". I see a lot of /* tslint:disable:.... */ comments in code so maybe that linter is too strict. What would be the solution for implementing advice from PSR standard that you mentioned before ( #23 (comment))?

[bonzzy]

Check possible solution to this problem on degordian/js-coding-standards/issues/26

[bonzzy]

Can we close this?

[krukru]

I think that we did not get enough strong opinions that this should be enforced as a hard limit.
My advice is to keep it within 120 characters wide, but we will not reject PRs with lines that are longer.