06 - composing functions - refactor to build up a more complicated function #366
Comments
You're right that the composed Currently we don't talk about "magic numbers" in the lesson. IMO, this is a bit of a premature optimization when instructing novice programmers -- yes, as you scale up, using variables for these numbers will make your code easier to read and easier to modify. But is that a necessary anxiety to give a novice programmer when they're just getting their feet wet? Further, 273.15 isn't an egregious example of a magic number as it will never need to be changed to something else. On the other hand, there is some precedent about talking about code style in callouts in the "What's in a name" callout in episode 2. I wouldn't be opposed to a callout in episode 6 about magic numbers, but I don't think I would change the functions that are there already. |
I'm concerned about the conceptual complexity, not the computational. The way the functions are currently laid out, it's like 2-steps-forward-1-step-back to do fahr to celsius via fahr to celsius to kelvin plus kelvin to celsius. Sure, I can see the "laziness" appeal, but I don't see this as a good example of building up complexity. Let me put together a quick PR just to see what it looks like. I think it'll be cleaner, but I've never taught this lesson so I could be wrong! |
Filling in steps for trainers on AMY
ISSUE_TEMPLATE.md: Nudge contributors to specify episodes unambigously
Currently, the fahr_to_celsius function is composed of fahr_to_kelvin and kelvin_to_celsius, both of which involve the "magic number" 273.15 -- this seems like bad form; and fahr_to_kelvin includes both conversion functions, so the composition doesn't really make sense, since it "undoes" a conversion that was already done.
The text was updated successfully, but these errors were encountered: