of fun fun function today we are going
to talk about the value of straight line
code over functions breaking in line
code out into a function is a very
powerful tool and because functions are
such a powerful tool they tend to be
used a lot in fact
I see people using them even when they
don’t have to and that actually lowers
the quality of your code and that is
what we are going to talk about today
what you are looking at here is some
code from an actual project that I was
involved with some naming has been
changed to protect the innocence and in
that process I did a mistake exactly
what this code does is not important but
what is important is that it’s a handles
a key press event I figures out a letter
here then it figures out what the scroll
container is that’s a bit of magic here
if it only has one small container it
grabs that scroll container and stuff
like that and if it finds the scroll
container it will find the parent of the
scroll container extract the URI from
that and if the URI is valid is going to
emit a letter jump request on e Central
Dispatch so intuitively it feels like I
should be doing something with this code
there are no comments and it’s just one
big function that does quite a bit of
things and that is what happened in this
project we felt that this is a contained
unit and this is one unit so they can
probably be broken out into two separate
functions like this
so this is the same on key press event
except that we have broken out the
scroll container block here into a
scroll container function it’s the same
thing except it’s inside a function and
we have also broken out the other logic
into a sort list letter jump and it’s in
here to me it feels like we are adding
value here it feels like we have added a
bit of documentation by naming these
blocks as functions it feels like we
have divided and conquered properly here
feels like we have broken the problem of
the onkeypress event into two things
getting a scroll container and the sword
is letter jump it also feels like we
have made the code more readable because
while we just get a scroll container and
then if we have a scroll container we do
the sort list
letter jump I mean this little bit of
code I mean this is a lot more readable
than this whole thing right it really
feels like we are doing a good thing
here but when you spend a little bit of
thinking about it it turns out that we
don’t let’s talk about the first feeling
that we had that functions feel like
you’re documenting the code looking at
the original code we have taken this
block here and in the variant with the
broken out function here we have given
it a name right get scroll container and
that feels like a good thing right we
have created that this part of the code
does this we have told the future
program or something right however are
we really adding something by making
this into a function
couldn’t we just do a comment something
yes the scroll and to this day something
like that I don’t know I often hear
programmers say that good code should be
soft documenting and you shouldn’t use
too many comments but when it comes down
to it a comment like this it’s really
the same thing as doing this the fact
that this is a function does not really
give you any kind of security you have
just essentially written a comment a lot
of people dislike comments like this
because they tend to go stale and buy
stale I mean like you might add some
code here that will do new things and
this description will no longer be
accurate but the thing is that you will
still have that problem with with a
function as well if I add new code here
that does things that does not fit into
the name of the function let’s hope the
documentation the comment the function
comment or whatever you like to call
this kind of pattern will still go stale
okay fine maybe it doesn’t add much in
terms of documentation but what about
dividing conquer by breaking get scroll
container out and breaking sort lists
letter jump out we have split the
problem into two parts and now we can
reason about them independently right
well not really
just because you’ve moved code from one
place to another doesn’t really mean
that you have separated the problem I
mean there are functions like that for
instance just look at two lowercase here
on like six taking a string and making
it lowercase that is a very well-defined
and generic problem that we would not
benefit from having in line
that would just confuse us however yet
scroll container is very specific to the
problem that we are solving here you
cannot go into get scroll container and
reason about this problem completely
independently from what is happening in
on keypress or the state of the
application in general you could do that
when you were writing to lowercase but
you can’t really do that with get scroll
container this is this is just an
illusion of separation this is not
actual separation of concerns you have
not actually decoupled these functions
from anything okay so maybe we haven’t
really broken the problem up but how do
we made it more readable I mean this is
so easy to follow it just gets the
scroll container and then if it has a
scroll container it does a sort least
little job well no not really
if another programmer is reading this
function it is because they are for some
reason trying to figure out what the
hell is happening it it is at such a
high abstraction level that it is
probably not going to be very useful to
them so they will have to dive into them
so the programmer would have to go in to
get scroll container and read here and
then we’ll we have to okay so there’s a
selector and they have to find out that
that selector comes from there okay it
returns scroll container then you have
to go back up here and then the scroll
contain okay it calls swordless leather
jump then I have to find that function
it’s down here and read here here here
here here here compare this to the
straight line function that we had
before the refactoring here we can
simply read the code from top to bottom
and see what happens
until the dispatch events is sent this
is much easier to reason about this
jumping back and forth thing there is
actually a word for that it’s called
indirection you might have heard it used
in the context of layers of indirection
and what indirection refers to in
computer science is that you refer to a
value by a reference instead of
referring to it immediately an example
would be the broken out functions that
we do here we refer to this code block
but it might also be variables such as
this selector here that we have broken
out and I think that personally
I mean selector is used in two instances
here but I feel like just two instances
of a variable is dubious to break out
because the person reading this will
have to jump back up and I think it
might actually be more readable and
maintainable code by just inline it it
might hurt you a bit that there is
duplication you know and duplication is
generally bad because it means that if
you have to change your system then you
have to change it in two places but with
such a replace in this case where it’s
just two instances it’s not that hard
really and we have gained a lot of
readability by doing this it’s a lot
easier code to follow if the selector
was used in ten different places across
the app and not just this function I
would really feel differently about it
but in this case I feel like duplication
is a lot better choice than the
indirection finally another subtle
problem that I would like to talk about
is the fact that breaking things out
into functions makes it a bit harder for
a developer to remove code from your
project and removing code is a very good
thing because as I’ve talked about
before less code in slash spots so what
do I mean when I say that it gets harder
to remove things well in this case I
just wrote to get scroll container it’s
easy to be it for me to reason about
this
and it’s very small but over time I will
forget on keypress will grow bigger and
new programmers might enter the project
and get scroll container will just be a
very small function call in this big
project now if anybody wants to change
code related to get scroll container
I mean remove the call or perhaps change
the logic inside of it they now have to
do an investigation to find out if other
pieces of code uses a get scroll
container don’t get me wrong here I’m
not saying that you should never break
things out into functions but you need
to be aware that there is a maintenance
cost to doing it so when you’re doing it
it needs to add a lot of value to offset
that cost so let’s recap a bit breaking
things out into functions like this is a
layer of indirection a layer of
indirection might be a bad thing or a
good thing in this case I would say that
it it’s a bad thing this this really
doesn’t add anything that’s not to say
that indirection is always bad sometimes
it’s very nice to have in directed code
such as to lowercase here it is very
nice not to have to think about the
implementation of lower casing at the
string when we are solving a completely
different problem and the reason that is
nice is because it’s a very small and
well-defined problem and also a very
general problem that is completely
separate from what we are trying to
solve at the moment that is different
from the get scroll container here which
is not at all generic not at all
well-defined and not at all small and
it’s definitely related to what we are
doing so we want that close at hand we
don’t want to indirect that if you
indirect something like get scroll
container that you have to reason about
the programmer that needs to reason and
understand your code
we’ll need to go up and down and back
and forth in your code and that’s bad so
the moral of the story is be a bit more
restrictive about adding layers of
indirection and this is important
because it will feel like you are adding
value regardless of whether or not you
are so make sure that you are
second-guessing your intuition today’s
video was inspired by a segment in a
talk by Jonathan Blow the developer of
grade so if you found this idea
intriguing you should check out that
talk I have linked it in the show
description I am the one doing the
talking here but it is your show so in
order to make a good show I need to know
who you are so kindly introduce yourself
in the comments below tell me what kind
of programmer you are today and how you
would like to improve you have just
watched an episode of fun fun function
fun for function is a weekly show where
we try to become more confident and
excited about programming by exploring
wild ideas all the wisdom and having fun
speaking of improving do not miss the
next episode subscribe down below or
follow me on twitter at MP Jamie until next Monday stay curious