Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lint using 🐊Putout: part 7 #4118

Merged
merged 4 commits into from Oct 4, 2022

Conversation

coderaiser
Copy link
Contributor

@coderaiser coderaiser commented Sep 14, 2022

image

Throughout your life advance daily, becoming more skillful than yesterday more skillful than today. This is never-ending.

(c) Yamamoto Tsunetomo "Hagakure"

The time is come for a new report of Xterm linting by 🐊v27:

☝️ As usual, any rule can be disabled.

Command used:

putout . --fix

Applied rules:

Current config for 🐊Putout v27:

{
    "rules": {
        "apply-is-array": ["on", {
            "inline": true
        }],
        "apply-comparison-order": "off",
        "new/remove-useless": "off",
        "remove-useless-return": "off",
        "typescript/remove-useless-parens": "off",
        "typescript/remove-useless-types-from-constants": "off",
        "remove-useless-type-conversion/with-double-negations": "off",
        "convert-typeof-to-is-type": "off",
        "apply-shorthand-properties": "off",
        "apply-destructuring": "off",
        "apply-numeric-separators": "off",
        "convert-assignment-to-comparison": "off",
        "convert-apply-to-spread": "off",
        "convert-math-pow": "off",
        "convert-for-to-for-of": "off",
        "convert-template-to-string": "off",
        "strict-mode": "off",
        "remove-useless-spread/object": "off",
        "remove-useless-array-constructor": "off",
        "remove-boolean-from-assertions": "off",
        "remove-iife": "off",
        "remove-console": "off",
        "remove-unused-variables": "off",
        "remove-useless-variables": "off",
        "merge-if-statements": "off",
        "promises/add-missing-await": "off",
        "promises/remove-useless-async": "off",
        "simplify-ternary": "off",
        "nodejs/convert-dirname-to-url": "off",
        "nodejs/declare-after-requir": "off",
        "declare-imports-first": "off",
        "apply-array-at": "off",
        "try-catch": "off"
    },
    "match": {
        "*.benchmark.ts": {
            "remove-unused-expressions": "off"
        },
        "SerializeAddon.test.ts": {
            "regexp/optimize": "off"
        },
        "Terminal.ts": {
            "logical-expressions/remove-duplicates": "off"
        }
    },
    "plugins": [
        "apply-shorthand-properties"
    ],
    "ignore": [
        "addons/*/lib/*.js",
        "*.benchmark.js",
        "*.md",
        "*.json",
        "*ignore",
        "*.yml",
        ".npmrc",
        "*.css",
        "out",
        "out-test",
        "demo"
    ]
}

Previous reports:

Copy link
Member

@jerch jerch left a comment

Choose a reason for hiding this comment

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

@coderaiser Went only halfway through and have 2 remarks:

  • Imho turning left/right side of conditionals is mostly unwanted. I think we want the local changing part on the left side, comparing to a more static right side.
  • Some conditionals do border testing against a left and a right side. Imho thats easier to grasp, if the the numbers stay in mathematically logical order. (thus left < var < right, which translates to left < v && v < right in JS).

If we can agree on my remarks above, I think the changelist will get much shorter.

@@ -4,7 +4,7 @@
*/

export class GridCache<T> {
public cache: (T | undefined)[][];
public cache: T[] | undefined[][];
Copy link
Member

Choose a reason for hiding this comment

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

I think this got the dimension wrong on T? Should be T[][] | undefined[][]?

Copy link
Member

Choose a reason for hiding this comment

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

Plus this doesn't feel like an improvement to me

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This transformation decrease cognitive load while reading the code. I can turn it of, that's not a problem :). But about benefit, here it is:

let info: (Info | SuperInfo | MagicInfo)[];

vs

let info: Info[] | SuperInfo[] | MagicInfo[];

In first case you need to unwrap types in your brain while reading the code. In second case you just reading the type information without unnecessary unwrapping the code.

Copy link
Member

Choose a reason for hiding this comment

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

I find the former easier to read and less error prone; info is an array of things, where things = Info | SuperInfo | MagicInfo

result.col + result.term.length >= this._terminal.cols ? result.row + 1 : result.row,
result.col + result.term.length >= this._terminal.cols ? 0 : result.col + 1,
this._terminal.cols <= result.col + result.term.length ? result.row + 1 : result.row,
this._terminal.cols <= result.col + result.term.length ? 0 : result.col + 1,
Copy link
Member

Choose a reason for hiding this comment

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

Over the years I've develop a habit/tendency for conditionals to write the changing entity on the left side comparing to something more statically on the right side, thus I'd prefer the old variant here. In the end its a matter of taste.

Same for several more occasions down below...

Copy link
Member

Choose a reason for hiding this comment

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

Not a fan too, this rule would best be ignored

@@ -311,7 +311,7 @@ describe('Search Tests', function (): void {
.replace(/\n/g, '\\n\\r');
}
fixture = fixture
.replace(/'/g, `\\'`);
.replace(/'/g, `'`);
Copy link
Member

Choose a reason for hiding this comment

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

This looks wrong to me compared to the original.

Copy link
Member

Choose a reason for hiding this comment

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

This is a code scanning alert for the PR now, it does nothing in its current state

Math.abs(imageData.data[offset + 1] - g) +
Math.abs(imageData.data[offset + 2] - b)) < threshold) {
threshold > (Math.abs(imageData.data[offset] - r) +
Math.abs(imageData.data[offset + 1] - g) + Math.abs(imageData.data[offset + 2] - b))) {
Copy link
Member

Choose a reason for hiding this comment

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

Basically same as above. Additionally if readability is an issue here, maybe introduce an interim variable? (No issue for me though...)

@@ -96,7 +96,7 @@ function evalButtonCode(code) {
}
if (move) {
action = 'move';
} else if (4 <= button && button <= 7) {
} else if (button >= 4 && button <= 7) {
Copy link
Member

Choose a reason for hiding this comment

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

Ok, here comes the exclusion from my habit above - if things test left/right borders, I prefer to write it with numbers to left and right side and variable in the middle. Always found that easier to grasp, visually resembling the "in the middle" aspect. Thus I'd prefer the original variant here.

Copy link
Member

Choose a reason for hiding this comment

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

I do this too as it's similar to 4 <= button <= 7 in maths

}

function isBoxOrBlockGlyph(codepoint: number): boolean {
return 0x2500 <= codepoint && codepoint <= 0x259F;
return codepoint >= 0x2500 && codepoint <= 0x259F;
Copy link
Member

Choose a reason for hiding this comment

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

Again left/right border testing...

@@ -231,11 +231,11 @@ export class DomRenderer extends Disposable implements IRenderer {
` background-color: ${this._colors.selectionInactiveBackgroundOpaque.css};` +
`}`;
// Colors
this._colors.ansi.forEach((c, i) => {
for (const [i, c] of this._colors.ansi.entries()) {
Copy link
Member

Choose a reason for hiding this comment

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

Yes much better, and since we are now on ES2015, should be officially supported. Also the for statement is way faster in general than the lisp style function mappers.

Copy link
Member

Choose a reason for hiding this comment

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

Another benefit is this works properly when debugging, instead of needing a breakpoint in the loop block

src/common/Color.ts Show resolved Hide resolved
@@ -2286,7 +2286,7 @@ export class InputHandler extends Disposable implements IInputHandler {
cSpace = 1;
}
accu[advance + i + 1 + cSpace] = subparams[i];
} while (++i < subparams.length && i + advance + 1 + cSpace < accu.length);
} while (subparams.length > ++i && accu.length > i + advance + 1 + cSpace);
Copy link
Member

Choose a reason for hiding this comment

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

I would not touch this and the following similar cases, as the execution order is very important. (The inline ++i in a conditional would even generate a warning in C/C++ for that reason).

@coderaiser
Copy link
Contributor Author

Just disabled unneeded rules :).

@Tyriar Tyriar self-assigned this Oct 4, 2022
@Tyriar Tyriar added this to the 5.1.0 milestone Oct 4, 2022
@Tyriar Tyriar enabled auto-merge October 4, 2022 16:52
@Tyriar Tyriar merged commit e1e8f28 into xtermjs:master Oct 4, 2022
@coderaiser coderaiser deleted the feature/lint-by-putout branch July 14, 2023 19:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants