-
Notifications
You must be signed in to change notification settings - Fork 30k
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
path: replace "magic" numbers by readable constants #18654
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.
Hm, the name symbols
is actually misleading out of my perspective. For me a symbol would mean it is e.g. Symbol('foo')
. I think it should be constants
instead.
Besides that I am not sure if V8 inlines these entries properly or not. Would you be so kind and run a benchmark? :-)
lib/internal/symbols.js
Outdated
// non-alphabetic symbols | ||
DOT: 46, /*.*/ | ||
SLASH: 47, /*/*/ | ||
VERTICAL_BAR: 92, /*|*/ |
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.
92 should be /*\*/
(backslash).
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.
@richardlau yeah, my bad, it's "backslash" of course
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 like the idea here but I agree with @BridgeAR that the file naming is less than ideal. I think the symbols
(after renaming) should be destructured into constants, so that they can be used without symbols.
which needs to perform a lookup. That also means that the naming of the properties should be more sensible... perhaps "CHAR_UPPERCASE_A" (& "CHAR_LOWERCASE_A"), "CHAR_FORWARD_SLASH", "CHAR_BACKWARD_SLASH", etc.
187f30d
to
10de2d4
Compare
@apapirovski @richardlau @BridgeAR Hi! I renamed module "symbols" into "constants" and constants. Also I ran benchmarks and this is a result:
Looks like fluctuations. What do you think? |
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. I like the approach. Just two small suggestions.
lib/internal/constants.js
Outdated
CHAR_UPPERCASE_Z: 90, /*Z*/ | ||
CHAR_LOWERCASE_Z: 122, /*z*/ | ||
|
||
// non-alphabetic symbols |
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.
Non blocking nit: it would be great to uppercase and punctuate comments :-)
lib/path.js
Outdated
if (code === 47/*/*/ || code === 92/*\*/) | ||
const isPathSeparator = | ||
code === CHAR_FORWARD_SLASH || code === CHAR_BACKWARD_SLASH; | ||
if (isPathSeparator) |
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.
Non blocking nit: I would just use a if statement spread over two lines.
10de2d4
to
d01f77b
Compare
d01f77b
to
0889294
Compare
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. I think this makes the code a lot clearer.
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 -0 on this change, imo current setup looks fine
|
||
module.exports = { | ||
// Alphabet chars. | ||
CHAR_UPPERCASE_A: 65, /*A*/ |
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: for readability it might help to change these comments to //
style
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.
@devdazed what about comment like this: // /
? Now it's /*/*/
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 is probably more subjective than i realized, i'll leave it up to your judgement 👍
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 would at least put spaces and quotes around them like /* 'A' */
which also makes the original suggestion less crazy since it would be // '/'
which is at least a little clearer.
The "changes requested" makes the -0 effectively a -1 and the "nit" non optional... 😕 |
my intention was more like "i think its fine the way it is but if it does get changed perhaps these comments could be cleaned up", please don't consider the above blocking this pr, sorry for the confusion 😄 |
That's fine but the "changes requested" means this won't be able to land as is. FWIW, I considered making the same comment re: the comment style but arguably |
@BridgeAR @apapirovski @richardlau Can I fix it somehow? |
@daynin our tests currently have a couple of flakes and therefore the CI some times fail even though the code change is completely fine. These failures are independent and you do not have to worry about them :-) |
The Windows failures seem related but I struggle to find where exactly this change breaks them. |
@@ -0,0 +1,16 @@ | |||
'use strict'; | |||
|
|||
module.exports = { |
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.
Does it make sense to group the constants a little more? This module looks like it's a place where more constants could be added so maybe it makes sense to create to group them in a character
or char
object?
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.
In general I agree but I personally think we should do that when it is time to do so instead of adding something before we need it.
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.
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.
If we're planning to add more in the future, it makes the scope of any future change smaller and less risky. I don't have a strong feeling either way, mostly just an observation since the new file is simply internal/constants.js
and in my experience those sorts of files get out of control before you know it.
lib/path.js
Outdated
} else if ((code >= 65/*A*/ && code <= 90/*Z*/) || | ||
(code >= 97/*a*/ && code <= 122/*z*/)) { | ||
} else if ((code >= CHAR_UPPERCASE_A && code <= CHAR_UPPERCASE_Z) || | ||
(code >= CHAR_LOWERCASE_A && code <= CHAR_UPPERCASE_Z)) { |
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.
Typo here. Second line of the else if
statement, second variable is supposed to be CHAR_LOWERCASE_Z
.
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.
@apapirovski fixed
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.
Oh, I did not see that you already commented @apapirovski :D
0889294
to
e551ccc
Compare
lib/path.js
Outdated
} else if ((code >= 65/*A*/ && code <= 90/*Z*/) || | ||
(code >= 97/*a*/ && code <= 122/*z*/)) { | ||
} else if ((code >= CHAR_UPPERCASE_A && code <= CHAR_UPPERCASE_Z) || | ||
(code >= CHAR_LOWERCASE_A && code <= CHAR_UPPERCASE_Z)) { |
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 second case is faulty.
@apapirovski @BridgeAR Should i fix it or just wait? |
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 like this, my only though would be if we want this constants file to be more namespaced or not.
PR-URL: nodejs#18654 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Anatoli Papirovski <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Kyle Farnung <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
@BridgeAR Just to understand the philosophy of the coding style, why do we compare characters using Looking forward into the future, it would mean that potentially there might be a mapping of all ASCII characters to its equivalent decimal values. |
It's still about 3x as fast to use |
And I've gone ahead and answered my question — it's still slower by about 10-20%.
That's somewhat unlikely given that we don't have that many places where this is an issue. |
https://jsperf.com/charcodeat-vs-string-comparison/11 I'm not an expert in JavaScript performance testing, but it seems here that character equality using bracket |
@jiaherrt Not really. It accesses the same character in a loop. Wouldn't surprise me if V8 can inline that access. I tested it on the function modified in this PR using the benchmarks within the benchmark folder which yielded roughly 10-20% worse results, depending on the exact test case. |
@daynin, are you planning on refactoring the other constants anytime soon? Would it be okay if I start refactoring the others? |
@jiaherrt hi!
Yeah, I wanna fix it in other places too. But if you want you can do the same |
Alright. I'll start with |
@jiaherrt Just a note to say that if you're working on
Could just use |
Alright. I'll keep that in mind when I refactor. Thanks for the heads-up. |
Looking it over again, I don't know how other collaborators will feel about refactoring that specific file. You could open an issue first to make sure there's support for it? |
PR-URL: #18654 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Anatoli Papirovski <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Kyle Farnung <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
PR-URL: #18654 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Anatoli Papirovski <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Kyle Farnung <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
PR-URL: #18654 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Anatoli Papirovski <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Kyle Farnung <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
PR-URL: nodejs#18654 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Anatoli Papirovski <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Kyle Farnung <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
I replaced "magic" numbers from "path" module by well readable constants. I want to replace all "magic" numbers in whole project by constants like these, but I decided to start from only one module "path"