Page MenuHomePhabricator

[lib] Remove extraneous ternary from `pluralize` function in `text-utils`
ClosedPublic

Authored by abosh on Jun 21 2022, 12:21 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Dec 16, 11:55 PM
Unknown Object (File)
Mon, Dec 16, 6:12 PM
Unknown Object (File)
Tue, Nov 26, 5:48 PM
Unknown Object (File)
Nov 23 2024, 2:50 AM
Unknown Object (File)
Oct 31 2024, 12:07 PM
Unknown Object (File)
Oct 31 2024, 12:07 PM
Unknown Object (File)
Oct 31 2024, 12:07 PM
Unknown Object (File)
Oct 31 2024, 12:05 PM
Subscribers

Details

Summary

The ternary condition in the pluralize function in text-utils is unnecessary since its "else" condition is unreachable. Because of the order of the cases in pluralize, if the maxNumberOfNouns === 1 conditional is entered, nouns.length will always be greater than 1, since the prior two conditionals check if nouns.length equals 0 or 1. Therefore, it can be removed.

Test Plan

The length property of an array can never be a negative number, and only a positive integer greater than or equal to 0. So nouns.length is guaranteed to be greater than 1 if the maxNumberOfNouns === 1 conditional is reached.

In addition, after @palys-swm's review, I checked all instances of lib/text/text-utils (specifically calls to pluralize and pluralizeAndTrim) in the codebase to make sure this change did not break anything:

  • Test to make sure InlineSidebars are displayed correctly:

image.png (184×928 px, 22 KB)
image.png (118×372 px, 11 KB)

Also, to be doubly sure, this is the usage of pluralizeAndTrim in InlineSidebarText, which calls pluralizeAndTrim with maxNumberOfNouns = 25. The code that was changed in this diff was in the conditional, which is only executed if maxNumberOfNouns === 1, so this change will not affect InlineSidebar.
image.png (360×1 px, 104 KB)

  • Test to make sure JoinThreadMessageSpec works correctly:

This is the only call to pluralize/usage of text-utils in JoinThreadMessageSpec:

image.png (112×1 px, 35 KB)

Because this call to pluralize does not define the maxNumberOfNouns parameter, the code that was changed will never be executed since maxNumberOfNouns is by default initialized to 3 (see line 5 in this diff), not 1. The code that was changed in this diff was in the conditional, which is only executed if maxNumberOfNouns === 1, so this change will not affect JoinThreadMessageSpec.

  • Test to make sure thread-utils works correctly:

This is the only call to pluralize in thread-utils:

image.png (496×1 px, 130 KB)

Once again, because this call to pluralize does not define the maxNumberOfNouns parameter, the code that was changed will never be executed since maxNumberOfNouns is by default initialized to 3, not 1. Therefore, this change will not affect thread-utils (or anything that uses it).

  • Test to make sure LeaveThreadMessageSpec works correctly:

Same logic as described above for JoinThreadMessageSpec:

image.png (134×1 px, 38 KB)

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

lib/utils/text-utils.js
20–21 ↗(On Diff #13637)

This change is to match the later style in trimText of removing the else branch if the if branch contains a return statement. I think this is good style (re: no-else-after-return), although I know @ashoat prefers to have else-ifs for chains of if blocks that have returns. But since this is just an if-else, there doesn't need to be an else block.

tomek requested changes to this revision.Jun 22 2022, 8:10 AM

This change definitely needs a test plan. For example, you can simply check if inline sidebars are displayed correctly. Also, this is a great function to have some tests.

This revision now requires changes to proceed.Jun 22 2022, 8:10 AM

You're right, I should have been more thoughtful. Just updated the Test Plan.

Thanks for the detailed test plan!

This revision is now accepted and ready to land.Jun 22 2022, 9:00 AM

I know @ashoat prefers to have else-ifs for chains of if blocks that have returns. But since this is just an if-else, there doesn't need to be an else block.

This looks good to me!