Conditions | 11 |
Total Lines | 55 |
Lines | 0 |
Ratio | 0 % |
Tests | 31 |
CRAP Score | 11 |
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 dtb._run() 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 | #!/usr/bin/env python |
||
92 | 1 | def _run(args, cwd, err): # pylint: disable=W0613 |
|
93 | """Process arguments and run the main program. |
||
94 | |||
95 | @param args: Namespace of CLI arguments |
||
96 | @param cwd: current working directory |
||
97 | @param err: function to call for CLI errors |
||
98 | """ |
||
99 | # Run the GUI |
||
100 | if args.gui: |
||
101 | logging.info("launching the GUI...") |
||
102 | return gui.run(args) |
||
103 | |||
104 | # Find the sharing directory |
||
105 | root = args.root or share.find() |
||
106 | |||
107 | # Create a new user and exit |
||
108 | if args.new: |
||
109 | return _new(args.new, root) |
||
110 | |||
111 | # Get the current user |
||
112 | if args.test: |
||
113 | this = user.User(os.path.join(root, args.test)) |
||
114 | else: |
||
115 | this = user.get_current(root) |
||
116 | this.cleanup() |
||
117 | |||
118 | # Delete user and exit |
||
119 | if args.delete: |
||
120 | this.delete() |
||
121 | print("deleted: {}".format(this)) |
||
122 | return True |
||
123 | |||
124 | # Display incoming, share a song, and/or display outgoing and exit |
||
125 | if any((args.incoming, args.share, args.outgoing)): |
||
126 | |||
127 | if args.incoming: |
||
128 | logging.info("displaying incoming songs...") |
||
129 | for song in this.incoming: |
||
130 | print("incoming: {}".format(song)) |
||
131 | |||
132 | if args.share: |
||
133 | path = os.path.abspath(args.share) |
||
134 | song = this.recommend(path, args.users) |
||
135 | print("shared: {}".format(path)) |
||
136 | |||
137 | if args.outgoing: |
||
138 | logging.info("displaying outgoing songs...") |
||
139 | for song in this.outgoing: |
||
140 | print("outgoing: {}".format(song)) |
||
141 | |||
142 | return True |
||
143 | |||
144 | # Run the command-line interface loop |
||
145 | logging.info("starting the main loop...") |
||
146 | return _loop(this, args.daemon, not args.no_log) |
||
147 | |||
186 |
Generally, there is nothing wrong with usage of
*
or**
arguments. For readability of the code base, we suggest to not over-use these language constructs though.For more information, we can recommend this blog post from Ned Batchelder including its comments which also touches this aspect.