| Conditions | 12 |
| Total Lines | 56 |
| Code Lines | 38 |
| Lines | 0 |
| Ratio | 0 % |
| 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 build.cogs.spotcog.SpotCog.count_spot() 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 | """ |
||
| 47 | await ctx.delete() |
||
| 48 | await ctx.channel.send(f"{role.mention}") |
||
| 49 | await DatabaseCog.db_count_spot(ctx.author.id, |
||
| 50 | monster_type_dict[spotted_monster["type"]]) |
||
| 51 | return |
||
| 52 | else: |
||
| 53 | await ctx.channel.send( |
||
| 54 | f"{ctx.author.mention} monster not found; are you sure that name is correct?", delete_after=5) |
||
| 55 | elif ctx.content[0] in cords_beginning: |
||
| 56 | await DatabaseCog.db_save_coords(ctx.content, ctx.channel.name) |
||
| 57 | return |
||
| 58 | |||
| 59 | |||
| 60 | def setup(bot: commands.Bot): |
||
| 61 | bot.add_cog(SpotCog(bot)) |
||
| 62 |