-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Reduce unnecessary condition determination #4197
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
These changes don't make sense to me.
The function signature shows three different parameters (
ifstr1
,ifstr2
,ifstr3
). If this design was chosen intentionally, then your changes are incorrect.Uh oh!
There was an error while loading. Please reload this page.
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.
@juergba
Thank you very much for reviewing my PR.
With your advice, I reviewed the intentions of the original code writer.
I checked out the history of
helpers.js
.According to Refactor Reporter tests #3272,
helpers.js
was created in the process of refactoring the duplicated code of the test files intest/reporters
.createRunnerFunction
inhelpers.js
is composed entirely ofswitch-case
statements. Depending on whatrunStr
is, the functions to return are defined one by one. This means thatcreateRunnerFunction
is not meant to be reused, just a collection of similarly structured code for refactoring purposes.So I could conclude: the code I modified will not affect what I didn't expect, and it will work independently of each other. This is supported by the fact that when I ran the test with my code, it all passed.
Nevertheless, as you said, I thought more about the possibilities of the intended design.
Compare the two cases below.
(1) If only using
if
separately in succession(2) If using
if else
Since the
event
does not change during this process, in most cases the codes mentioned above will do the same. It works differently only in one case thatifStr1
andifStr2
are same. WhenifStr1
andifStr2
are same to each other,(1)
executes bothcallback(a);
andcallback(b);
while(2)
only executescallback(a);
.If the original author had intentionally designed something like this, it was probably because there were some situations where both
callback(a);
andcallback(b);
have to run, that is,ifStr1
andifStr2
are equal.I've looked through every case using the
createMockRunner
intest/reporters/*.spec.js
to see if those situations really exist.In most cases, the logic inside the
case
statement was just forevent === ifStr1
.Only five
case
s in thehelpers.js
deal withevent === ifStr2
, so I've looked at those five:When I checked the use cases of
createMockRunner
for these five mentioned above, I found 17 times as below.case 'start test'
case 'suite suite end'
case 'pass end'
case 'test end fail'
case 'fail end pass'
But as you can see, the case that
ifStr1
is the same asifStr2
never appeared.Therefore, it can be assumed that the original author did not expect anything by writing
if
separately. That's why I think the original author didn't design it intentionally.Now, you know that changing
if, if
toif, if else
is no problem.Once
event === ifStr1
is satisfied, you don't have to check anymore forevent === ifStr2
orevent === ifStr3
. By modifying it toif else
, you can expect some efficiency.if
, then at least the thirdif
statement will be skipped.