addons/FastJet/JetClustering.h's clustering_* structs (kt, antikt,
cambridge, ee_kt, ee_genkt, genkt, valencia, jade) hold _cs and
_recombScheme as private members, but both are only ever written and read
within a single call (_cs inside operator(), _recombScheme inside the
constructor) — never across calls, never accessed externally (checked via
repo-wide grep). They could be plain local variables instead.
_jetAlgorithm may be a related case for clustering_kt/antikt/
cambridge/ee_kt/ee_genkt/genkt (a plain enum, constructor-only use),
but for clustering_valencia/clustering_jade it's an owning raw pointer
passed into fastjet::JetDefinition, and localizing it would need checking
FastJet's actual ownership contract first — not a confirmed case.
This is likely not unique to JetClustering — worth a broader look at the
codebase for the same smell (member state that's really call-scoped) rather
than treating this as a JetClustering-only cleanup.
Not urgent, no functional bug — just unnecessary state on hot per-jet objects.
addons/FastJet/JetClustering.h'sclustering_*structs (kt, antikt,cambridge, ee_kt, ee_genkt, genkt, valencia, jade) hold
_csand_recombSchemeas private members, but both are only ever written and readwithin a single call (
_csinsideoperator(),_recombSchemeinside theconstructor) — never across calls, never accessed externally (checked via
repo-wide grep). They could be plain local variables instead.
_jetAlgorithmmay be a related case forclustering_kt/antikt/cambridge/ee_kt/ee_genkt/genkt(a plain enum, constructor-only use),but for
clustering_valencia/clustering_jadeit's an owning raw pointerpassed into
fastjet::JetDefinition, and localizing it would need checkingFastJet's actual ownership contract first — not a confirmed case.
This is likely not unique to
JetClustering— worth a broader look at thecodebase for the same smell (member state that's really call-scoped) rather
than treating this as a JetClustering-only cleanup.
Not urgent, no functional bug — just unnecessary state on hot per-jet objects.