Note that there are many rules in this section and some of them I will skip either because they are self explanatory or are thoroughly explained by Airbnb.
Section 7: Functions
7.1: Use named function expressions instead of function declarations.
What’s an Error Call Stack?
A [call stack][https://en.wikipedia.org/wiki/Call_stack] allows you to trace errors through your program. It will show you the path your program took through its code that led to the error. This makes finding complex bugs that involve code in several locations easier to fix.
7.5: Never name a parameter arguments. This will take precedence over the arguments object that is given to every function scope.
According to Mozilla
“The arguments object is a local variable available within all (non-arrow) functions. You can refer to a function’s arguments within the function by using the arguments object. This object contains an entry for each argument passed to the function, the first entry’s index starting at 0.”
Making one of your function’s parameters
arguments will overwrite the default
arguments and you won’t be able to use it.
7.7: Use default parameter syntax rather than mutating function arguments.
7.8: Avoid side effects with default parameters.
A side effect is when a function modifies something outside of its scope. In Airbnb’s example the function is modifying the variable b which is defined outside the function. This goes against the rule of encapsulation and can make your programs have strange behaviors and even stranger bugs.
7.10: Never use the Function constructor to create a new function.
I talked about why eval() is bad in the [strings][section 6] section. Just like with eval(), if you’re not careful, this could allow malicious users to insert and run their own code in your program. It’s best not use it at all so you don’t have to worry about this vulnerability.
7.14: Prefer the use of the spread operator … to call variadic functions.
What are variadic functions?
A variadic function is one that can accept different numbers of variables as arguments. This can give certain functions more flexibility and can make for more flexible and readable code.
7.15: Functions with multiline signatures, or invocations, should be indented just like every other multiline list in this guide: with each item on a line by itself, with a trailing comma on the last item.
When you have code that, when on a single line would be too long, you can usually spread them out to several lines to make them more manageable and easier to read. Although the examples given by Airbnb don’t seem easier to read them having them on a single line, imagine if each of the variables were several words long or involved function invocations. Things would quickly get out of hand.
Why Should I Care?
Functions are one of the most powerful tools a developer has. Everyone knows how to use them, but not every one knows how to use them properly. Proper use of functions will step up your programming game and make your code less error prone, easier to write, and easier to maintain.
Next Saturday I’ll explain arrow functions. If you enjoyed this post or just want to say hi, leave me a comment down below.