Refactor (src/user/categories.js): reduce nesting in module.exports #163
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.
P1B: Starter Task: Refactoring PR
1. Issue
Link to the associated GitHub issue:
#155
Full path to the refactored file:
src/user/categories.js
What do you think this file does?
(Your answer does not have to be 100% correct; give a reasonable, evidence‑based guess.)
This file contains a function that returns the queried category of a user.
What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)
I've modified the function module.exports, and also added lines outside the function.
Which Qlty‑reported issue did you address?
(Name the rule/metric and include the BEFORE value; e.g., “Cognitive Complexity 18 in render()”.)
Function with many returns (count = 9): exports
Function with high complexity (count = 11): exports
2. Refactoring
How did the specific issue you chose impact the codebase’s maintainability?
Having many returns means that the maintainer will have to individually test if each early return is triggered correctly, which can be a maintenance burden. Having high complexity means that there needs to be at least a dozen key paths to be covered in order for us to be confident about the code, which makes writing tests more frustrating.
What changes did you make to resolve the issue?
I've taken out the functions defined inside the outer function module.exports, and replaced these little functions with triggers.
How do your changes improve maintainability? Did you consider alternatives?
My changes reduced nesting, which helps separating concerns and improves the codebase's testability.
3. Validation
How did you trigger the refactored code path from the UI?
Unfortunately I have not found a way to trigger it from the UI. My file has something to do with the user feature, but I'm sure how to actually trigger that feature, since I can't even log myself in from the UI, and thus can't seem to perform any user related actions. :(
Attach a screenshot of the logs and UI demonstrating the trigger.
(If you refactored a public/src/ file (front-end related file), watch logging via DevTools (Ctrl+Shift+I to open and then navigate to the 'Console' tab). If you refactored a src/ file, watch logging via ./nodebb log. Include the relevant UI view. Temporary logs should be removed before final commit.)
this is the only output I have :(

Attach a screenshot of
qlty smells --no-snippets <full/path/to/file.js>showing fewer reported issues after the changes.