lib: remove unnecessary symbols

[ghost]

Remove (...), because this is a simple,sensitive expression.

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows [commit guidelines]

[Trott]

This change causes the else branch to be taken when n is equal to MAX_HWM. That seems less efficient then the if branch. and possibly a bug?

[ghost]

OK, Thanks I've removed that modification.

[richardlau]

This appears to be the sort of stylistic changes being discussed in #22351.

[ghost]

@richardlau：But you have to admit that this (……) is useless here.
And this makes your style not in union :)

Please compare with them:

1. node/lib/_stream_readable.js

   Line 78 in 6acb550

   isDuplex=streaminstanceofStream.Duplex;

2. node/lib/_stream_readable.js

   Line 150 in 6acb550

   constisDuplex=(thisinstanceofStream.Duplex);

So sometimes for those useless styles or styles aren't necessary (But not change to a style that will make bad effects on what the codes were). I think it worth changing to make tiny (but not much) refactors.

Hope you can understand what I mean here.

[BridgeAR]

I am -0.5 on this. There might be a eslint rule for this and it would be fine for me with a rule if that does not result in to much churn.

[mscdex]

FWIW I generally prefer including conditional statements like this in parentheses when being assigned as a value as it makes it easier to read and that's why these parentheses currently exist there.

[ghost]

I think it's time to have a disscussion on when to refactor（IMO）：

First, as what I said above, refactoring codes cannot make bad effects on what the codes were (including making performance lower than before, making hard to read / understand, or making unit tests too complicated to complete……ect). Anyway, any bad effects resulted by refactoring will be abandoned. And what @richardlau's closed example just belongs to this (because using IndexOf's performance isn't better, even lower than three if's. So this refactor isn't necessary).

Second, to make codes in style union. I mostly agree with what @BridgeAR said, but I have to say that even if when we all pass the eslint's checks, sometimes the stylish still will have useless or unnecessary things to be removed (Just like this fixture above). And the reason why we will do refactoring is that we should clean up codes to make them in union and look better, and obviously our Nodejs project belongs to the developers all over the world. Since we cannot control different people's options of code style, why don't we make them in union for obviously stylish problems? :)

As for @mscdex's suggestions, this is still in discussion. If most of you think for a condition wrapped by (……) —— I mean if the style looks better (though I disagree with that), I'll still make a change according to what you said (Maybe

node/lib/_stream_readable.js

Line 78 in 6acb550

isDuplex=streaminstanceofStream.Duplex;

should be changed by wrapping it with (……)).

[addaleax]

I think larger patches are much more relevant when talking about “churn”. A +1/-1 change is not getting in the way of anything – if it can be backported, great, if it can’t, it doesn’t make anything worse either in terms of merge conflicts.

[ghost]

@addaleax：Yes I agree with you.

And I think for those rules we should refactor codes:

1. Code styles that makes us feel puzzled, hard to understand.

2. Codes with useless things or symbols.

3. Codes with unused parameters, varaiables,……ect.

4. A function with the same logic but written everywhere when needed, we should take this into a global locaion.

5. Code styles that makes a huge performance improved (benchmark test can prove this, but what is the defination of a huge performace? 10% or 20%? This needs discussion).

Any other better ideas in details? It's interesting to share ideas and experience with all of you here :D

[addaleax]

CI: https://ci.nodejs.org/job/node-test-pull-request/16804/

I’d prefer to land this in the next few days rather than having it hang in limbo, given that there are 8 approving reviews at this point.

[Trott]

Resume build: https://ci.nodejs.org/job/node-test-pull-request/16920/

[mcollina]

LGTM

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/16997/

[ghost]

Maybe this can be merged?

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/17123/

[addaleax]

Resume CI: https://ci.nodejs.org/job/node-test-pull-request/17133/

[tniessen]

CI was stopped, resuming again... https://ci.nodejs.org/job/node-test-pull-request/17149/

[Trott]

Only red CI was arm-fanned. Re-run: https://ci.nodejs.org/job/node-test-commit-arm-fanned/3457/

[addaleax]

Landed in 9c6f59e 😄

[ghost]

Thanks all for your help!