Cleaning up our JavaScript code is easy with default parameters and property shorthands.
In this article, we’ll look at the best practices when designing functions, including the ideal length and the number of parameters it should take.
Use Opposites Precisely
If 2 functions do opposite things, then they should be named precisely
For instance, if we have 2 functions to increment and decrement and number respectively, then they should be named as such.
They should be named increment and decrement to describe what they do.
How Long Can a Function Be?
Function length are inversely correlated to the number of errors per line of code according to Basili and Perricone study.
Another study from Shen et. al. mentioned that function size isn’t correlated with errors per line.
But structural complexity and amount of data were correlated with errors.
We should just let functions grow into their size organically. And we should only put operations together if they must be put together.
However, if a function is longer than 200 lines, then we should think we can break them up into smaller functions.
This is because if it’s longer than 200 lines, then a function would be harder to understand for most people.
Function Parameters
When we’re adding parameters into a function, we should take into account some guidelines so that we make them easier to understand and avoid mistakes.
If Several Function Use Similar Parameters, Put the Similar Parameters in a Consistent Order
If we have multiple functions that have similar parameters, then we should put them in the same order in each function.
For instance, instead of writing:
const calcVolume = (length, width, height) => {
//...
}
const calcArea = (width, length) => {
//...
}
We should write:
const calcVolume = (length, width, height) => {
//...
}
const calcArea = (length, width) => {
//...
}
This way, we won’t be confused about the order of the parameters when we pass them in.
Use All the Parameters
We should use all parameters that are in the function signature. If it isn’t used often, then we should take them out.
Unused parameters cause more errors since there’s more to think about.
Put Status or Error Variables Last
If we have status or error variables, then we should put them last since they’re output only.
For instance, we write:
const callback = (res, err) => {
//...
}
err is output only, so it should go last.
Don’t Use Function Parameters as Working Variables
We shouldn’t mutate parameters. This way, we won’t be accidentally modifying the value outside if it’s passed by reference.
For instance, we shouldn’t have code like:
const fn = (input) => {
input++;
//...
}
Instead, we write:
const fn = (input) => {
let count = input;
count++;
//...
}
Always assign it to a variable and then apply operations to that instead.
Limit the Number of a Function’s Parameters to About 7
The fewer parameters we have in our code the better.
It’s easier to read and harder for us to make mistakes passing them in.
If we have a dozen parameters, then anyone would get confused with the order of the parameters and the data type of each.
This is worse since JavaScript doesn’t provide any data type checking built-in at compile time.
Use Named Parameters
We can mimic named parameters by using objects as parameters and the destructuring syntax.
For instance, we can write:
const calcArea = ({
length,
width
}) => {
return length * width;
}
calcArea({
length: 1,
width: 2
});
Then we don’t have to worry about the order that length and width are passed in and we can see what we passed in for each parameter.
Conclusion
There’re a few things to consider when we’re defining functions.
The lengthy matters since we don’t want functions that are so long that they’re hard to understand.
Also, we want to reduce the number of parameters in our function to reduce the chance of mistakes.
We also want to destructure object parameters to mimic named parameters so that we can see the name of the property we pass in.
