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.
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?