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

lib: remove some yoda statements #18746

Closed
wants to merge 1 commit into from
Closed

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Feb 13, 2018

This enables the yoda eslint rule and prohibits statements like false === variable. They are mainly historically and if someone would add a new one, I guess it would be complained about while reviewing. This makes that complain obsolete due to the lint rule.

I fixed the cases where this failed.

Note: this is currently blocked by #18395 as that removes a lot of yoda statements as well. So I only removed the other cases here.

Update: I kept some yoda statements and removed the rule.

Checklist
  • 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
Affected core subsystem(s)

lib, benchmark, doc, test

@BridgeAR BridgeAR added the blocked PRs that are blocked by other issues or PRs. label Feb 13, 2018
@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Feb 13, 2018
Copy link
Member

@TimothyGu TimothyGu left a comment

Choose a reason for hiding this comment

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

Commit message nit: s/yoda/Yoda conditions/. Otherwise LGTM.

@@ -55,7 +55,7 @@ const ms = new MyStream();
const results = [];
ms.on('readable', function() {
let chunk;
while (null !== (chunk = ms.read()))
while (chunk = ms.read())
Copy link
Member

Choose a reason for hiding this comment

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

The !== null test should be kept to make the code more explicit.

Copy link
Member Author

Choose a reason for hiding this comment

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

A couple of our current tests rely on the implicit version. Do you want those also be converted? Because I would argue having a consistent style is best.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, but I'd rather have that in a separate PR.

Copy link
Member

@bnoordhuis bnoordhuis left a comment

Choose a reason for hiding this comment

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

Boo! Yoda style I like.

@@ -937,7 +937,7 @@ the internal buffer is fully drained.
const readable = getReadableStreamSomehow();
readable.on('readable', () => {
let chunk;
while (null !== (chunk = readable.read())) {
while ((chunk = readable.read()) !== null) {
Copy link
Member

Choose a reason for hiding this comment

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

Type-check-on-RHS is less readable than the other way around in expressions like these, IMO.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think this is something very subjective. I personally feel like the version is better to read.

lib/_tls_wrap.js Outdated
@@ -1099,7 +1099,7 @@ exports.connect = function(...args /* [port,] [host,] [options,] [cb] */) {
var cb = args[1];

var defaults = {
rejectUnauthorized: '0' !== process.env.NODE_TLS_REJECT_UNAUTHORIZED,
rejectUnauthorized: process.env.NODE_TLS_REJECT_UNAUTHORIZED !== '0',
Copy link
Member

Choose a reason for hiding this comment

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

Another example where I think it hurts legibility: the line is so long that the type check almost falls off the screen.

Copy link
Member Author

Choose a reason for hiding this comment

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

Here the process.env part is actually something I consider less important to look at. So I have to move further to see that the comparison is with the NODE_TLS_REJECT_UNAUTHORIZED env.

@@ -78,6 +78,6 @@ function child() {
conn.on('drain', common.mustCall(write));

function write() {
while (false !== conn.write(req, 'ascii'));
while (conn.write(req, 'ascii'));
Copy link
Member

Choose a reason for hiding this comment

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

Dropping the strict comparison is a semantic change that I'm not sure is actually correct. Same comment applies to a couple of other places.

Copy link
Member Author

Choose a reason for hiding this comment

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

Write operations should always either return true or false. If that is not the case, it would be an error.

For read operations it returns a string, a buffer or null. The latter when there is nothing to read. Buffer is always truthy and the string should (to my best knowledge) always be non empty. I might be wrong about the empty string case though. But here in our tests we definitely do not have any empty strings.

Copy link
Member

Choose a reason for hiding this comment

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

Write operations should always either return true or false.

In the past we treated (for example) undefined different from false. In fact, I suspect the change to lib/internal/streams/legacy.js is a subtle regression that just happens to fly under the radar of our test suite.

@jasnell
Copy link
Member

jasnell commented Feb 13, 2018

I'm mildly -0 on this. Personally not a fan of Yoda-style, no, but live with it, I can.

Agree with @bnoordhuis, I do, that more readable sometimes it is.

@BridgeAR
Copy link
Member Author

Alright, shall I remove the rule and keep most changes or should I just close the PR?

@BridgeAR BridgeAR force-pushed the remove-yoda branch 3 times, most recently from b036efd to 7bf1793 Compare February 16, 2018 19:32
@BridgeAR BridgeAR removed the blocked PRs that are blocked by other issues or PRs. label Feb 16, 2018
@BridgeAR
Copy link
Member Author

I updated the PR to only remove a couple yoda statements.

PTAL. I am also OK with closing this if that is the preference.

@BridgeAR
Copy link
Member Author

Rebased due to conflicts.

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

@BridgeAR BridgeAR changed the title lib: prohibit yoda lib: remove some yoda statements Feb 17, 2018
@BridgeAR
Copy link
Member Author

How shall we progress here? @jasnell @bnoordhuis

@bnoordhuis
Copy link
Member

When in doubt, do nothing. I'm not 100% sure but I think it's a backwards-incompatible change in behavior.

@gibfahn
Copy link
Member

gibfahn commented Feb 21, 2018

When in doubt, do nothing. I'm not 100% sure but I think it's a backwards-incompatible change in behavior.

Or you could just leave the === false in and have this PR just reverse the yoda expressions. Removing === false should really be a separate PR anyway IMO. FWIW I much prefer being explicit about comparisons.

Reversing the yoda expressions seems fine to me.

@jasnell
Copy link
Member

jasnell commented Feb 22, 2018

I'm -0 on the entire change. Not favorable but won't block and defer to @bnoordhuis' opinion on it.

@BridgeAR
Copy link
Member Author

BridgeAR commented Mar 2, 2018

I further reduced the changeset and think the rest should probably be uncontroversial. PTAL @bnoordhuis @jasnell @gibfahn @TimothyGu

@BridgeAR
Copy link
Member Author

BridgeAR commented Mar 2, 2018

Mini-CI just for the reduced case: https://ci.nodejs.org/job/node-test-commit-light/329/

// CJK Radicals Supplement .. Enclosed CJK Letters and Months
(0x2e80 <= code && code <= 0x3247 && code !== 0x303f) ||
Copy link
Member

Choose a reason for hiding this comment

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

Most of the changes seem good to me but I wonder if this whole block is the one exception? It's basically making it look like 0 <= code <= 100, which is actually kinda nice readability wise.

Copy link
Member Author

Choose a reason for hiding this comment

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

Do you feel strongly about it? Otherwise I would just go ahead and land it as is.

Copy link
Member

Choose a reason for hiding this comment

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

Nope. :)

@apapirovski
Copy link
Member

Landed in f2d9379

@apapirovski apapirovski closed this Mar 4, 2018
apapirovski pushed a commit that referenced this pull request Mar 4, 2018
PR-URL: #18746
Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: James M Snell <[email protected]>
addaleax pushed a commit to addaleax/node that referenced this pull request Mar 5, 2018
PR-URL: nodejs#18746
Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Mar 6, 2018
MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
PR-URL: nodejs#18746
Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@jasnell
Copy link
Member

jasnell commented Aug 17, 2018

Should this be backported to 8.x? If so, a separate backport PR is needed.

@BridgeAR BridgeAR deleted the remove-yoda branch April 1, 2019 23:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lib / src Issues and PRs related to general changes in the lib or src directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants