1
00:00:00,040 --> 00:00:02,680
Have you ever looked at 
something really complex, maybe 

2
00:00:02,680 --> 00:00:06,080
a tangled mess of wires, and 
just, you know, felt something 

3
00:00:06,080 --> 00:00:08,000
was off? 
Like it needed a good sort out, 

4
00:00:08,080 --> 00:00:10,720
even if you couldn't quite say 
why technically. 

5
00:00:11,280 --> 00:00:13,320
Yeah, that intuitive feeling. 
Exactly. 

6
00:00:13,800 --> 00:00:16,200
Well, that same sense applies to
software code. 

7
00:00:16,440 --> 00:00:18,720
Subtle clues can point to deeper
problems. 

8
00:00:19,040 --> 00:00:22,320
Welcome to the deep dive. 
We take a whole stack of 

9
00:00:22,320 --> 00:00:24,960
information and pull out the 
really important bits for you. 

10
00:00:25,720 --> 00:00:27,960
Today we're getting into the 
world of code smells. 

11
00:00:27,960 --> 00:00:31,240
We're drawing mainly from Marco 
Tulio Valente's Software 

12
00:00:31,240 --> 00:00:35,960
Engineering a Modern Approach, 
specifically Section 9.5. 

13
00:00:36,280 --> 00:00:38,000
Right. 
And our mission today really is 

14
00:00:38,000 --> 00:00:39,800
to help you spot these 
indicators. 

15
00:00:39,800 --> 00:00:42,280
Sometimes they're subtle, 
sometimes frankly they're not so

16
00:00:42,280 --> 00:00:44,200
subtle. 
These signs of, well, it's a 

17
00:00:44,200 --> 00:00:47,080
lower quality code. 
We'll look at why they matter, 

18
00:00:47,080 --> 00:00:50,120
how they impact things, and 
crucially, what you can actually

19
00:00:50,120 --> 00:00:52,480
do about them. 
It's about recognizing those red

20
00:00:52,480 --> 00:00:55,440
flags, whether you're building 
software yourself or just, you 

21
00:00:55,440 --> 00:00:57,480
know, curious about how good 
systems are put together. 

22
00:00:57,480 --> 00:00:59,960
OK, let's jump right in then. 
How would you explain the 

23
00:00:59,960 --> 00:01:04,200
difference between a code smell 
and, say, a bug? 

24
00:01:04,200 --> 00:01:07,000
What's the key thing there? 
That's a really important 

25
00:01:07,000 --> 00:01:09,840
distinction. 
A code smell, or sometimes 

26
00:01:09,840 --> 00:01:13,480
called a bad smell. 
It isn't a bug in the usual way,

27
00:01:13,480 --> 00:01:15,960
It doesn't make the program 
crash or give the wrong answer. 

28
00:01:16,440 --> 00:01:19,960
It's more like an an indicator, 
maybe a symptom that your code 

29
00:01:19,960 --> 00:01:23,680
might be tricky to maintain down
the line, or hard to understand,

30
00:01:23,680 --> 00:01:27,360
modify, or even test properly. 
Think of it like code that just 

31
00:01:27,640 --> 00:01:30,080
doesn't smell right. 
A hint that maybe some 

32
00:01:30,080 --> 00:01:32,480
refactoring is needed. 
Refactoring meaning. 

33
00:01:32,920 --> 00:01:36,480
Ah yes, refactoring is all about
improving the internal structure

34
00:01:36,480 --> 00:01:39,160
of the code without changing 
what it actually does from the 

35
00:01:39,160 --> 00:01:40,800
outside. 
It's external behavior. 

36
00:01:41,040 --> 00:01:42,680
Cleaning it up internally. 
Got it. 

37
00:01:43,000 --> 00:01:45,600
So it's more about the 
underlying structure being weak,

38
00:01:45,600 --> 00:01:48,400
not an immediate failure. 
Precisely, and the word 

39
00:01:48,480 --> 00:01:51,800
indicators is really key. 
Not every single smell means you

40
00:01:51,800 --> 00:01:53,800
have to drop everything and 
refactor right away. 

41
00:01:54,240 --> 00:01:56,360
The decision depends on, well, a
few things. 

42
00:01:56,520 --> 00:01:57,880
How critical is that bit of 
code? 

43
00:01:58,080 --> 00:02:00,520
How often does it actually get 
changed or maintained? 

44
00:02:00,520 --> 00:02:03,160
Is it a core part of the system?
So there's some judgement 

45
00:02:03,160 --> 00:02:05,800
involved. 
Definitely, but ignoring smells 

46
00:02:05,800 --> 00:02:07,640
can lead to technical debt 
piling up. 

47
00:02:07,840 --> 00:02:11,080
You know, making future work 
harder and frankly, more 

48
00:02:11,080 --> 00:02:13,480
expensive. 
OK, let's tackle the first big 

49
00:02:13,480 --> 00:02:15,840
one you mentioned. 
It's maybe the most common 

50
00:02:16,240 --> 00:02:19,840
duplicated code. 
Sounds simple, but what makes it

51
00:02:19,840 --> 00:02:22,480
so bad for a system? 
Duplication. 

52
00:02:22,760 --> 00:02:25,720
It's incredibly common, yes, and
it really has a high potential 

53
00:02:25,880 --> 00:02:28,240
to damage how a system evolves 
over time. 

54
00:02:28,520 --> 00:02:31,640
When code is duplicated, 
maintenance isn't just doubled, 

55
00:02:31,640 --> 00:02:35,040
it gets much worse. 
Any change, any bug fix has to 

56
00:02:35,040 --> 00:02:36,680
be applied in multiple places 
and. 

57
00:02:36,800 --> 00:02:38,280
You might miss one. 
Exactly. 

58
00:02:38,560 --> 00:02:40,880
That creates a constant risk of 
inconsistency. 

59
00:02:41,000 --> 00:02:42,960
You fix it here, but forget it 
over there. 

60
00:02:43,680 --> 00:02:45,120
And it's not just the extra 
work. 

61
00:02:45,120 --> 00:02:46,720
It can actually stifle 
development. 

62
00:02:46,920 --> 00:02:49,440
People become afraid to make 
changes because they might miss 

63
00:02:49,480 --> 00:02:52,600
a duplicated instance. 
That fear can paralyze things, 

64
00:02:52,840 --> 00:02:54,880
make important updates seem too 
risky. 

65
00:02:55,120 --> 00:02:57,520
Wow, OK. 
And fundamentally, it just makes

66
00:02:57,520 --> 00:02:59,160
the whole code base more 
complex. 

67
00:02:59,320 --> 00:03:02,320
You've got logic scattered 
around that could and should be 

68
00:03:02,320 --> 00:03:04,080
nicely contained in one single 
place. 

69
00:03:04,400 --> 00:03:07,440
So once you spot these 
duplicates, what are the typical

70
00:03:07,440 --> 00:03:09,640
ways to fix them? 
What are the refactoring moves? 

71
00:03:09,920 --> 00:03:12,280
Well, there are specific 
refactorings for this. 

72
00:03:12,440 --> 00:03:15,960
For instance, if you see the 
same block of code inside two or

73
00:03:15,960 --> 00:03:19,720
more methods, extract method is 
usually the way to go. 

74
00:03:20,160 --> 00:03:22,760
That just means you take that 
duplicated block, put it into 

75
00:03:22,760 --> 00:03:24,880
its own new method, and then 
call that new method from the 

76
00:03:24,880 --> 00:03:27,600
original places. 
OK, and if you see the same 

77
00:03:27,600 --> 00:03:30,240
attributes and methods popping 
up in several different classes,

78
00:03:30,520 --> 00:03:32,720
then extract classes. 
Often the answer you create a 

79
00:03:32,720 --> 00:03:36,960
new smaller class to hold that 
shared stuff and another common 

80
00:03:36,960 --> 00:03:39,760
one. 
If a method is duplicated across

81
00:03:39,760 --> 00:03:42,800
several subclasses, like 
children inheriting from a 

82
00:03:42,800 --> 00:03:46,080
parent class, you might use pull
up method that moves the common 

83
00:03:46,080 --> 00:03:48,560
method up into the parent class.
All the children can share it. 

84
00:03:48,840 --> 00:03:50,720
The source talks about clones 
here. 

85
00:03:50,720 --> 00:03:52,920
Can you break down the different
types it mentions? 

86
00:03:53,040 --> 00:03:54,960
Yes. 
These blocks of duplicated code 

87
00:03:54,960 --> 00:03:58,800
are often called clones, and the
source categorizes them into 

88
00:03:58,800 --> 00:04:01,600
four types basically based on 
how similar they are. 

89
00:04:02,040 --> 00:04:04,560
Type 1 clones are pretty much 
identical, the only differences 

90
00:04:04,560 --> 00:04:07,720
might be things like comments or
maybe some extra spaces or blank

91
00:04:07,720 --> 00:04:09,640
lines. 
Purely cosmetic. 

92
00:04:09,720 --> 00:04:13,480
OK, exact copies mostly, right? 
Then type 2 clones are like type

93
00:04:13,480 --> 00:04:16,519
one, but they might use 
different names for variables or

94
00:04:16,519 --> 00:04:19,079
other identifiers. 
So the structure is the same, 

95
00:04:19,360 --> 00:04:21,519
but the names are changed. 
Still pretty similar then. 

96
00:04:22,280 --> 00:04:25,600
Type 3 clones build on type 2. 
They have the same structure, 

97
00:04:25,760 --> 00:04:28,320
maybe different names, but also 
some minor differences in the 

98
00:04:28,320 --> 00:04:31,120
actual code statements. 
Perhaps one has an extra print 

99
00:04:31,120 --> 00:04:33,760
command for debugging or a 
slightly altered condition? 

100
00:04:34,320 --> 00:04:36,920
Small variations. 
And type 4, you said they were 

101
00:04:36,920 --> 00:04:39,200
the tricky ones, ah. 
Yes, type 4. 

102
00:04:39,840 --> 00:04:42,080
These are the hardest to spot 
automatically. 

103
00:04:42,960 --> 00:04:45,680
They are semantically 
equivalent, meaning they achieve

104
00:04:45,680 --> 00:04:48,880
the exact same result or 
purpose, but they're implemented

105
00:04:48,880 --> 00:04:51,120
using totally different logic or
algorithms. 

106
00:04:51,440 --> 00:04:53,760
They might look completely 
unalike on the surface. 

107
00:04:54,280 --> 00:04:57,480
Spotting these often requires 
more sophisticated analysis 

108
00:04:57,480 --> 00:05:00,160
tools or just a really deep 
understanding of what the code 

109
00:05:00,160 --> 00:05:02,600
is trying to do. 
Simple text comparison won't 

110
00:05:02,600 --> 00:05:04,160
find them. 
That's a really crucial 

111
00:05:04,160 --> 00:05:06,280
difference. 
The source uses a factorial 

112
00:05:06,280 --> 00:05:09,080
function as an example. 
Can you like describe how these 

113
00:05:09,080 --> 00:05:11,880
clone types might show up there?
Just conceptually, no need for 

114
00:05:11,880 --> 00:05:13,360
the actual code. 
Sure, yeah. 

115
00:05:13,560 --> 00:05:17,720
So imagine a basic function to 
calculate factorial. 

116
00:05:18,080 --> 00:05:23,560
You know, NN 1 and 2 and so on. 
A type 1 clone would be just the

117
00:05:23,560 --> 00:05:26,680
same function copied elsewhere, 
maybe with a different comment 

118
00:05:26,680 --> 00:05:28,000
or indentation. 
Simple. 

119
00:05:28,000 --> 00:05:29,400
Copy paste. 
Exactly. 

120
00:05:29,600 --> 00:05:33,120
A type 2 might rename the input 
variable from north to member or

121
00:05:33,120 --> 00:05:36,080
the result variable from fact to
result, but the calculation 

122
00:05:36,080 --> 00:05:38,920
logic is identical. 
OK, a type 3 could have a small 

123
00:05:38,920 --> 00:05:41,240
difference, Maybe it prints the 
value at the end at the start 

124
00:05:41,440 --> 00:05:43,800
just for logging, while the 
original doesn't. 

125
00:05:44,600 --> 00:05:47,200
A minor statement difference 
right at a type 4 clone? 

126
00:05:47,760 --> 00:05:49,360
Well, that could be a completely
different approach. 

127
00:05:49,640 --> 00:05:53,480
Maybe one version use a for loop
to to calculate the factorial, 

128
00:05:53,640 --> 00:05:56,160
while the other uses recursion 
where the function calls itself.

129
00:05:56,560 --> 00:05:58,760
They both get the factorial, but
the way they do it looks totally

130
00:05:58,760 --> 00:06:00,120
different. 
But functionally, they're 

131
00:06:00,120 --> 00:06:01,640
duplicates. 
You only need one. 

132
00:06:01,640 --> 00:06:03,880
Precisely. 
That underlying duplication is 

133
00:06:03,880 --> 00:06:06,480
still there, just hidden much 
better in type 4. 

134
00:06:06,560 --> 00:06:09,080
And this isn't just theoretical 
academic stuff, is it? 

135
00:06:09,120 --> 00:06:11,160
The source mentioned a study. 
That's right, It's very 

136
00:06:11,160 --> 00:06:13,920
practical. 
Back in 2013, researchers 

137
00:06:13,920 --> 00:06:17,680
Yamasita and Moonen surveyed. 
I think it's 85 developers. 

138
00:06:18,040 --> 00:06:20,080
They asked them about their 
biggest headaches, their main 

139
00:06:20,080 --> 00:06:24,680
concerns with code smells, and 
duplicated code was by far the 

140
00:06:24,680 --> 00:06:26,960
top answer. 
It scored almost double the 

141
00:06:26,960 --> 00:06:30,280
points of the next one down the 
list, which was long method. 

142
00:06:30,560 --> 00:06:34,160
So that really highlights how 
much duplication impacts 

143
00:06:34,160 --> 00:06:36,560
developers in their actual 
day-to-day work. 

144
00:06:36,680 --> 00:06:39,640
It's a real pain point. 
OK, so that brings us neatly to 

145
00:06:39,640 --> 00:06:41,960
the second biggest concern, long
method. 

146
00:06:42,680 --> 00:06:44,280
What exactly makes a method 
long? 

147
00:06:44,360 --> 00:06:48,120
An why is that a problem? 
Well, ideally methods should be 

148
00:06:48,120 --> 00:06:50,320
short and sweet. 
They should have names that 

149
00:06:50,320 --> 00:06:53,640
clearly explain what they do and
contain, you know, relatively 

150
00:06:53,640 --> 00:06:56,760
few lines of code. 
A long method is a smell because

151
00:06:56,960 --> 00:06:58,280
honestly, it just makes life 
difficult. 

152
00:06:58,280 --> 00:07:00,600
It becomes really hard to 
understand the whole thing, to 

153
00:07:00,600 --> 00:07:02,240
follow the logic from start to 
finish. 

154
00:07:02,240 --> 00:07:04,000
Cognitive Overload. 
Exactly. 

155
00:07:04,360 --> 00:07:06,560
Trying to maintain it without 
accidentally breaking something 

156
00:07:06,560 --> 00:07:09,280
becomes a challenge. 
Debugging can turn into a real 

157
00:07:09,280 --> 00:07:12,480
slog because you're juggling too
many steps and variables in your

158
00:07:12,480 --> 00:07:15,400
head. 
The usual fix, again, is extract

159
00:07:15,400 --> 00:07:16,760
method. 
Break it down. 

160
00:07:17,200 --> 00:07:21,200
Carve out smaller, more focused 
pieces, each doing just one 

161
00:07:21,200 --> 00:07:23,960
thing well. 
Is there a specific number of 

162
00:07:23,960 --> 00:07:26,680
lines? 
Like a hard rule over 50 lines 

163
00:07:26,680 --> 00:07:28,560
maybe? 
Not really. 

164
00:07:28,560 --> 00:07:30,920
Not an arbitrary number. 
There's no universal magic 

165
00:07:30,920 --> 00:07:32,960
number that says this is too 
long. 

166
00:07:33,120 --> 00:07:35,840
What counts as long can depend 
on the language you're using, 

167
00:07:35,840 --> 00:07:38,520
how important the method is, the
complexity of the problem it's 

168
00:07:38,520 --> 00:07:40,680
solving, things like that. 
Context matters. 

169
00:07:40,760 --> 00:07:43,120
It does. 
However, there is a strong trend

170
00:07:43,120 --> 00:07:45,840
in the industry these days 
towards writing very small 

171
00:07:45,840 --> 00:07:47,880
methods. 
Often you know fewer than 20 

172
00:07:47,880 --> 00:07:51,080
lines, sometimes even less. 
The goal is really clarity and 

173
00:07:51,080 --> 00:07:54,080
making sure each method has a 
single well defined 

174
00:07:54,080 --> 00:07:55,640
responsibility. 
Right, that single 

175
00:07:55,640 --> 00:07:57,240
responsibility idea keeps coming
up. 

176
00:07:57,480 --> 00:08:00,080
If methods can be too long, I 
guess classes can too. 

177
00:08:00,480 --> 00:08:04,560
That leads us to large class. 
Precisely same principle, just 

178
00:08:04,560 --> 00:08:07,960
scaled up. 
Classes like methods shouldn't 

179
00:08:07,960 --> 00:08:11,800
try to do too many things. 
A large class is a smell when it

180
00:08:11,800 --> 00:08:14,800
takes on too many different 
responsibilities or offers 

181
00:08:14,800 --> 00:08:16,760
services that aren't really 
related to each other. 

182
00:08:16,760 --> 00:08:18,280
Lacks cohesion. 
Exactly. 

183
00:08:18,280 --> 00:08:20,760
Low cohesion. 
This makes the class hard to 

184
00:08:20,760 --> 00:08:23,840
understand, hard to maintain, 
and especially hard to reuse. 

185
00:08:24,480 --> 00:08:27,760
If a class does 20 different 
things, you probably only need 

186
00:08:27,760 --> 00:08:30,360
three of those things in another
part of your system, but you 

187
00:08:30,360 --> 00:08:32,039
have to drag the whole behemoth 
along. 

188
00:08:32,320 --> 00:08:35,559
Often you'll see these large 
classes have tons of attributes 

189
00:08:35,799 --> 00:08:38,880
data fields that don't really 
belong together conceptually. 

190
00:08:38,880 --> 00:08:41,919
And the fix for that kind of, 
well, class bloat? 

191
00:08:42,159 --> 00:08:44,080
The main approach is extract 
class. 

192
00:08:44,520 --> 00:08:46,880
You look for a group of 
responsibilities or a set of 

193
00:08:46,880 --> 00:08:50,000
related data within the large 
class and you pull that out into

194
00:08:50,000 --> 00:08:52,080
a new, smaller, more focused 
class. 

195
00:08:52,600 --> 00:08:54,840
The original large class then 
just holds a reference and 

196
00:08:54,840 --> 00:08:58,480
attribute of this new smaller 
class type and delegates work to

197
00:08:58,480 --> 00:08:59,480
it. 
OK, delegation. 

198
00:08:59,600 --> 00:09:02,360
Yeah, and sometimes these 
classes get so big they start 

199
00:09:02,360 --> 00:09:04,160
doing almost everything in a 
part of the system. 

200
00:09:04,160 --> 00:09:07,680
They become the central brain. 
These get a special rather 

201
00:09:07,680 --> 00:09:11,080
negative name, the God class or 
sometimes a BLOB. 

202
00:09:11,520 --> 00:09:14,800
You often spot them by their 
very generic names, like System 

203
00:09:14,800 --> 00:09:18,200
manager or main controller or 
something equally vague. 

204
00:09:18,280 --> 00:09:21,960
God class, I like that. 
OK, next smell feature Envy. 

205
00:09:22,680 --> 00:09:24,640
That name is pretty evocative. 
What's going on there? 

206
00:09:24,720 --> 00:09:27,760
It is a great name, isn't it? 
Feature envy happens when a 

207
00:09:27,760 --> 00:09:30,840
method inside one class seems 
more interested in the data and 

208
00:09:30,840 --> 00:09:32,680
methods of another class than 
its own. 

209
00:09:33,440 --> 00:09:36,200
Basically, it spends most of its
time calling methods or 

210
00:09:36,200 --> 00:09:38,640
accessing data on an object of a
different class. 

211
00:09:39,000 --> 00:09:41,000
It envies the features of that 
other class. 

212
00:09:41,000 --> 00:09:43,720
So it's like a method that's in 
the wrong place. 

213
00:09:43,720 --> 00:09:46,040
It should belong to the class 
it's constantly interacting 

214
00:09:46,040 --> 00:09:47,400
with. 
That's exactly it. 

215
00:09:47,920 --> 00:09:50,160
It suggests the method is 
misplaced. 

216
00:09:50,480 --> 00:09:53,440
If you see this, the common 
refactoring is move method. 

217
00:09:53,760 --> 00:09:56,200
You literally move the method 
over to the class. 

218
00:09:56,200 --> 00:09:59,560
It seems to envy the one whose 
data it uses so much. 

219
00:10:00,080 --> 00:10:03,800
The source gives an example of a
method that calls lots of 

220
00:10:03,800 --> 00:10:06,720
functions on an object called 
App It, which comes from another

221
00:10:06,720 --> 00:10:09,280
class, but barely uses anything 
from its own class. 

222
00:10:09,280 --> 00:10:11,600
Clear sign, yeah. 
A very clear sign that the 

223
00:10:11,600 --> 00:10:14,480
method probably belongs in the 
class where AP comes from, which

224
00:10:14,480 --> 00:10:16,120
was abstract tool in that 
example. 

225
00:10:16,520 --> 00:10:19,040
Moving it improves the overall 
design and makes 

226
00:10:19,040 --> 00:10:22,880
responsibilities clearer. 
OK, shifting gears from location

227
00:10:22,880 --> 00:10:25,880
to inputs, we've got long 
parameters list. 

228
00:10:26,320 --> 00:10:28,720
Why is having too many 
parameters to a method 

229
00:10:28,720 --> 00:10:30,440
considered a smell? 
Right. 

230
00:10:30,520 --> 00:10:33,160
Methods ideally should have very
few parameters. 

231
00:10:33,160 --> 00:10:36,160
A long list makes the method 
signature complicated and harder

232
00:10:36,160 --> 00:10:38,520
to use correctly. 
When you call it, it also often 

233
00:10:38,520 --> 00:10:40,640
indicates the method might be 
trying to take on too much 

234
00:10:40,640 --> 00:10:42,960
responsibility itself. 
It needs a lot of information 

235
00:10:42,960 --> 00:10:44,360
because it's doing too many 
things. 

236
00:10:44,440 --> 00:10:46,200
Makes sense? 
What are the solutions? 

237
00:10:46,360 --> 00:10:47,760
There are two main things to 
look for. 

238
00:10:48,320 --> 00:10:51,560
First, can the method figure out
one of the parameters itself? 

239
00:10:51,560 --> 00:10:54,240
For example, if you're passing 
in parameter P1 and parameter 

240
00:10:54,240 --> 00:10:58,360
P2, but inside the method you 
could always calculate P2 just 

241
00:10:58,360 --> 00:11:02,200
by using P1, then you don't 
actually need to pass P2 in the 

242
00:11:02,200 --> 00:11:03,640
method, can derive it 
internally. 

243
00:11:04,000 --> 00:11:07,440
That simplifies the call. 
OK, eliminate redundant inputs. 

244
00:11:07,440 --> 00:11:10,920
What's the second approach? 
The other, often more powerful 

245
00:11:10,920 --> 00:11:14,320
solution is to group related 
parameters together into a new 

246
00:11:14,320 --> 00:11:17,280
object or class. 
Like instead of having a method 

247
00:11:17,280 --> 00:11:20,480
like process dates, date start 
date and date string format, 

248
00:11:20,480 --> 00:11:23,840
maybe you can create a date 
range class that holds the start

249
00:11:23,840 --> 00:11:27,160
and end dates and then the 
method just takes a single date 

250
00:11:27,160 --> 00:11:28,760
range object. 
Maybe like process date range, 

251
00:11:28,760 --> 00:11:31,280
date range range string format. 
It cleans up the signature, 

252
00:11:31,560 --> 00:11:34,480
makes the code more readable, 
and often bundles related data 

253
00:11:34,480 --> 00:11:36,600
with behavior too. 
That makes a lot of sense. 

254
00:11:36,640 --> 00:11:38,720
OK, let's talk about global 
variables. 

255
00:11:39,120 --> 00:11:41,480
I've definitely heard 
programmers warn against using 

256
00:11:41,480 --> 00:11:44,480
those. 
Why does the source list them as

257
00:11:44,480 --> 00:11:47,360
a code smell? 
Yes, global variables are 

258
00:11:47,360 --> 00:11:48,960
generally considered 
problematic. 

259
00:11:49,720 --> 00:11:52,600
The main issue is that they 
create a really bad kind of 

260
00:11:52,600 --> 00:11:55,040
dependency, sometimes called 
common coupling. 

261
00:11:55,720 --> 00:11:58,320
They make it incredibly hard to 
understand what a function or 

262
00:11:58,320 --> 00:12:01,080
method actually does just by 
looking at it. 

263
00:12:01,360 --> 00:12:04,120
Its behavior can depend on this 
global value that could be 

264
00:12:04,120 --> 00:12:07,080
changed by any other part of the
program at any time. 

265
00:12:07,160 --> 00:12:09,440
So hidden dependencies 
everywhere. 

266
00:12:09,440 --> 00:12:12,040
Exactly. 
Imagine a function calculating 

267
00:12:12,040 --> 00:12:15,320
something and at the end it adds
the value of a global variable 

268
00:12:15,320 --> 00:12:17,480
counter. 
To know what that function will 

269
00:12:17,480 --> 00:12:21,240
return, you can't just read the 
functions code, you have to know

270
00:12:21,240 --> 00:12:23,640
the current value of counter 
which could have been set or 

271
00:12:23,640 --> 00:12:27,400
modified by completely unrelated
code somewhere else entirely. 

272
00:12:27,800 --> 00:12:30,760
This makes reasoning about the 
code extremely difficult and 

273
00:12:30,760 --> 00:12:33,520
debunking a nightmare. 
A bug might appear in one 

274
00:12:33,520 --> 00:12:36,640
function, but the actual cause 
could be some distant piece of 

275
00:12:36,640 --> 00:12:38,600
code messing with that global 
variable. 

276
00:12:38,720 --> 00:12:40,440
That sounds fragile. 
Very. 

277
00:12:40,920 --> 00:12:43,200
It creates spooky action at a 
distance. 

278
00:12:43,840 --> 00:12:47,080
And it's worth pointing out, in 
languages like Java, static 

279
00:12:47,080 --> 00:12:50,200
attributes behave essentially 
like global variables within 

280
00:12:50,200 --> 00:12:53,000
their scope, so they carry the 
same risks and are also 

281
00:12:53,000 --> 00:12:54,800
considered this smell. 
Good point. 

282
00:12:55,440 --> 00:12:58,040
OK, finally let's tackle 
primitive obsession. 

283
00:12:58,400 --> 00:13:00,840
This sounds like maybe using the
basic building blocks like 

284
00:13:00,840 --> 00:13:03,920
numbers and strings too much. 
That's a great way to think 

285
00:13:03,920 --> 00:13:06,400
about it, actually. 
Yes, Primitive obsession is when

286
00:13:06,400 --> 00:13:09,240
we rely too heavily on these 
fundamental primitive types. 

287
00:13:09,560 --> 00:13:13,600
Integers, strings, booleans, 
floats instead of creating small

288
00:13:13,600 --> 00:13:17,000
dedicated classes to represent 
concepts from our problem 

289
00:13:17,000 --> 00:13:18,880
domain. 
Can you give an example of that?

290
00:13:19,040 --> 00:13:22,160
Sure, let's say you need to 
handle a zip code in an address.

291
00:13:22,520 --> 00:13:25,640
The quick and dirty way is just 
to use a string variable, store 

292
00:13:25,640 --> 00:13:27,240
it as text. 
Seems simple enough. 

293
00:13:27,360 --> 00:13:30,640
It seems simple, but the source 
suggests and it's good practice 

294
00:13:30,840 --> 00:13:33,560
to create a dedicated zip code 
class instead. 

295
00:13:34,080 --> 00:13:36,480
Why? 
Well, the main benefit is that 

296
00:13:36,480 --> 00:13:40,280
this dedicated class can hold 
not just the data the I code 

297
00:13:40,280 --> 00:13:43,320
string itself, but also the 
behavior associated with it. 

298
00:13:43,920 --> 00:13:46,840
For instance, the I code class 
constructor could automatically 

299
00:13:46,840 --> 00:13:50,600
validate the format. 
Is it 5 digits or 9 digits with 

300
00:13:50,600 --> 00:13:52,480
a hyphen? 
Does it match known valid 

301
00:13:52,480 --> 00:13:54,040
ranges? 
It can handle that logic 

302
00:13:54,040 --> 00:13:56,120
internally. 
So you encapsulate the rules 

303
00:13:56,120 --> 00:13:57,560
with the data. 
Precisely. 

304
00:13:57,560 --> 00:13:59,160
You encapsulate that 
responsibility. 

305
00:13:59,400 --> 00:14:01,320
Now, other parts of your code 
don't need to worry about 

306
00:14:01,320 --> 00:14:04,920
validating ZIP codes, they just 
use the ZIP code object, 

307
00:14:04,920 --> 00:14:07,840
trusting it's valid. 
It makes the code cleaner, safer

308
00:14:07,840 --> 00:14:09,520
because of type checking, and 
more expressive. 

309
00:14:10,080 --> 00:14:12,840
You're dealing with AZIP code, 
not just some arbitrary string, 

310
00:14:13,400 --> 00:14:15,480
so the idea is don't be obsessed
with primitives. 

311
00:14:15,640 --> 00:14:18,480
Elevate these simple values into
more meaningful objects when 

312
00:14:18,480 --> 00:14:20,800
they represent a distinct 
concept in your domain. 

313
00:14:20,960 --> 00:14:24,720
And that wraps up our deep dive 
into the, well, sometimes 

314
00:14:24,720 --> 00:14:27,960
fragrant world of code smells. 
We hope this is giving you a 

315
00:14:27,960 --> 00:14:31,640
much clearer picture of what 
makes code smell, so to speak, 

316
00:14:31,920 --> 00:14:34,520
and why spotting these 
indicators is really quite 

317
00:14:34,520 --> 00:14:37,560
crucial for building software 
that's robust and, importantly, 

318
00:14:37,560 --> 00:14:40,000
maintainable overtime. 
It's all about that underlying 

319
00:14:40,000 --> 00:14:41,960
quality. 
Thank you for joining us on this

320
00:14:41,960 --> 00:14:42,880
exploration today.