smontanari / code-forensics

A toolset for code analysis and report visualisation
383 stars 45 forks source link

Forcing visualisation of developer effort analysis to always use colors #68

Closed ghost closed 3 years ago

ghost commented 3 years ago

Basically if you have in project a lot of different paths with different lengths like for example:

Then you gonna have (most of the time) a lot of gray color in visualization, which reduces usefulness of it. image (Gray like here.)

smontanari commented 3 years ago

Then you gonna have (most of the time) a lot of gray color in visualization, which reduces usefulness of it.

That ultimately depends on what useful means to you.

When analysing file metrics I generally use enclosure diagrams or, like in this case, a tree map diagram. The reason being that we normally structure our files in a hierarchical fashion (a directory tree) and those diagrams make it easier to navigate a large codebase with hundreds or thousands of files. To be clear, the intent is not to render metrics at an aggregate level.

The purpose of this graph, in particular, is to represent the ownership/effort distribution on each file of the codebase, or, if you want, its level of fragmentation. Note that I explicitly stated each file, whereas, if I interpret correctly your demand, you're asking to have a representation at directory or folder, module level.

While in principle I can see the reason behind that, I would argue that its value depends mostly on how you logically structure your codebase. And that can vary depending on many factors that have little to do with what this analysis is about, such as:

While a fragmentation at file level has a well known meaning and there are best practices principles that can help you understand when fragmentation is good or bad in a file, as soon as you move up the directory tree, that meaning becomes completely dependent on your particular choices on how you organised your project files. Moreover, if you have a large number of developers, the chance is that the higher up you go in the directory tree from the file level view, the more cluttered the representation becomes (basically a large mosaic of colours) and the less useful its information, to the point of being completely irrelevant (think for example the root directory of your codebase).

For those reasons, at the moment I'd be a bit reluctant to add this feature, but if many more users were asking for it I would definitely look at what it would imply as far as implementation goes.