To keep code elegant and readable, this lesson presents a refactoring technique consisting of two rules: (1) Don't have empty lines in a function, (2) keep the function short, with at most 6 or 8 statements. See how this can help keep each function focused on one responsibility.


Refactoring tip: no empty lines inside a function

[00:00] I want to share with you today a refactoring technique in JavaScript, to keep your code clean and elegant. It consists of two rules. The first one is, don't have any empty lines in a function.

[00:11] It's quite common in JavaScript. Sometimes you have an empty line here in between statements, to separate this part from the rest. The rule that I try to follow is to never have any of this type of lines.

[00:23] The second rule is to keep functions short, with at most six statements or lines of code. Usually in a function that has a lot of statements you feel like putting this space here, to separate these parts. This is really common, but the technique I follow is that I never put these empty lines. Then what you may think is that it gets quite nasty, once you have a lot of statements, right?

[00:50] For instance in this function here, animate, it has a lot of statements. If you take a look here, it has 40 lines of code, so it's pretty large. It has no spaces, empty lines in between. It gets quite nasty. As you can see, it's quite nasty.

[01:06] What I do instead, is I try to refactor this animate function to be really small. We can do that by moving some of these parts away.

[01:14] For instance, I can move this one away. We're going to put that in a function. We're going to call it determineDeltaPoints, which takes this argument. I'm going to return that, and then I can call that function here.

[01:30] This is, by the way, RxJS code. I'm just going to call that like this, and then I can move this part out as well. I can name it as expandAsRenderingFrames, and then I can call it as well.

[01:58] There's this big scan here which I can also move, and I can put it somewhere else. Let's put it in a function called, calculateAnimationSteps. It takes an accumulator, and a current point.

[02:14] Actually it takes...no. It takes a point stream. Put in all of the scan inside that, and then I also call that function as well.

[02:29] There you can see now animate is a really small function. It has only these steps, and it's really readable. It doesn't have any spaces, any empty line in between, because it's really short. If it's short, then it doesn't need any empty lines.

[02:46] That's the general approach that I follow in. As you can see, we made some other functions here. You could even decide maybe to put this one in a function, and then you would make the determineDeltaPoints even shorter.

[02:59] Of course, this one is also quite huge. It doesn't have empty lines in between, so we can also refactor this one if you want.

[03:09] We can get this, and we can move it somewhere else. Let's call this one incorporateNewpoint, with an accumulator and a current point. I'm going to return this new accumulator, and then you can call that from here. You could also ask yourself, "Is this function quite short?" Or do you feel like putting an empty space?

[03:41] The idea is that if you feel like putting an empty space, then it probably means you should make this function even shorter by refactoring or splitting it in another function. As you can see here as well, this is another part that we can take out. I'm going to call this function progressEachPoint, takes an old accumulator and a new accumulator.

[04:06] It returns this progressedAccumulator, and then I'm going to call that function here. Now as you can see, this calculateAnimationSteps with this scan operation is much more smaller, much shorter. I don't really feel like putting an empty line here. Maybe I could even extract this one as a function.

[04:32] The idea is that if you feel like putting an empty line in between statements, then probably what you need is just to split that function in more functions. I've been following these two rules, and they've been really helpful for me to keep all of my functions quite short.

[04:50] They have just one responsibility, and they have only one level of abstraction. I've been quite happy as a JavaScript developer with this technique.

Refactoring tip: no empty lines inside a function

Share this video with your friends

Free Community Resource