We covered a lot of rules in the last video.

Things like keeping functions limited and not causing side effects.

But how do we actually do those things?

Let's go to WorkSpaces and look at some things not to do.

So to illustrate some of the things that are bad ideas,

things we shouldn't really do when we use Python, I've got a file here called

bad examples.py, and we're gonna walk through what each of these things are.

So up at the top, we have this list that's a very important list.

It needs to stay exactly that way it is.

Maybe these are the order that players signed up, or any number of things.

So it needs to stay in the order of five, two, three, one whenever I use it,

in different places, but you may want to do stuff with it.

And then we have a variable called name that's just my name.

So we have this function here called def mutate, and

it takes very important lists and it sorts it.

So let's do, right here, let's print

very_important_list, and then let's call mutate.

And then let's again print very_important_list.

All right, so then we can run this with bad_example.py.

And you can see that, since inside this function,

we called sort on the list, it sorted the list even out here.

So ideally, we'd get the same thing here and here.

Both of those print calls would give us 5, 2, 3, 1, but instead,

since we called mutate, we sorted the list in memory, it's sorted for good

now as far as the program is concerned, and we get two different outputs.

So, you don't want to call methods on mutable types

unless you know exactly what you're doing and why, because you get this.

It changes that list outside of the scope.

All right, so that's a bad one.

We won't do that anymore.

On our next function here we're using global.

And so what global does, there is another keyword similar to global called nonlocal

that I'll put in the teacher's notes and recommend that you look up.

What global does though is it says, hey, go out to the global scope,

go as far out as you need to go and see if you can find a variable with this name.

And if you do, give it to me, I'm gonna use it.

So, normally, let's ignore this line.

Let's comment out that line.

Okay, so, if we're just looking at this function, all we're doing in here is we're

setting a name, and we're setting it to the string James, okay?

But, when we use global and we use name it

comes out to this global scope and says oh hey there's a variable here called name.

Let's reference that one and then here we've set it to James.

So again let's do a similar kind of experiment we're gonna print name and

then we're gonna call global.use.

And then we're gonna print name again.

Now ideally we would get Kenneth both times

but We get Kenneth and then we get James.

And the reason is because we've overridden that global name variable.

We've got back up to this top scope and

said hey, we're gonna change that variable up there.

So don't do that.

That's not good or predictable.

There are occasionally times when you're gonna wanna use global.

But those are very few and very far between.

So now these next two we don't really need to run them.

We're just gonna talk about these.

I mentioned that we want to avoid functions that are too long, so

let's look at this.

We have this long_func here, it imports random, it gets some random

numbers between 5 and 250, or rather shuffles the range 5 to 250 randomly.

And then we run through, what do we have?

We have an index and a num coming out of enumerate of all those numbers.

If the number is divisible by three, or isn't evenly divisible by three.

So, if this comes back as a truthy value, then we set the number to the fifth power.

If it's not evenly divisible by seven, then we set the number to the tenth power,

otherwise I always set the number squared.

And then we total all those up, and then we print out the total and

then we're returning the list of shuffled and now randomly mutated numbers.

I wrote this function and I just had to stop and read it for

a second to tell you what was happening in it.

So we don't want functions like this, where there's just so much stuff going on,

and you have to constantly think about what's happening.

And now you may be saying but Kenneth I can put in comments,

I can put in a doc string and I can explain what's going on.

And then everybody will know and yeah that's true you can but

if you have to explain what's happening in a function, what, not why,

explaining the reason why the function was written is a great thing to do.

But if you have to explain what the function does

then you've probably written that function wrong, you should probably simplify this.

This would be really good if we were to say like,

maybe the function takes in the range of numbers, the list, right?

Maybe it takes in that list and then works on them.

Maybe it just returns that shuffled list or

it returns, instead of returning the shuffled list because then you

are repeating what the Python already does, maybe it returns the mutated list.

This part.

And it doesn't print or total or anything like that.

Because why do we need to total it?

The total seems completely useless.

So, things to think about when you're designing functions,

when you're designing your software.

And then for the last one, lot_of_inputs.

We mentioned having functions that take too many inputs,

they take a whole bunch of stuff.

Now in this case,

if you look through you'll see that I've taken inputs that I'm not using.

It's kind of an idea of like, well, we might need that some day so let's do it.

That's generally a bad idea because it means you're usually putting way more

thought into the software than actually needs to be there.

And that might sound like a silly thing, but

it means that you're spending all this time on details that don't actually

matter, instead of writing the code that you need.

So try not to do that.

Try to do things in a smart and

simple way to where you know exactly what the code's gonna do.

So in this one we've got seven inputs coming in,

only four of them actually get used.

And we return this and again this is when I would say it's too long,

it's too complicated of a function too.

Cuz inside here we make these two named tuples which act kind of like classes

and then we return objects that are of those classes and

it's a lot of work for one function.

So we're gonna avoid all of these design mistakes,

all of these usage mistakes when we write our code.

Mutable types, like lists and

dictionaries, are things that we can deal with.

Python gives us some handy tools like slices and some functions that we'll cover

later in this course, that make it pretty easy to leave those things alone.

Global is also pretty simple to avoid.

Just don't use it.

The last two things, writing long functions, or

writing functions with inflated scopes are things you get better at not doing

the more you pay attention to your code.

You'll find, as you get more experience and practice,

that it's second nature to keep things tight.

In our next video, we'll get to the tools that we're actually going to

use in the course, and the data that we'll use those tools on.