-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
test,lib,benchmark: match function names #9113
Conversation
In most cases, named functions match the variable or property to which they are being assigned. That also seems to be the practice in a series of PRs currently being evaluated that name currently-anonymous functions. This change applies that rule to instances in the code base that don't comply with that practice. This will be enforceable with a lint rule once we upgrade to ESLint 3.8.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.
I don't mind the changes. +0 on activating the rule.
@@ -340,10 +340,10 @@ TLSSocket.prototype._wrapHandle = function(wrap) { | |||
res._secureContext = context; | |||
res.reading = handle.reading; | |||
Object.defineProperty(handle, 'reading', { | |||
get: function readingGetter() { | |||
get: function get() { |
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.
What about using get() {
?
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 find that confusing to read. I will probably change my opinion as it becomes more common and I get used to seeing it. If there's a strong preference for it among others, I'll use it. But if left to my own devices, I prefer the explicit key: value
format instead.
return res.reading; | ||
}, | ||
set: function readingSetter(value) { | ||
set: function set(value) { |
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.
Ditto
cb(); | ||
}; | ||
|
||
s.destroy = s.destroySoon = function destroy() { | ||
s.destroy = s.destroySoon = function destroySoon() { |
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.
This one is ambiguous. I would keep destroy
if I had the choice. Did ESLint complain?
Anyway that's fine. It's just a test...
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.
Yeah, ESLint wanted it to be destroySoon
. I agree that destroy
is probably preferable, I'll switch it back.
@@ -166,7 +166,7 @@ const tests = [ | |||
expected: [prompt, replFailedRead, prompt, replDisabled, prompt] | |||
}, | |||
{ // Make sure this is always the last test, since we change os.homedir() | |||
before: function mockHomedirFailure() { | |||
before: function before() { |
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.
Nit: shorthand syntax
@@ -291,7 +291,7 @@ const testCustomCompleterSyncMode = repl.start({ | |||
prompt: '', | |||
input: putIn, | |||
output: putIn, | |||
completer: function completerSyncMode(line) { | |||
completer: function completer(line) { |
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.
Ditto here and on line 326.
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.
LGTM
c133999
to
83c7a88
Compare
One more CI for good measure: https://ci.nodejs.org/job/node-test-commit/5698/ Only red in that one is a build failure on a Raspberry Pi. |
In most cases, named functions match the variable or property to which they are being assigned. That also seems to be the practice in a series of PRs currently being evaluated that name currently-anonymous functions. This change applies that rule to instances in the code base that don't comply with that practice. This will be enforceable with a lint rule once we upgrade to ESLint 3.8.0. PR-URL: nodejs#9113 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Landed in 68ba9aa |
In most cases, named functions match the variable or property to which they are being assigned. That also seems to be the practice in a series of PRs currently being evaluated that name currently-anonymous functions. This change applies that rule to instances in the code base that don't comply with that practice. This will be enforceable with a lint rule once we upgrade to ESLint 3.8.0. PR-URL: #9113 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
In most cases, named functions match the variable or property to which they are being assigned. That also seems to be the practice in a series of PRs currently being evaluated that name currently-anonymous functions. This change applies that rule to instances in the code base that don't comply with that practice. This will be enforceable with a lint rule once we upgrade to ESLint 3.8.0. PR-URL: #9113 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
hey @Trott I've backported this to both v6 and v4 in 7b75cb9 and bd99b2d respectively. The v4 change had some conflicts, specifically in files where you changes touched stuff that didn't exist in the tree. I'm under the impression we would want this work backported, please let me know if we should revert. |
it seems this backport did not happen on v4.x @Trott should we backport? |
I'd prefer that we do, yes. |
@Trott would you be willing to backport to v4.x? |
In most cases, named functions match the variable or property to which they are being assigned. That also seems to be the practice in a series of PRs currently being evaluated that name currently-anonymous functions. This change applies that rule to instances in the code base that don't comply with that practice. This will be enforceable with a lint rule once we upgrade to ESLint 3.8.0. PR-URL: nodejs#9113 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
In most cases, named functions match the variable or property to which they are being assigned. That also seems to be the practice in a series of PRs currently being evaluated that name currently-anonymous functions. This change applies that rule to instances in the code base that don't comply with that practice. This will be enforceable with a lint rule once we upgrade to ESLint 3.8.0. PR-URL: #9113 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
In most cases, named functions match the variable or property to which they are being assigned. That also seems to be the practice in a series of PRs currently being evaluated that name currently-anonymous functions. This change applies that rule to instances in the code base that don't comply with that practice. This will be enforceable with a lint rule once we upgrade to ESLint 3.8.0. PR-URL: #9113 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
In most cases, named functions match the variable or property to which they are being assigned. That also seems to be the practice in a series of PRs currently being evaluated that name currently-anonymous functions. This change applies that rule to instances in the code base that don't comply with that practice. This will be enforceable with a lint rule once we upgrade to ESLint 3.8.0. PR-URL: #9113 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
In most cases, named functions match the variable or property to which they are being assigned. That also seems to be the practice in a series of PRs currently being evaluated that name currently-anonymous functions. This change applies that rule to instances in the code base that don't comply with that practice. This will be enforceable with a lint rule once we upgrade to ESLint 3.8.0. PR-URL: #9113 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Checklist
make -j8 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected core subsystem(s)
test lib benchmark
Description of change
In most cases, named functions match the variable or property to which
they are being assigned. That also seems to be the practice in a series
of PRs currently being evaluated that name currently-anonymous
functions.
This change applies that rule to instances in the code base that don't
comply with that practice.
This will be enforceable with a lint rule once we upgrade to ESLint
3.8.0.