Closed ResistantBear closed 6 months ago
I dont think we should split the nodes. That seems like too big of a change for me and it does not guarantee that all files within one category support all metrics. I would keep all nodes on one list and either leave out all metrics that are not supported or (in my opinion the better option) set all unsupported metrics to -1. As we do not have any metrics that become negative and -1 is often used as a "not found" value.
We go with option 3
As already discussed, we should ensure that new metrics that only apply for markup files are only calculated for markup files and not for source code files (and vice versa, as a lot of metrics for source code do not apply for markup languages). This is necessary to ensure both the correctness of the output and to avoid unessesary computation. To apply this to our JSON output, we have come up with the following options:
nodes
of all supported files into lists likesource_files
andmarkup_files
(plus adding a list forunsupported_files
with only lines of code as a metric, see #142). The objects within these lists then include the metrics supported for the files of the respective category. This means that every object in thesource_files
list has the same list of metrics.nodes
(maybe renamed to "files") and put the results for any kind of encountered file in it. The objects withthin this list leave out all metrics that are not supported by the individual file.type
value within the objects ofnodes
to something that makes it clear that it represents a source code, markup or unsupported file.Another point for 1. to 3. is how to handle deviations within one category, as there might be programming languages that e.g. do not have functions. The current behaviour would be to (more or less) calculate the metric nevertheless and set the functions metric to 0. With 2. and 3., we could also decide to leave out the metric.