MaibornWolff / metric-gardener

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

Rework node types config, renamed "expression" to "node type" #225

Closed ResistantBear closed 5 months ago

ResistantBear commented 5 months ago

Rework node types config, renamed "expression" to "node type"

Closes #145 Closes #103 Closes #54

Description

Refactors the nodeTypesConfig.json. We now no longer have a direct mapping between node type and metric, but a "category" to which a node type belongs that might be relevant for one or multiple metrics. This is especially helpful when defining new metrics or refining the definition of old metrics. For example, there are now distinct categories for "class_definition", "interface_definition", "if", "logical_binary_expression", etc., so that we can redefine e.g. the "classes" or "complexity" metric quite easily. Changed the Queries in src/parser/queries/QueryStatements.ts and all their uses accordingly. By reading all information out of a NodeTypesConfig-object by default, using these queries should be less error prone now, too.

This also introdues a more consistent naming by changing "expression" to "node type" or "type name" where "expression" was used as a synonym to these terms to avoid confusion. The obsolete field type was removed. The file src/parser/helper/Model.ts now includes documentation about the meaning of the fields in the nodeTypesConfig.json.

This does not touch the issue #213 and #222. Intries for node types that touch these issues are either unchanged if there is no mapping or mapped as "interface_definition".

Definition of Done

A PR is only ready for merge once all the following acceptance criteria are fulfilled:

ResistantBear commented 5 months ago

NOTE on activated_for_languages:

This does not change that we cannot specify a mapping between some languages to one category (metric before) and other languages to another category for one syntax node type I discussed in https://github.com/MaibornWolff/metric-gardener/issues/145#issuecomment-1961626890. We currently do not have the issue that we consider a syntax node type for different things in different languages. To support this, we would have to change the field "category" to a list of objects that contain a pair of the category name itself and a (optional) "activated_for_languages" field for this single category. We also would have to take care that we do not add multiple queries for one node type which has multiple categories when building a query that should cover the node types of more than one category, e.g. for the "complexity" metric. As that is not trivial and would negatively impact the performance, I am not sure if we should implement such a feature now for the case that this issue could occur in the future.

I have opened #231 for this potential feature.