Conditions | 14 |
Total Lines | 68 |
Code Lines | 34 |
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 tests.validation_test.teardown_module() 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 | """ |
||
28 | def teardown_module(module): |
||
29 | """ The teardown (module) function is called when all tests in this module are complete |
||
30 | |||
31 | This function will collect and report on the results of all validation tests. That is, their correctness and their |
||
32 | run-times. These reports are collated into ordered CSV files, each capturing up to 100 contiguous tests: |
||
33 | |||
34 | * tests 1-100 |
||
35 | * tests 101-200 |
||
36 | * etc. |
||
37 | |||
38 | These CSVs will be picked up by other code to ultimately build the documented project. These CSVs will contribute |
||
39 | to the tables of solutions and their respective run-times. |
||
40 | |||
41 | :param module: the module under teardown (i.e. :mod:`tests.validation_test`) |
||
42 | :return: None |
||
43 | """ |
||
44 | |||
45 | def build_csv(start_problem: int, end_problem: int) -> None: |
||
46 | """ Helper function to build a CSV for 100 problems in a 10x10 grid """ |
||
47 | |||
48 | # Check that start_problem and end_problem define a block of 100 problems |
||
49 | assert isinstance(start_problem, int), "start_problem must be an integer" |
||
50 | assert isinstance(end_problem, int), "end_problem must be an integer" |
||
51 | assert start_problem % 100 == 1, "start_problem must be 1 modulo 100" |
||
52 | assert end_problem % 100 == 0, "end_problem must be 0 modulo 100" |
||
53 | assert start_problem < end_problem, "start_problem must be less than end_problem" |
||
54 | assert end_problem - start_problem + 1 == 100, "start_problem and end_problem must be 100 apart" |
||
55 | |||
56 | global results # map the local results variable to the globally shared variable |
||
57 | |||
58 | header = [""] + ["***{}**".format(i % 10) for i in range(1, 11)] |
||
59 | |||
60 | path = os.path.join(DOC_ROOT, "{}-{}.csv".format(start_problem, end_problem)) |
||
61 | with open(path, "w", newline="") as fp: |
||
62 | # Open a CSV file and create a header row |
||
63 | cw = csv.writer(fp) |
||
64 | cw.writerow(header) |
||
65 | |||
66 | row = [] # temporary list to hold each row as it is populated |
||
67 | |||
68 | for i in range(start_problem, end_problem + 1): |
||
69 | # Add the row range to the start of a CSV row |
||
70 | if i % 10 == 1: |
||
71 | row.append("**{} - {}**".format(i, i + 9)) |
||
72 | |||
73 | # Add the results for problem number i to the next cell in the CSV |
||
74 | try: |
||
75 | if results[i]["correct"]: |
||
76 | row.append("|tick| :doc:`{:.2f} <solutions/{}>`".format(results[i]["time"], i)) |
||
77 | else: |
||
78 | row.append("|warning| :doc:`{:.2f} <solutions/{}>`".format(results[i]["time"], i)) |
||
79 | except KeyError: |
||
80 | # KeyError caused by results[i], i.e. there isn't a solution for problem number i |
||
81 | row.append("|cross|") |
||
82 | |||
83 | # Flush the 10-long row to the CSV file |
||
84 | if i % 10 == 0: |
||
85 | cw.writerow(row) |
||
86 | row = [] # blank row for the next one |
||
87 | |||
88 | # Construct CSVs in blocks of 100 problems |
||
89 | build_csv(1, 100) |
||
90 | build_csv(101, 200) |
||
91 | build_csv(201, 300) |
||
92 | build_csv(301, 400) |
||
93 | build_csv(401, 500) |
||
94 | build_csv(501, 600) |
||
95 | build_csv(601, 700) |
||
96 | |||
180 |
This check looks for invalid names for a range of different identifiers.
You can set regular expressions to which the identifiers must conform if the defaults do not match your requirements.
If your project includes a Pylint configuration file, the settings contained in that file take precedence.
To find out more about Pylint, please refer to their site.