I'm of the belief that each challenge should try to get across a single concept. I don't feel your users are familiar enough with scoping and the behaviour of named function expressions. And moreover, it's not relevant to the lesson we are attempting to teach, and I feel it distracts from it a little.
For reference, here is the code:
const sum = (function() {
"use strict";
return function sum(x, y, z) {
const args = [ x, y, z ];
return args.reduce((a, b) => a + b, 0);
};
})();
I assume the use of assigning the arguments to a single identifier and then using it for the reduction is so that it's significantly easier to replace (x, y, z) with (...args) and it will then Just Work. This is great, and really useful for teaching.
Yet, the code could (and should!) be:
function sum(x, y, z) {
"use strict";
const args = [ x, y, z ];
return args.reduce((a, b) => a + b, 0);
}
This preserves the same behaviour of ease of transformation.
(If you really must avoid the hoisting behaviour of the use of a function declaration, this can be done).
I propose we change the default snippet to the above.
For reference, here is a thread in which conversion to arrow notation was attempted, and it was noted that it wasn't as easy as if it would be had the function been written as above.
When viewing the default code that the editor is initialised with for the ES6: Use the rest operator with function parameters, it appears to be too confusing.
I'm of the belief that each challenge should try to get across a single concept. I don't feel your users are familiar enough with scoping and the behaviour of named function expressions. And moreover, it's not relevant to the lesson we are attempting to teach, and I feel it distracts from it a little.
For reference, here is the code:
I assume the use of assigning the arguments to a single identifier and then using it for the reduction is so that it's significantly easier to replace
(x, y, z)
with(...args)
and it will then Just Work. This is great, and really useful for teaching.Yet, the code could (and should!) be:
This preserves the same behaviour of ease of transformation.
(If you really must avoid the hoisting behaviour of the use of a function declaration, this can be done).
I propose we change the default snippet to the above.
For reference, here is a thread in which conversion to arrow notation was attempted, and it was noted that it wasn't as easy as if it would be had the function been written as above.
Thoughts are welcome.