 Programmers have many mantras and aphorisms about how to write good code, but perhaps the most important one is D-R-Y. Don't repeat yourself. The basic point of D-R-Y is that whenever you feel yourself doing the same thing over and over in your code, there's probably a better way to write the code that avoids that duplication. Repetition is the number one sign that you're doing something wrong, that you're doing more work than you need to do, or that you're creating more work for yourself down the line, because the problem with repetition and code is that later on when you want to change something, and you will want to change things, you're going to have to modify the code in many places at once to make any small change. So repetition is very toxic. The fundamental tool we have for avoiding repetition is the function. As a beginning programmer, you're going to be quite uncertain how to organize your code into functions. In fact, you won't even know when you should write a function at all. The problem is that when we talk about repetition, we don't necessarily mean verbatim repetition. Very often you will get the vague sense that you have repeated yourself, but that repetition will be intermingled among other things, and it may not be obvious how you can disentangle and extract that repetition into its own functions, how you can take several particular cases and generalize them into one case. There's also the related question of how much work individual functions should perform. The mantra here has always been that a function should do one single thing and only that thing. If we follow this prescription well, we should generally end up with code in which most of the functions end up quite short. How short exactly? Well, if there's a consensus among programmers, I would say it's this. The majority of your functions should stay in the range of about 15 to 30 lines. At the very least, anything above about 30 lines strongly warrants careful consideration as to whether it might perhaps be better split into smaller functions. In programming languages, the term scope is used to refer to both the place and code and the time during execution, where and when a thing exists. The variables of a function are said to have local scope to be local to the function in which they are found. So here cat, dog, and bird are all local variables of the function, Kate. And yes, parameters really are just local variables. They're only special in the way they get their initial values from the arguments to the function calls. When we say that cat, dog, and bird are local to the scope of Kate, what do we mean? Well, this means that they exist only in that function and so cannot be used outside the function or in another function. In fact, when a function is called, the local variables are created for that individual call. And then when the function call returns when it ends, those local variables disappear. They're destroyed. They're nowhere in memory. They don't exist. Effectively, each different call to the same function has its own independent set of the local variables. So in two different calls to Kate, the cat variable in one call is a separate variable from the cat variable in the other. So it be clear that when we call a function, the local variable values are not retained from any previous call to that function. This uniqueness of local variables and different invocations will be very important to understand when we discuss function recursion. A namespace is simply a space in the abstract sense in which a set of names exist. What we want to avoid in programming languages are namespace collisions. A namespace collision is the situation in which you have a single name that's ambiguous because it refers to more than one thing. In daily life, we cope with these ambiguities such as in cases where you have two friends with the same name. Programming languages, however, can't have any ambiguity of what a function or variable name refers to. The simplest rule a programming language could adopt to avoid namespace collisions is to simply decree that one name always refers to the same thing throughout the entire code of a program. In practice, though, this would be quite inconvenient. For one thing, it would just be bothersome if we had to come up with unique names for simple variables like loop counters. For another, when writing any new code, we'd constantly have to check the entire rest of our code to see if a name we want to use is already in use. Consequently, languages almost universally adopt the rule that each function is its own namespace. For example, here we have a local variable coconut in the function Miguel, but then we also have a local variable coconut in the function colon. But this is fine because each function is its own namespace. Coconut in the one function has nothing to do with coconut in the other. The two variables just happen to have the same name. This works out fine because as we just explained, each function is its own scope anyway. The variables of a function only exist for the duration of each invocation. So it's simply not possible for one function to use the variables of another. For example, we can't use the local apple of the Miguel function inside the function colon. And so the language will give us an error if we attempt to do so. If we assign to a variable named apple in the colon function, then what we are actually doing is creating a new separate local variable in colon that has nothing to do with the variable apple in Miguel. There are other ways in which you might get name collisions. For instance, it's possible you might create a variable with the name of a function. Here we have two functions, one called Harry, the other called Lisa, and Lisa has a variable called Harry. So the question is, if in the body of Lisa, I use the name Harry, which does it refer to the local variable or the function pigeon solution to this problem is crude yet simple pigeon disallows variables and functions with the same name to coexist. So this code would just be rejected outright. As we'll see in later units, most languages have rules that allow for such name reassess without ambiguity.