You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The different variations are stored in a vector in a predetermined order, but that order isn't advertised anywhere, and is accessed with unexplained "magic numbers." There should either be an enum explaining the indices, or the vector should be an unordered_map. There should also be a check in the getXIndex function that the entry exists.
Another small point is that the official CMSSW naming convention recommends not using "get" in the name of getting funcitons. So getDynNames, getScaleIndex --> dynNames, scaleIndex.
The different variations are stored in a vector in a predetermined order, but that order isn't advertised anywhere, and is accessed with unexplained "magic numbers." There should either be an enum explaining the indices, or the vector should be an unordered_map. There should also be a check in the getXIndex function that the entry exists.
Talking about these lines: https://github.com/kdlong/cmssw/blob/ImprovedParsing/SimDataFormats/GeneratorProducts/interface/ScaleWeightGroupInfo.h#L46-L64
There are also some unexplained "magic numbers" here: https://github.com/kdlong/cmssw/blob/ImprovedParsing/SimDataFormats/GeneratorProducts/src/ScaleWeightGroupInfo.cc#L42
Another small point is that the official CMSSW naming convention recommends not using "get" in the name of getting funcitons. So getDynNames, getScaleIndex --> dynNames, scaleIndex.
https://cms-sw.github.io/cms_coding_rules.html#2----naming-rules-1
@dteague are you able to implement this?
The text was updated successfully, but these errors were encountered: