-
Notifications
You must be signed in to change notification settings - Fork 28
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
Remove unused escape characters and variables #59
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,7 @@ | ||
module.exports = function (opts) { | ||
return { | ||
name: 'noauth', | ||
create: function (_opts) { | ||
create: function () { | ||
return function (stream, cb) { | ||
cb(null, { | ||
remote: opts.keys.publicKey, | ||
|
@@ -12,7 +12,7 @@ module.exports = function (opts) { | |
}) | ||
} | ||
}, | ||
parse: function (str) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would actually prefix this one with underscore because it might be useful. It's more useful in the implementation than it is in tests. I.e. I agree with removing unused variables in tests. |
||
parse: function () { | ||
return {} | ||
}, | ||
stringify: function () { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,7 +8,7 @@ module.exports = function (opts) { | |
return { | ||
name: 'onion', | ||
scope: function() { return 'public' }, | ||
parse: function (s) { return null } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would keep this one, but use underscore |
||
parse: function () { return null } | ||
} | ||
} | ||
|
||
|
@@ -63,7 +63,7 @@ module.exports = function (opts) { | |
} | ||
} | ||
|
||
tryConnect(connectOpts(daemonProxyOpts), function(err) { | ||
tryConnect(connectOpts(daemonProxyOpts), function() { | ||
tryConnect(connectOpts(browserProxyOpts), function(err) { | ||
cb(err) | ||
}) | ||
|
@@ -87,7 +87,7 @@ module.exports = function (opts) { | |
port: port | ||
} | ||
}, | ||
stringify: function (scope) { | ||
stringify: function () { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would keep this one, but use underscore |
||
return 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.
The use of prefixed underscore is usually (e.g. often in TypeScript) for variables and arguments that you know you are not using, but would like to still explicitly name. For instance, for internal documentation, to indicate that this argument is provided and could be used, but is not used at the moment. So in this specific case I would recommend keeping it.
Long story short:
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'm familiar with the convention, but I'm using eslint:recommended specifically to avoid any controversy about linter configuration. I think the right solution would be to write documentation for the plugin API rather than having to keep hinting at it with unused variables sprinkled around our code.
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 fine for personal code, but when working with others I think it's better to have a consistent rule rather than 'the tyranny of whoever touched it last'. I want to make two distinct points:
I want to make sure that you have an opportunity to respond, so I won't close my pull request now, but if this patch is unacceptable I think we should probably just close the pull request and discuss some other time.
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.
Well, ok, I won't make this a blocker to merge