All language subtitles for 8. How to become a Better Programmer - Code Refactoring

Now, in it's current state, our styles.css is looking a little bit atrocious.
1

I mean there's so much repetition here.
2

Montserrat-Bold font-family, Montserrat-Bold font-family.
3

And you might even remember how many times we wrote padding 7 percent 15 percent, right?
4

We wrote it like all over the place here and here and many many more.
5

So as I said previously, as a programmer, we’re always aspiring to be dry.
6

Do not repeat yourself.
7

And the opposite of this is kind of our code at the moment, and it's probably like wet code.
8

We enjoy typing.
9

This is why we want to refactor our code on a regular basis in order to keep it performant and easy
10

to read.
11

Now whenever I go on holiday I always seem to be packing an hour before I have to leave.
12

I think I have some medical condition where I can't pack in advance so my suitcase always inevitably
13

ends up looking like there's basically a mess and I have to sort of like kneel on it to try and close
14

it and everything is everywhere and it's just impossible to find anything
15

once I actually do arrive. Now, instead, what would be a lot nicer is if I had actually learned the skills of
16

packing properly so that everything is neat and tidy and myself or anybody else would be able to easily
17

find anything they need inside the suitcase.
18

And this is kind of the idea behind code refactoring as well, right?
19

I mean, incidentally, I’m also the type of person who cooks, makes a huge mess in the kitchen,
20

and then I will just sort of mentally ignore it until I eat, and then after I eat I kind of have to confront
21

the situation, or sometimes, you know, maybe even go two meals without tidying the kitchen.
22

But of course the longer that you go on like this the harder it is to continue cooking because you can't
23

find anything and everything is everywhere.
24

One of the most memorable things that I remember from one of my mentors is that he once said you should
25

refactor your code and maintain it to keep your code in a state as if you expect the next person who's
26

going to have to maintain your code to be an axe murderer.
27

Basically how much do you want to get murdered when they can't find any of the variables and they can't
28

figure out why something's going wrong because your code is a mess and it's a load of unorganized spaghetti
29

code?
30

So we've spoken enough about why we need to refactor our code, but how do you actually do it?
31

Well there's a number of guiding principles that most people will follow when they're refactoring their
32

code.
33

And for me the order of importance goes more or less like this.
34

So I would prioritize readability as the number one priority.
35

So make sure that your code is easy to understand but not just, you know, yourself but maybe, say,
36

your future self,
37

say when you come back in a year to try and understand your code, can you quickly understand what's going
38

on?
39

Is everything organized in a logical way?
40

Is everything commented so that you can easily understand what each part of the code is about?
41

And also when somebody else comes along or if you're working on the same project with another person,
42

and this is a very common scenario if you're working in any sort of company or team, you're likely to
43

be cooperating on the same piece of code.
44

So remember axe murderer.
45

Bad.
46

So try to keep your code readable.
47

Now the next thing is modularity and this kind of relates to how easy is it to reuse bits of your code
48

and how easy is it to narrow down.
49

Say if, you know, one particular part of your web site breaks down, is your code modular enough that you
50

would be able to narrow down on the exact section of code or code file that's responsible for the problems
51

that's occurring? Now,
52

at the moment, because we're only covering, basically, HTML and CSS, we haven't really dug into this idea of
53

modularity, although
54

I've tried to impress upon you the importance of keeping your structure code inside the HTML and your style
55

code inside the CSS, so that when you come to debugging your code you know where to look.
56

And this kind of division of labor is another form of modularity.
57

But as we go on to learn more about Javascript or NodeJS, back end stuff, we're going to be making our code
58

more and more modular so that it's easier to maintain as it gets more complex and more interesting.
59

And then we come on to the slightly less important things like efficiency.
60

How fast does your code run?
61

There's ways of making your code very efficient and very fast.
62

Now a lot of that happens at the choosing the programming language level, so, you know, you want something
63

fast, choose something like C,
64

right, something that's close to the mantel. But there's also other ways of improving the efficiency of
65

your code.
66

But it's much much less important than keeping your code modular and readable.
67

So that's why it's number three.
68

And the last thing that a lot of people like to obsess about but it's mostly a vanity thing is the
69

length of your code.
70

You’ll very often hear coding bros
71

talk about how short they've managed to make their code.
72

And very often when you're talking to a bunch of programmers and somebody says that I built this feature
73

and you know it only has what like 21 lines then somebody else is going to come along,
74

inevitably, and going to be like, well I can write that in Haskell and it'll be 10. And, you know, yours
75

truly, I might have also engaged in such terrible behavior.
76

But it's kind of more like recreational.
77

This is not good coding practice by any means.
78

Now if you're cutting down on the length to improve readability then that's great.
79

That's really really important.
80

Making sure that you're not repeating yourself in your code so that you keep your code really well structured
81

and readable, that is very important, up there,
82

number one. But if you're purely just reducing the length of your code and actually making your code
83

less readable, less comprehensible, then that's bad.
84

And if you're building code for enterprise or for your company then that's, you know, probably not what you
85

want to do.
86

But if you are doing it just for fun there's actually a sport amongst programmers called code golf.
87

Don't worry it doesn't involve, you know, getting changed or actually having to sweat.
88

All it involves is trying to figure out how you can write the shortest code possible in order to achieve
89

a certain task.
90

And if you're interested there's a section of Stack Exchange called codegolf.stackexchange, where
91

they've got a whole bunch of these kind of things.
92

For example, this one is where you get to create a magic 8-ball that spits out one of these answers randomly
93

and you have to do that in the least number of characters of code possible.
94

So you see stuff like people using crazy programming languages which are just, like, look how short this
95

is.
96

And for some reason it’s able to spit out that code, but more likely you're going to see something like
97

this or something like this.
98

But it's a fun place to explore
99

once you've really understood a particular language and you really want to flex your code biceps for
100

recreation. But, for code that you're going to ship,
101

this is not important at all.
102

So I just want to make that really clear.
103

Now let's head into our code and see what we can do to refactor it and make it more readable and more
104

modular.