Skip to content

Compare strings with strict equality operators - #2582

Closed
thefourtheye wants to merge 4 commits into
nodejs:masterfrom
thefourtheye:compare-strings-with-===
Closed

Compare strings with strict equality operators#2582
thefourtheye wants to merge 4 commits into
nodejs:masterfrom
thefourtheye:compare-strings-with-===

Conversation

@thefourtheye

Copy link
Copy Markdown
Contributor

@thefourtheye
thefourtheyeforce-pushed the compare-strings-with-=== branch from b6399cd to b81547fCompareAugust 27, 2015 18:12
@thefourtheyethefourtheye mentioned this pull request Aug 27, 2015
@seishun

Copy link
Copy Markdown
Contributor

Why? If it doesn't change the behavior, then it's pointless code churn. If it does, then it's a breaking change.

This patch makes sure that the strings are compared with strict
equality operator.
This patch makes sure that the strings are compared with strict
equality operator.
This patch makes sure that the strings are compared with strict
equality operators.
This patch makes sure that the strings are compared with strict
equality operators.
@thefourtheye
thefourtheyeforce-pushed the compare-strings-with-=== branch from b81547f to 301e14fCompareAugust 27, 2015 22:53
@rvagg

Copy link
Copy Markdown
Member

agreed, I'm somewhere between -1 and -0 on this, unless there's a measurable performance gain from doing this then I'm not a fan, sorry for the second negative comment in a row @thefourtheye

@thefourtheye

Copy link
Copy Markdown
ContributorAuthor

@seishun@rvagg No problem :-)

@ronkorving

Copy link
Copy Markdown
Contributor

lgtm, it's one step in the direction of unification (style, if nothing else).

@seishun

Copy link
Copy Markdown
Contributor

I'm not convinced that the majority agrees on the "use === unconditionally everywhere" style. Either way, it seems very unlikely it will ever be enforced throughout the code base anyway, so why apply it partially?

@pmq20

Copy link
Copy Markdown
Contributor

@seishun if it were a breaking change then it would be picked up by the CI. And I think the code churn is not pointless, because == i.e. comparison w/ type conversions could easily introduce bugs and therefore should be avoid.

@ronkorving

Copy link
Copy Markdown
Contributor

Also, he applied it partially because last time he did it not-so-partially and got bad feedback on that.

@rvagg

Copy link
Copy Markdown
Member

@seishun if it were a breaking change then it would be picked up by the CI.

Not true, we don't have 100% coverage and we certainly don't test anything near the number of weird ways people use Node and are expecting it to behave. We have a diverse ecosystem and are always running in to edge-cases and subtle bugs encountered by novel uses.

@pmq20

Copy link
Copy Markdown
Contributor

@rvagg Agreed with you. 👎 on the PR then.

@cjihrig

Copy link
Copy Markdown
Contributor

Also -1. Just make changes like this when you're modifying the code for more meaningful reasons.

@Fishrock123

Copy link
Copy Markdown
Contributor

Yeah... it's hard to agree to change these once they are there. We should just make sure we always land with strict equality, unless explicitly sating why otherwise.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@thefourtheye@seishun@rvagg@ronkorving@pmq20@cjihrig@Fishrock123