Refactor UrlbarMuxerUnifiedComplete._canAddResult() to avoid eslint complexity error, or disable eslint complexity
Categories
(Firefox :: Address Bar, task, P3)
Tracking
()
People
(Reporter: adw, Unassigned)
Details
Modifying UrlbarMuxerUnifiedComplete._canAddResult() at this point causes an eslint complexity error, e.g.:
588:16 error Method '_canAddResult' has a complexity of 66. Maximum allowed is 61. complexity (eslint)
IMO I'm not sure what this error is buying us and if it's worth leaving on, but if we don't disable it outright we need to refactor the method to avoid it.
|
||
Comment 1•3 years ago
|
||
The general idea behind the complexity check is that code should usually be split into methods and helpers, the error is supposed to tell "your code is really hard to follow, maybe you can split it out".
That works in most cases where you can easily offload some of the work to an helper, but in some cases there's no way out of complexity without hiding the logic (that has other negative impacts). URIFixup falls in a similar case, because it has a bunch of nested if conditions of various kind for all the cases it manages, and moving them into helpers would hide the logic and actually make it worse.
I think it's ok to bump up complexity for single files when things cannot really be made much better because the task at hand IS complex.
Description
•