search

MaibornWolff / metric-gardener

BSD 3-Clause "New" or "Revised" License
6 stars 0 forks source link

Discuss how to handle different categories of files (source code, markup and unsupported files) #179

Closed ResistantBear closed 6 months ago

ResistantBear commented 6 months ago

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:

  1. Split the current list nodes of all supported files into lists like source_files and markup_files (plus adding a list for unsupported_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 the source_files list has the same list of metrics.
  2. Keep the current list 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.
  3. Like 2., but change the currently unused type value within the objects of nodes to something that makes it clear that it represents a source code, markup or unsupported file.
  4. Similar to 2., but the objects within the list always include all metrics that metric-gardener could calculate. Not applicable metrics are ensured to be set to 0.

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.

Nereboss commented 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.

ResistantBear commented 6 months ago

We go with option 3