sprout42 /
StarStruct
| Conditions | 11 |
| Total Lines | 56 |
| Lines | 0 |
| Ratio | 0 % |
| Changes | 2 | ||
| Bugs | 0 | Features | 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 TestStarStructNone.test_single_element_2() 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 python3 |
||
| 20 | def test_single_element_2(self): |
||
| 21 | def pseudo_salted_md5(salt, original): |
||
| 22 | temp_md5 = md5(original) |
||
| 23 | |||
| 24 | if salt is None: |
||
| 25 | salt = b'' |
||
| 26 | |||
| 27 | return md5(salt + temp_md5.digest()).digest() |
||
| 28 | |||
| 29 | TestStruct = Message('TestStruct', [ |
||
| 30 | ('length_in_objects', 'H', 'vardata'), |
||
| 31 | ('vardata', self.VarTest, 'length_in_objects'), |
||
| 32 | ]) |
||
| 33 | |||
| 34 | CRCedMessage = Message('CRCedMessage', [ |
||
| 35 | ('data', TestStruct), |
||
| 36 | ('salted', None), |
||
| 37 | ('function_data', '16B', pseudo_salted_md5, ['salted', b'data'], False), |
||
| 38 | ]) |
||
| 39 | |||
| 40 | test_data = { |
||
| 41 | 'data': { |
||
| 42 | 'length_in_objects': 2, |
||
| 43 | 'vardata': [ |
||
| 44 | {'x': 1, 'y': 2}, |
||
| 45 | {'x': 3, 'y': 4}, |
||
| 46 | ], |
||
| 47 | }, |
||
| 48 | 'salted': b'random_salter', |
||
| 49 | } |
||
| 50 | |||
| 51 | made = CRCedMessage.make(test_data) |
||
| 52 | # assert len(made) == 5 |
||
| 53 | assert len(made.data.vardata) == 2 |
||
| 54 | assert made.data.vardata[0].x == 1 |
||
| 55 | assert made.data.vardata[0].y == 2 |
||
| 56 | |||
| 57 | no_data = made.pack() |
||
| 58 | regular = CRCedMessage.pack(**test_data) |
||
|
|
|||
| 59 | assert regular == no_data |
||
| 60 | |||
| 61 | # Show that there's no room to have the random salter be packed |
||
| 62 | len_data = len(no_data) - 16 |
||
| 63 | assert no_data[0:len_data] == struct.pack('HBBBB', 2, 1, 2, 3, 4) |
||
| 64 | assert md5( |
||
| 65 | b'random_salter' + |
||
| 66 | md5(no_data[0:len_data]).digest() |
||
| 67 | ).digest() == no_data[len_data:] |
||
| 68 | |||
| 69 | unpacked = CRCedMessage.unpack(no_data) |
||
| 70 | |||
| 71 | assert unpacked.salted is None |
||
| 72 | |||
| 73 | # TEMP |
||
| 74 | new = unpacked._replace(**{'salted': b'random_salter'}) |
||
| 75 | assert new.salted == b'random_salter' |
||
| 76 | # print(new._asdict()) |
||
| 77 |
Loading history...
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.