Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-75156

Cyclomatic Complexity tree map - everything is orange

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • coverage-plugin
    • None

      Not sure if this occurs for everyone, but when I look at the Cyclomatic Complexity tree map view, every box is colored orange. I can see the complexity in the tooltip so I think the value is there, but it does not seem to color the boxes accordingly.

      The other tree maps (Line Coverage and Branch coverage) are colored correctly.

          [JENKINS-75156] Cyclomatic Complexity tree map - everything is orange

          Ulli Hafner added a comment -

          Actually I had no idea what colors to use for which value so I decided to not use any colors yet. Do you have a suggestion, which colors would make sense for which value?

          Ulli Hafner added a comment - Actually I had no idea what colors to use for which value so I decided to not use any colors yet. Do you have a suggestion, which colors would make sense for which value?

          Ulli Hafner added a comment -

          And an additional note: the next major release will include https://github.com/jenkinsci/coverage-plugin/pull/213 that provides a couple of additional metrics. For these we also have the problem that it makes sense to provide colors for "good" and "bad" results. Maybe we should let the users configure these options or compute them on the fly from the results.

          Ulli Hafner added a comment - And an additional note: the next major release will include https://github.com/jenkinsci/coverage-plugin/pull/213 that provides a couple of additional metrics. For these we also have the problem that it makes sense to provide colors for "good" and "bad" results. Maybe we should let the users configure these options or compute them on the fly from the results.

          Sebastian added a comment -

          Ah yes, very interesting question... Thank you for your quick answer!

          I think there are two fundamental ways to do this:

          • Just use fixed values for the color scale
          • Dynamically calculate the colors for the current project, like you mentioned in the previous comment

          If you just want a general rule as a simple baseline that is easy to implement, I would suggest something like:

          • green for <= 10
          • yellow for <= 100
          • orange for <= 1000
          • red for > 1000
            Of course there are some issues with that...

          -------------

          Let's explore the fixed color scale a bit more. I can give you some practical insights from our (enterprise) projects, but of course this is highly specific to the kinds of project you are working on.

          First of all, there is a big difference between the complexity of classes, packages, submodules and projects (we use it for Java/Maven projects, so I'm using that terminology here):

          • Classes have the lowest complexity. Ours are usually in the range of 1-20, but it can go into the low hundreds for some cases.
          • Packages have a higher complexity than classes. Specifically, the package complexity is the sum of all class complexities in that package. Which might imply that using the same color scale for different categories (like packages and classes) could be misleading. Practically, the complexity here can go from <10 for very small packages, into the hundreds, but most of our packages are <100.
          • Submodules, again, have a higher complexity than packages - same principles apply, it is the sum of all the packages. Most of our submodules are around 100 - 500, but there are also smaller (and bigger) ones.
          • Projects have the highest complexity, the sum of all the submodules. Smaller ones might be around 1000, but here the number can go up to over 9000.

          I'm not sure how useful these values are in a general scope, but I hope this let's you put the numbers into perspective.
          So it might make sense to use different color scales for classes, packages, submodules and projects. On the other hand, it might also be confusing for the user if the same colors can mean different values, so I cannot give a specific recommendation. Maybe it does make more sense to use the same color scale for everything...

          --------------

          On to the "dynamic" coloring option. 
          I suppose the practical choice here would be to just calculate the min and max values, and map that onto the color scale.
          Again, this would mean that classes would be colored way more leniently than projects, for example. And the complexity of the project might be so high that all the classes just end up in a similar shade of green. Two ideas to deal with this come to mind:

          • Use a log scale (e.g. log2 or log10, or the natural logarithm) to calculate the color values - then the differences between classes should be more obvious. Another advantage of this method is that all categories (classes, packages, submodules, projects) can use the same color scale, so it is easier to put them into relation to each other - i.e. more red always means more complex.
          • Calculate the min and max values for each category separately. Of course this, again, might be confusing for the users (because the colors mean different things between the categories). Also, you won't have anything to compare the project to, because there is only one project - and there are probably just a few submodules as well.

          --------------

          Personally, I would probably try out the completely fixed color scale option first - this should give us a simple and unproblematic solution. 

          Then, maybe make the thresholds configurable.

          If it becomes apparent that this color scale does not make much sense, I would probably try to put the values on a log scale. You can also combine the log scale with the "fixed color scale" approach - just define a fixed color scale for the logarithmized values. That should make the color differences more pronounced for values that are close to each other. This approach would also make it easier to compare different projects (compared to dynamic calculations of min/max values), because then each project would also use the same color scale.

          Unless issues with these approaches become apparent, I would probably not bother with trying to create a dynamic scale based on min/max/average/median/whatever calculations at all, mostly because it would make it so that you cannot compare the colors of different projects to each other. But that's just my intuition.

          Sebastian added a comment - Ah yes, very interesting question... Thank you for your quick answer! I think there are two fundamental ways to do this: Just use fixed values for the color scale Dynamically calculate the colors for the current project, like you mentioned in the previous comment If you just want a general rule as a simple baseline that is easy to implement, I would suggest something like: green for <= 10 yellow for <= 100 orange for <= 1000 red for > 1000 Of course there are some issues with that... ------------- Let's explore the fixed color scale a bit more. I can give you some practical insights from our (enterprise) projects, but of course this is highly specific to the kinds of project you are working on. First of all, there is a big difference between the complexity of classes, packages, submodules and projects (we use it for Java/Maven projects, so I'm using that terminology here): Classes have the lowest complexity. Ours are usually in the range of 1-20, but it can go into the low hundreds for some cases. Packages have a higher complexity than classes. Specifically, the package complexity is the sum of all class complexities in that package. Which might imply that using the same color scale for different categories (like packages and classes) could be misleading. Practically, the complexity here can go from <10 for very small packages, into the hundreds, but most of our packages are <100. Submodules, again, have a higher complexity than packages - same principles apply, it is the sum of all the packages. Most of our submodules are around 100 - 500, but there are also smaller (and bigger) ones. Projects have the highest complexity, the sum of all the submodules. Smaller ones might be around 1000, but here the number can go up to over 9000. I'm not sure how useful these values are in a general scope, but I hope this let's you put the numbers into perspective. So it might make sense to use different color scales for classes, packages, submodules and projects. On the other hand, it might also be confusing for the user if the same colors can mean different values, so I cannot give a specific recommendation. Maybe it does make more sense to use the same color scale for everything... -------------- On to the "dynamic" coloring option.  I suppose the practical choice here would be to just calculate the min and max values, and map that onto the color scale. Again, this would mean that classes would be colored way more leniently than projects, for example. And the complexity of the project might be so high that all the classes just end up in a similar shade of green. Two ideas to deal with this come to mind: Use a log scale (e.g. log2 or log10, or the natural logarithm) to calculate the color values - then the differences between classes should be more obvious. Another advantage of this method is that all categories (classes, packages, submodules, projects) can use the same color scale, so it is easier to put them into relation to each other - i.e. more red always means more complex. Calculate the min and max values for each category separately. Of course this, again, might be confusing for the users (because the colors mean different things between the categories). Also, you won't have anything to compare the project to, because there is only one project - and there are probably just a few submodules as well. -------------- Personally, I would probably try out the completely fixed color scale option first - this should give us a simple and unproblematic solution.  Then, maybe make the thresholds configurable. If it becomes apparent that this color scale does not make much sense, I would probably try to put the values on a log scale. You can also combine the log scale with the "fixed color scale" approach - just define a fixed color scale for the logarithmized values. That should make the color differences more pronounced for values that are close to each other. This approach would also make it easier to compare different projects (compared to dynamic calculations of min/max values), because then each project would also use the same color scale. Unless issues with these approaches become apparent, I would probably not bother with trying to create a dynamic scale based on min/max/average/median/whatever calculations at all, mostly because it would make it so that you cannot compare the colors of different projects to each other. But that's just my intuition.

            drulli Ulli Hafner
            konfuzian Sebastian
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: