-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Conversation
There was a problem hiding this 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()) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
doc/api/stream.md
Outdated
@@ -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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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', |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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')); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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. |
Alright, shall I remove the rule and keep most changes or should I just close the PR? |
b036efd
to
7bf1793
Compare
I updated the PR to only remove a couple yoda statements. PTAL. I am also OK with closing this if that is the preference. |
7bf1793
to
f4e55c0
Compare
Rebased due to conflicts. |
How shall we progress here? @jasnell @bnoordhuis |
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 Reversing the yoda expressions seems fine to me. |
I'm -0 on the entire change. Not favorable but won't block and defer to @bnoordhuis' opinion on it. |
I further reduced the changeset and think the rest should probably be uncontroversial. PTAL @bnoordhuis @jasnell @gibfahn @TimothyGu |
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) || |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. :)
Landed in f2d9379 |
PR-URL: #18746 Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: nodejs#18746 Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: nodejs#18746 Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]>
Should this be backported to 8.x? If so, a separate backport PR is needed. |
This enables the yoda eslint rule and prohibits statements likefalse === 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), orvcbuild test
(Windows) passesAffected core subsystem(s)
lib, benchmark, doc, test