Conditions | 12 |
Total Lines | 58 |
Code Lines | 32 |
Lines | 58 |
Ratio | 100 % |
Changes | 0 |
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
Complex classes like glances.exports.glances_influxdb.Export._normalize() often do a lot of different things. To break such a class down, we need to identify a cohesive component within that class. A common approach to find such a component is to look for fields/methods that share the same prefixes, or suffixes.
Once you have determined the fields that belong together, you can apply the Extract Class refactoring. If the component makes sense as a sub-class, Extract Subclass is also a candidate, and is often faster.
1 | # |
||
88 | def export(self, name, columns, points): |
||
89 | """Write the points to the InfluxDB server.""" |
||
90 | # Manage prefix |
||
91 | if self.prefix is not None: |
||
92 | name = self.prefix + "." + name |
||
93 | # Write input to the InfluxDB database |
||
94 | if not points: |
||
95 | logger.debug(f"Cannot export empty {name} stats to InfluxDB") |
||
96 | else: |
||
97 | try: |
||
98 | self.client.write_points( |
||
99 | self.normalize_for_influxdb(name, columns, points), |
||
100 | time_precision="s", |
||
101 | ) |
||
102 | except Exception as e: |
||
103 | # Log level set to warning instead of error (see: issue #1561) |
||
104 | logger.warning(f"Cannot export {name} stats to InfluxDB ({e})") |
||
105 | else: |
||
106 | logger.debug(f"Export {name} stats to InfluxDB") |
||
107 |