Fix documentation issues - #230
Conversation
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
| import java.util.ArrayList; | ||
| import java.util.List; | ||
| import java.util.Set; | ||
| import java.util.stream.Collectors; |
There was a problem hiding this comment.
✅ Getting better: Overall Code Complexity
The mean cyclomatic complexity decreases from 9.22 to 7.77, threshold = 4
| } | ||
| return operators; |
There was a problem hiding this comment.
✅ Getting better: Bumpy Road Ahead
processDocXMLOperators decreases from 5 to 2 logical blocks with deeply nested code, threshold is one single block per function
| } | ||
| return operators; |
There was a problem hiding this comment.
✅ Getting better: Complex Method
processDocXMLOperators decreases in cyclomatic complexity from 24 to 12, threshold = 9
| private void addConcepts(org.w3c.dom.Element operator, ExecutableElement e) { | ||
| org.w3c.dom.Element conceptsElt; |
There was a problem hiding this comment.
❌ New issue: Code Duplication
The module contains 5 functions with similar structure: addCategories,addConcepts,processDocXMLStatementsInsideKind,processDocXMLStatementsInsideSymbol and 1 more functions
| } | ||
| return operators; |
There was a problem hiding this comment.
✅ No longer an issue: Deep, Nested Complexity
processDocXMLOperators is no longer above the threshold for nested complexity depth
|
I think that's good enough for the codescene report, the only thing we could do to help with code "duplication" is to refactor completely the module to have getConcepts, getCategories and getDocElt to merge into one method. I don't think it's worth the hassle and it would probably lead to a monster of a method anyway |
|
I think that's good enough for the codescene report, the only thing we could do to help with code "duplication" is to refactor completely the module to have getConcepts, getCategories and getDocElt to merge into one method. I don't think it's worth the hassle and it would probably lead to a monster of a method anyway. because that test was already done a few lines above, so my guess was that it was some forgotten code with no practical impact, but maybe I overlooked it and it makes sense ? |
|
Indeed you can remove one if :-) |
) Operators in ImageOperators and Displays declare no explicit category, so they fell back to their Java class name and appeared under the non-uniform titles "ImageOperators" / "Displays" instead of proper "... operators" titles. Add canonical IMAGE ("Image operators") and DISPLAY ("Display operators") categories and map those two classes to them, so their titles are uniform with the rest of the operator categories. Fixes gama-platform.github.io#230
2 participants
Fixes attempt for issues #222, #219, #220, #214 from gama-platform.github.io repository