 This video is about refactoring, which is ways to restructure your program So what do we mean when we say refactoring? Essentially, it's removing duplicate code or similar code that we see in parts of our program We don't want two bits of code that look roughly the same when they can be Clapsed down into one piece of code with a few changes Why do we do this? Well Mainly it's to make the program easier to understand It also improves code maintenance If you have to make a change and some piece of code Exists in essentially the same form in multiple places in your program And you need to go make some change in those multiple places Instead of having just one chunk of code for all that and then you just have to make one maintenance change Let's have a look at some examples here I mean this is not meant to be a comprehensive list of everything you can do for refactoring It's more just to get you thinking about the sorts of things that you need to you know do when you do refactoring So here's a simple example here We've got some numbers in here the 20 and the 20 Let's replace those by having a constant And we know what it's all about and maybe that circle size gets used somewhere else in the program We can use the same constant there Again easy for maintenance. We have to change the circle size. We just change it in one place Have you've written some ifs like this? You can see that the bodies of both those ifs is exactly the same So we can just combine those with an ore and we've got it in the one place And here we've just got a very simple body of y equals 4 But if we had a complicated body then we'd be just we'd see that big chunk of code in two places And we don't want it in two places. We want it in just one Here we have another version of an if we can see we've got the same condition with different bodies And this time we can just combine the two bodies into one and just have one if Sometimes we have nested ifs Again depends on the exact structure of the nesting in a case like this we have a simple change to make and Maybe we're not exactly reducing the code here But I would suggest that the second version of the code is easier to read Perhaps you've written if conditions like this Really this can be done much more simply with a sort of good understanding of what Boolean values are about Excuse me. We can just get rid of the if entirely and just replace it like this because if x percent two is equal to zero then it's true and so we've already got the value true and if x percent two equals zero is false that we've already got the value false We don't need to use an if and an else to get to these values sometimes There are parts of our code that we can't get to and processing is pretty good at identifying things like this and so he would actually point this out to you, but Some programming languages is not always the case so That last line there the return three will never be reached so we should get that out of our code Sometimes there are logical things in your program where you can see that certain bits of your code you can't get to But processing is not smart enough to see that So you should make sure you get rid of those dead bits of code here we've got five lines and Hopefully we can see there's a nice pattern there. We can see The x and y coordinates going 30 60 90 20 150 It's a nice easy pattern there of things going up by 30 so Just wheel in a loop and that collapses that down nice and simple And you see we've just got the loop starting at 30. It's going up to 150 in steps of 30 You might be tempted to write the loop like this But I'd say I'd suggest this just doesn't have the clarity the previous one. I look at the code and I think okay well What values do the x and y coordinates go through? Oh, it's 30 times i or what's the range of i 1 to 5? Oh, okay, it's 30 times 1 up to 30 times 5 30 up to 150 So it's just not as apparent Much, I mean, I think this previous version is much clearer You can see just by looking at the first line of the fourth statement Exactly what the range of i's values are there Sometimes you've got something like this which looks very similar to the previous example But we don't have a nice pattern here 30 50 110 120 160. Well, I don't see any simple formula for that Sometimes we can just use an array to capture those values And now we can just have something that steps through the array and that will give us those values 30 50 110 120 160 And here we're trying to do the same thing We've got these lines of code on the left and we're trying to collapse this down Into a for loop by having some arrays and we can see that It's all a bit complicated, but you can see that this thing on the right here it has Uh like this one one or two is meant to indicate whether you've got You notice you have an ellipse rectangle ellipse ellipse So we need something to say whether we're going to do an ellipse or a rectangle So that's what this first value is one means ellipse. There's just an arbitrary value and two Means rekt and you'll see down in the code here if the If that first value there the zero element is one then we draw an ellipse. Otherwise we draw a rekt And then you can see all the fill values are in the one two three position. They are one 10 21 93 and then Everything to do with how to draw The ellipse or rectangle is in the four five six position You can see the six positions duplicated here because we notice that it's always 20 20 70 30 30 50 50 so Clue this is going overboard Clear the code on the left is actually much simpler than this complicated code on the right But sometimes this we saw in the previous example. It was worthwhile doing So it's always worthwhile thinking about this for complicated cases, but obviously this this is just going overboard and we're better off with the original code And let's uh Look at Another example of refactoring here. Um, this was prompted by a Uh, I know a maths joke. I heard years ago. Um, so think about Boiling an egg Here we go. Here's some steps to boiling egg. Get out a saucepan. Put some water in it. Still on the stove Violet stick the egg in four minutes later. You yank the egg out and Hopefully that's what you want. So okay. Nice simple steps So we've got an algorithm there. So we'll call this boil egg and we had the steps on the last slide What are we doing here? So purpose to boil an egg input. We've got a raw egg Effects none. We're ignoring the fact that the kitchen gets a bit hotter and uh, whatever Um, but we're just interested in the output. The output Um is meant to be a boiled egg a bit on the runny side Okay, but uh One day you come into the kitchen and you find there's a saucepan On the stove and it's already got some water in it. What do you do? Well And this is back to the math the math joke is that what a mathematician would do is to Empty the water out of the saucepan try the saucepan put it back in the cupboard and then apply the previous algorithm Okay, well, so let's just think about what this means from a programming point of view. So really we've got two Usages here the original usage where you start from scratch and you use the boil egg algorithm that we talked about before where everything's like the saucepans in its cupboard and whatever and then you have the second usage with the mathematician Who's the butt of the joke here who? Decides to empty the saucepan dry the saucepan and put it back in the cupboard and then apply the boiled egg algorithm going through all its steps Okay, well, let's just think about how we could refactor this to make sense of this so we can start off by basically splitting the Boil egg algorithm into two parts. We have a prepare saucepan algorithm And we have a boil egg in saucepan algorithm And this is really just splitting the previous algorithm up into two parts as we can see from the steps there and so then we have Our new usage can be summed up like this If everything's in its place, then we do the prepare saucepan algorithm And then we do the boil egg in saucepan algorithm and everything's good And then the second usage is where there's already a saucepan on the stove with water in it So we can immediately just do boil egg in saucepan algorithm And then we can go back and say okay. Well, but we had this original boil egg algorithm And we don't really we now have got three algorithms. We've got a boil egg algorithm. We've got the prepare saucepan algorithm and we've got the boil egg in saucepan algorithm So we've got too many there because they're they're duplicating some of their functionality So what we want to do is take the original boil egg algorithm and we'll Start again on that and instead of going through all the Steps that it had originally instead will take advantage of these two new algorithms the prepare saucepan and the boil egg in saucepan algorithms So now we only have two algorithms that have real functionality in them the prepare saucepan and the boil egg in saucepan and the original boil egg now just uses those two so again, we've kept our code nice and clean and If we were using boil egg anywhere, you know our code in some other part, then we can still use our boil egg Algorithm because we've managed to rewrite it. So it uses the new stuff. So if somebody came along and said there's some change to be made to um, the the prepare saucepan or the boil egg in saucepan algorithm Then that needs to be made in just one place And everything else will just flow from it because for instance the boil egg algorithm Uses those other two algorithms Now the way we could have done this to refactor it is to make the boil algorithm more complicated by adding a boolean parameter the first parameter And second parameter being the egg the raw egg and then we can use that boolean parameter Say whether the saucepan is ready or not and so then we can see that if the saucepan is not ready then we go through the preparing the saucepan part and if the and then either way we get to the second part of the function there and we can see that then we just do the Boiling the egg etc once the saucepan is prepared. So again, there's lots of ways to refactor With this one, it means that if anybody had boil egg somewhere else in their program with one parameter They now have to change it. So it's got a second parameter whereas the previous way It didn't require having to change Wherever boil egg was previously used So maybe this is a bit of a complicated example, but I just want to show that you know refactoring is a serious business and out in the real world When you do program maintenance you come across all these sorts of issues and they need to be dealt with properly