I think I did the task wrong :)

Tell us what’s happening:
I removed strict and return, so code would look like in an example and it works just fine. Is my version correct? :slight_smile: It looks much shorter and simpler than the Hint version.

Your code so far


const createPerson = (name, age, gender) => 

// Only change code below this line
({name,age,gender});
// Only change code above this line


Your browser information:

User Agent is: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36.

Challenge: Write Concise Object Literal Declarations Using Object Property Shorthand

Link to the challenge:

Sure, what you did is perfectly find JS. Just be sure you understand why that still returns the correct object. You are just using the implicit return of the arrow function.

The code will work without the "use strict"; - it is just a way to tell the compiler to not let you do anything “sloppy” - which you aren’t. You could have moved it above the code.

It’s good to solve the problems the way they want, but once you’ve done that, messing around to see what else work is a great way to learn, too.

In terms of formatting, I think either:

const createPerson = (name, age, gender) => ({ name, age, gender });

or

const createPerson = (name, age, gender) => ({
 name, age, gender,
});

or even

const createPerson = (name, age, gender) => ({
  name,
  age,
  gender,
});

Would be more common. But they all do the same thing. I would probably prefer the first option I showed because it is so short. The thing I don’t really like about yours is that it has an implicit return without anything on the end of that line, after the implicit return, it starts on the next line. It just looks odd to me, especially because that would be a no-no with an explicit return. But it does work here.

Hey there,

in the end you have to decide depending on some variables:

  • who will read the code (beginner? expert?)
  • how well do you understand the code?
  • do you want to change the code later?

Example:

const createPerson = (name, age, gender) => 
({name,age,gender});

I want to add some logging:

const createPerson = (name, age, gender) => {
  console.log("something here");
  return {name,age,gender};
}

Lot of stuff to move around.

That’s why I mostly prefer this solution:

const createPerson = (name, age, gender) => {
  return {
    name,
    age,
    gender
  };
}
  • easier to understand for beginners, sometimes they don’t know about the implicit return
  • easier to add additional code above the return statement
  • easier to see the current object properties
  • easier to add additional object properties
  • but: more code

But this is your choice and there are pros and cons for every approach.

2 Likes

I don’t know, where I work that would get flagged. Actually, I think the linter flags this so it’s actually impossible to merge that. As to your points:

easier to understand for beginners, sometimes they don’t know about the implicit return

As a professional developer, I don’t write code for beginners - I work with professionals. If they don’t understand what the implicit return is, they don’t work here. And everything looks strange until you get used to it. And this is something that you will be seeing a lot.

easier to add additional code above the return statement

Yeah, that’s a slight pain, but very minor and rare.

easier to see the current object properties

I don’t understand, I can see them just fine in every example.

easier to add additional object properties

Again, I’m not seeing what is difficult about adding a property to any of the examples.

but: more code

Yeah, that’s a thing. When you’re working on a codebase of 110k lines with 40 other developers, keeping things tight can be a good thing. Obviously you can go too far. I’m all for taking up extra lines if it adds something to the code - readability is a big thing. But once you are used to arrow functions and implicit returns, they are no more difficult to read than regular functions - it’s just about familiarity. We shouldn’t use the readability argument to write extra code to appease people that haven’t become as comfortable with the language as they should.

When I first saw arrow functions they looked bat crap crazy and made no sense. Now they are second nature and I write almost no regular functions - generator functions being the exception. And it’s expected (actually the linter makes it “required”) to use the implicit return when it makes sense. I can’t speak to other work places, but that’s mine. And it makes sense to me.

1 Like

Totally valid points, Kevin.

My argumentation is based on the guess that the thread starter is not a professional and therefore doesn’t ask for best practices in an professional work environment.

I think a beginner should learn best practice for making progress in their learning and then slowly adapt to best practices for professional development.

I also think that “professional” isn’t contrary to “making ‘beginner’ mistakes”. I’ve seen bugs based on “oh, damn, I didn’t see this curly brackets”:

const works = () => ("works");
console.log(works()); // "works"

const bug = () => {("bug")};
console.log(bug()); // "undefined"

Some kind of this “beginner mistake” lead to postponing a demo day. Sure, our systems should have caught this one, but they didn’t. And this guy was +10y into this stuff, he only did a “beginner’s mistake”, probably because he was stressed and missed this tiny little thing.

That’s why I opt for the more explicit, more beginner-friendly code, especially as best practice for beginners.

Yeah, I understand what you’re saying. (But I would have expected a good linter and definitely unit tests to catch something like that mistake.)

I just encounter a lot of resistance to certain patterns. Often it’s from people that aren’t JS developers but think they are and either are scared by some ESNext or are trying to turn JS into Java. People unfamiliar with standard functions can screw that up too. As to arrow functions, it reminds me of a question I love to ask junior devs: What does the following function return?

() => {};

If they say “an empty object”, then I know we’re in for a bumpy ride.

2 Likes