What's the value of the length field for JavaScript functions? What will be logged to the console?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A lot of JavaScript entities have the length field.
For example, it holds the total number of element in JavaScript arrays.
const arr = ['a', 'b', 'c'];
console.log(arr.length); // 3
For strings — it’s the number of characters. Literally, the length of a string.
const welcomeMessage = 'Hello!';
const goodbyeMessage = 'Goodbye!';
const emptyString = '';
console.log(welcomeMessage.length); // 6
console.log(goodbyeMessage.length); // 8
console.log(emptyString.length); // 0
Regular objects don’t have the length field by default.
const user = { name: 'Jack', age: '32'};
console.log(user.length); // undefined
But the functions do have it! And it holds not the "length of a function", which is hard to define, but rather the number of function parameters.
const sum = (a, b) => a + b;
const log = (s) => console.log(s);
const noop = () => {};
console.log(sum.length); // 2
console.log(log.length); // 1
console.log(noop.length); // 0
ANSWER: The length field holds the number of parameters for all JavaScript functions. Thus, the output is
1
0
As the function sayHello has one parameter and the function confirmSubscription has zero parameters.
Discussion (10)
Not denigrating the post at all. This is something that would come up in an interview potentially...but, why? What does this prove to anyone about someone's ability to write useful JS code that is clean, easy to follow, and adheres to best practices and architecture?
Again, not being negative about the article - this is probably an interview question. The question is just why it is?
As an interview question this would be ridiculous, but as a quirky fun fact it's great! But, an employer or a company who expects me to know something like this, and values this kind of knowledge, no I definitely don't want to work for that kind of employer.
You'd never be dumped just for not knowing this stuff. All knowledge is valuable.
And your reaction to the questions you don't know is a good indicator of how you'll tackle the difficulties on your job.
Well maybe, but some knowledge is arguably more valuable than others - I'm just saying that if an employer really attaches great importance to this sort of knowledge, then it's a red flag for me and I'd probably not want to work for that employer - it tells me something about their "culture". But, it does depend on the way they ask it, and on their intentions when asking it.
I absolutely agree. The "how" and "why" are just as important as "what".
There are millions of different interview styles. My goal with these posts is to help Junior devs uncover their weaknesses and be better prepared for their next interview.
Sorry, but I disagree. If you want to help junior developers with their weaknesses, then you'll be better off with articles about good configs for linters/formatters, efficient googling, how to create new projects, popular/on-demand libraries and frameworks, actual day to day issues and how to solve them (like scope, closure, hoisting, etc), and new stuff that might be useful (like new operators such as
??and?.).Nowadays nobody (not even a senior) wants to work for a company that has questions that you can google and are useless in a regular day of coding. Those question tell you nothing about the skills of the developer, other than if they memorized something just before the interview.
Don't get me wrong, some of the articles in your "Test your JavaScript skills" series are interesting as "curiosities" or "tips" about JS, and maybe there are a few actually useful for a junior. My concern is if this is actually taken seriously as something useful for "junior interviewing", which from my PoV is not.
Valid point.
I think the answer is
as opposed to
Thank you for noticing the error 🙏.
You're absolutely right.
I've fixed the typo.