Hi everyone,
I'm trying to reimplement the existing template analyses for the TPTP-based smell detection. From my understanding, the following has been implemented so far:
- RULE1: unreferenced template -> remove (not yet implemented as refactoring) - RULE2: only 1 reference -> inline template - RULE3: multiple references, no formal parameters ("maximise maintainability") -> inline template - RULE4(?): all references to parameterised template use the same actual paramaters -> inline template params - RULE5: all fields defined by formal parameters -> inline template - RULE6: formal params that aren't actually used -> remove parameter (not yet implemented)
Plus the merging rules, but I'm leaving them for now.
Comparing these rules with my smell catalogue, I get to the following:
RULE 1: Special case of smell "Unused Definition" (I'm going to introduce another subcategory "Unused Definition" with specialized rules "Unused ..." and matching quickfixes/refactorings) RULE 2: "Singular Template Reference" RULE 3: I don't get the point here; why is it considered bad if there are multiple references to a non-parameterized templated? In my opinion, inlining the template leads to duplicated inline templates (which is another smell in my catalogue) RULE 4: Special case of "Unneeded Parameter" (maybe I'll find a more suitable name for this) - same as #1 RULE 5: I haven't had this one yet... But good idea! ;) RULE 6: Special case of "Unused Parameter", same as #1
Can anyone help me with RULE 3?
Thanks,
Martin
Martin Bisanz wrote:
Hi everyone,
Hi Martin!
I'm trying to reimplement the existing template analyses for the TPTP-based smell detection. From my understanding, the following has been implemented so far:
- RULE1: unreferenced template -> remove (not yet implemented as
refactoring)
- RULE2: only 1 reference -> inline template
- RULE3: multiple references, no formal parameters ("maximise
maintainability") -> inline template
- RULE4(?): all references to parameterised template use the same actual
paramaters -> inline template params
- RULE5: all fields defined by formal parameters -> inline template
- RULE6: formal params that aren't actually used -> remove parameter
(not yet implemented)
We have revised the rules, and our papers contain the revised version, e.g. the SAM paper: http://www.swe.informatik.uni-goettingen.de/pubs/single_pub/index.php?pub_nr...
However, I just realise that in TRex, the old rules are implemented. :-(
Plus the merging rules, but I'm leaving them for now.
Comparing these rules with my smell catalogue, I get to the following:
RULE 1: Special case of smell "Unused Definition" (I'm going to introduce another subcategory "Unused Definition" with specialized rules "Unused ..." and matching quickfixes/refactorings) RULE 2: "Singular Template Reference" RULE 3: I don't get the point here; why is it considered bad if there are multiple references to a non-parameterized templated? In my opinion, inlining the template leads to duplicated inline templates (which is another smell in my catalogue) RULE 4: Special case of "Unneeded Parameter" (maybe I'll find a more suitable name for this) - same as #1 RULE 5: I haven't had this one yet... But good idea! ;) RULE 6: Special case of "Unused Parameter", same as #1
Can anyone help me with RULE 3?
In the old version, RULE 3 really makes no sense. In the latest version, the number of parameters is not considered anymore and instead of maintainability, readability is considered:
"If a user wants to achieve 'optimal readability' (i.e. maximise the Template Coupling Score), a template definition which is referenced multiple times (Metric value: Number of References to the Template > 1 ) should be inlined and its definition should be removed (Application of Inline Template refactoring)."
This makes IMHO more sense, since inline notation avoids indirections and thus eases readability. (However, as stated later in the paper as well: "using inline templates optimises readability only up to a certain size of template". -- If you like you may consider this fact as well, by allowing to parameterise the smell by the maximum reasonable size of an inline template. Whether the size is specified in terms of characters or number of elements/fields is another question...)
Hence, both for your completing your smell catalogue as well for moving the TRex implementing to the TPTP static analysis framework, I suggest that you refer to the latest version of the rules.
Do not hesitate to ask again, if any questions remain!
Best regards, Helmut
trex-devel@informatik.uni-goettingen.de