teacherc
commented
1 year ago Closed teacherc closed 1 year ago
teacherc
commented
1 year ago 
BurningSquid
commented
1 year ago Notice how the process of trying to think of good variable names can lead to a slightly different program structure with more flexibility. It's often the case that variables or functions that are hard to name are doing too many things at once, and should be broken up until simple names and operations convey the meaning clearly.
Whole comment is great, I definitely think it's important to note this last bit because new developers can get a bit frustrated with people being nitpicky about names. But ultimately asking these questions can bring to light a lot of issues in design. Some call them "code smells" lol
From Reddit: https://www.reddit.com/r/Python/comments/zb6ro9/comment/iys8m4e/?utm_source=share&utm_medium=web2x&context=3
Related addition to this: naming could use some work here. Use descriptive names that are less specific about the implementation, it will convey more information to future readers, and often drives you to better implementations. In a python script, code_dict can mean so many different things, and the last thing I would expect it to be is a module and not a dictionary at all.
If you used codes.py and lovely = {...} so that you had codes.lovely rather than code_dict.lovely_dict, it is shorter, less implementation focused, and more natural. However, there still is something to be desired..it's not very obvious what a code is or what lovely is. Note that keeping the _dict suffix doesn't add any clarity here, your IDE can tell you it's a dict, but...a dict of what?
The dicts map codes to descriptions. So why do you need a lovely dict and a moody dict and a ... dict if you just need a mapping from the code to the descriptions? Well, you also need to specify which codes are a part of the lovely and moody and ... vibes. But that means these dictionaries play two separate responsibilities; the descriptions and which codes are part of each vibe are coupled in your code, when really they are separate concepts.
It seems more like you should have a dict which map all the codes to their descriptions, and then just a container of codes for each vibe. So for example, in codes.py
descriptions = { "248": "Fog", "143": "Mist", "122": "Overcast", "119": "Cloudy" "116": "Partly Cloudy", "113": "Clear, Sunny", }
moody = ["248", "143", "122", "119"] lovely = ["116", "113"] Now the descriptions dict could theoretically be populated by something else, like an API call. Instead of mapping to a string description, it could map to some object representing the weather with more info. In both cases, you wouldn't have to edit the moody/lovely/etc lists, so your program still would maintain the truth of what codes map to what genres regardless of what you do with the descriptions dict. This is the benefit you get from decoupling the two concepts.
Notice how the process of trying to think of good variable names can lead to a slightly different program structure with more flexibility. It's often the case that variables or functions that are hard to name are doing too many things at once, and should be broken up until simple names and operations convey the meaning clearly.