Find a Balance

00:00 Oh, we still need to change, of course, refactor,

00:06 refactor the question and answer. `validate()`. All right. That is a common thing when you work with comments, that they may need to be updated as well when you refactor your code. But good catch there.

00:21 I also really like how you cleaned up the code and, at the beginning, the dictionaries that we now have on line 17 and line 21, so the valid_input with "source" and "target" and the invalid_input with "source" and "target" were just called X.

00:38 Like, the dictionary was called X, and the keys were "s" and "t".

00:43 And you might have experienced this sometimes when you read questions online, where people use fu and bar as variable names to make the code generic.

00:54 And we were saying before that you should aim for making your code generic so people can understand it. But you shouldn’t go too far with it, because it’s always a good idea to call the variables what they are and help your readers to understand what you mean with it. So by naming the dictionaries like Martin did here, valid_input and invalid_input, it says what it is.

01:18 And with "source" and "target", instead of "s" and "t", as keys, you are also very clear about what the content of your dictionary is.

01:28 So if you go generic with your code to share it, which is generally a good idea, don’t take it too far. Still name the variables in a way that helps your readers to understand what they mean. Great. And so maybe one thing we could still do here now is to—because we removed this try and except block, but there’s good reason for catching exceptions too—and let’s reintroduce them in the next lesson to show where, if you actually did want to catch the exceptions, where you would do that and how then raising and catching exceptions can play together to be something useful for your codebase. Perfect.

02:04 So let’s hop into the next lesson.