Skip to content
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.

Fix linting errors. #1610

Merged
merged 1 commit into from
Nov 15, 2017
Merged

Fix linting errors. #1610

merged 1 commit into from
Nov 15, 2017

Conversation

rxl881
Copy link
Contributor

@rxl881 rxl881 commented Nov 15, 2017

No description provided.

@rxl881 rxl881 requested a review from ara4n November 15, 2017 10:25
@ara4n
Copy link
Member

ara4n commented Nov 15, 2017

I HATE our linter. thanks.

@ara4n ara4n merged commit ec33806 into develop Nov 15, 2017
@@ -376,8 +383,7 @@ class Tinter {
const attr = this.svgAttrs[k];
for (let l = 0; l < this.keyHex.length; l++) {
if (tag.getAttribute(attr) &&
tag.getAttribute(attr).toUpperCase() === this.keyHex[l])
{
tag.getAttribute(attr).toUpperCase() === this.keyHex[l]) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the style we would generally go with is

if (reallyLongstuff &&
    otherReallyLongStuff
) {
    bla

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

says who, though? i've never used that style in my life, and it's not in our code style (https://github.com/matrix-org/matrix-react-sdk/blob/master/code_style.md), and I don't understand why we are enforcing lint rules which are more extreme than our code style!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never seen that, actually. We really ought to update the linting configuration to reflect that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. just to be clear: linting is meant to fix bugs and help legibility in terms of enforcing a consistent style - but there is no benefit in making it needlessly over-restrictive (especially based on personal taste, when there's already a formal style). I don't think anyone's eyes are ever going jar at where the { goes after an multiline if clause, so in the end it just burns time having to fix up unnecessary linting errors. In other words: we should introduce linting where it helps us, not slows us down, and certainly not for the sake of arbitrary consistency.

As Emerson said (and I think the old MX Coding Style guide as written by vdh & myself about 15 years ago, which you have more of an excuse not to have read ;): A foolish consistency is the hobgoblin of little minds.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to having the lint less strict. It's getting tiring to have an "appease the linter" commit on every PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't find it that bad, but then I do have the linting built into my IDE, so there's no extra "appeasing" step in general.

@rxl881 rxl881 deleted the rxl881/lintingErrors branch November 15, 2017 18:17
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants