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

prefer String#includes to comparing indexes #3844

Closed
wants to merge 1 commit into from

Conversation

tejasmanohar
Copy link

readability boost. tests still pass. no downsides afaik

@tejasmanohar tejasmanohar changed the title prefer String#includes to static String#indexOf comparisons prefer String#includes to String#indexOf comparisons Nov 16, 2015
@tejasmanohar tejasmanohar changed the title prefer String#includes to String#indexOf comparisons prefer String#includes to comparing indexes Nov 16, 2015
@tejasmanohar tejasmanohar force-pushed the use_string_contains branch 2 times, most recently from 1470636 to ed127e5 Compare November 16, 2015 09:41
@@ -250,7 +250,7 @@ Module._resolveLookupPaths = function(request, parent) {

// make sure require('./path') and require('path') get distinct ids, even
// when called from the toplevel js file
if (parentIdPath === '.' && id.indexOf('/') === -1) {
if (parentIdPath === '.' && id.includes('/')) {
Copy link
Member

Choose a reason for hiding this comment

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

is this correct??
previous code indicated id.indexOf('/') === -1, I think !id.includes('/') is correct.

if (parentIdPath === '.' && !id.includes('/')) {
}

But I don't understand why test are passed...

Copy link
Author

Choose a reason for hiding this comment

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

ahh what, no this is wrong! will be back to computer momentarily and fix this and run thru rest

Copy link
Contributor

Choose a reason for hiding this comment

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

@tejasmanohar It looks like this could use a test. It is not absolutely necessary from this PR's point of view, but a test which covers this case would be awesome :-)

Copy link
Author

Choose a reason for hiding this comment

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

resolved thru soft reset and override in push -f... so this diff is now outdated. thx for spotting, @yosuke-furukawa

Copy link
Author

Choose a reason for hiding this comment

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

i agree, @thefourtheye - will take a look and maybe send in another PR :) - not relevant to this one, but in another one- would make more sense yeah.

@thefourtheye thefourtheye added the lib / src Issues and PRs related to general changes in the lib or src directory. label Nov 16, 2015
@yosuke-furukawa
Copy link
Member

I compared includes and indexOf in jsperf. But indexOf is little bit faster than includes.
http://jsperf.com/includes-vs-indexof/2

@tejasmanohar
Copy link
Author

@yosuke-furukawa barely... not sure it's to the point it matters. That said, > -1 / using indexOf is really common so readable by convention anyways :P

@tejasmanohar
Copy link
Author

Updated. The mismatch issue @yosuke-furukawa mentioned no longer exists. It's only performance that's really debatable at this point afaik... readability benefits are pretty clear ;)

@yosuke-furukawa
Copy link
Member

I am sorry, -1 to this PR.

We have some discussion about readability and performance.
As a result, I mind that we have decided performance is more important than readability.
Of course we need to be better to improve readability to suppress bugs, but IMHO, I feel indexOf !== -1 is not so difficult to read.

@evanlucas
Copy link
Contributor

Thanks for the contribution! I have to agree with @yosuke-furukawa. Unless the performance is at least on par with indexOf, I'm -1 as well

@cjihrig
Copy link
Contributor

cjihrig commented Nov 16, 2015

I think the exact discussion of includes() vs. indexOf() has come up before, and we decided that we wouldn't make the change until the performance was adequate. So, I'm -1 as well.

@jasnell
Copy link
Member

jasnell commented Nov 16, 2015

-1 as well. Definitely appreciate the PR but I'm going to close this given the -1's

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.

6 participants