Opened 10 years ago
Closed 9 years ago
#8888 closed feature (wontfix)
Add code metric checks to .jshintrc
Reported by: | Jörn Zaefferer | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | git |
Component: | [meta] ui.dev | Version: | 1.9.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
JSHint supports a few code metric checks that we could adapt. Elijah has details here: http://www.elijahmanor.com/2012/09/control-complexity-of-your-javascript.html
Basically we'd add a variant of these:
"maxparams": 5, "maxdepth": 5, "maxstatements": 25, "maxcomplexity": 10,
If we increase maxcomplexity to 13, its mostly datepicker and sortable left as offenders. We have to figure out which ones to address before adding these, and where to increase the numbers to accept what's there.
Change History (5)
comment:1 Changed 10 years ago by
Milestone: | 1.10.0 → git |
---|---|
Status: | new → open |
comment:2 Changed 10 years ago by
comment:3 Changed 10 years ago by
We'll stick with the numbers in the code block from the description. I made some progress on this today. For methods that use switch statements (like keydown
event handlers) or independent if statements (like _setOption()
) in a logical, we just increase the allowed cyclomatic complexity for those specific functions.
Still need to clean up the interactions and datepicker, plus one failure in the scale effect (too many statements).
comment:4 Changed 10 years ago by
I'm not a fan of maxstatements, and I'm not a fan of creating inline concessions for switch statements and independent ifs, as that opens a whole can of worms for inline linting comments. If the cyclomatic complexity is too high due to a switch statement, it's gotta be refactored.
That's just my thoughts.
comment:5 Changed 9 years ago by
Resolution: | → wontfix |
---|---|
Status: | open → closed |
Not doing this for now. May revisit someday in the future.
The specific metrics need to be decided in conjunction with core.