loading...

Discussion on: DevTips: Use early returns to avoid nested conditions

yannbertrand profile image
Yann Bertrand

Totally agree!

I also try to instantiate boolean variables instead of multiplying conditions inside an if statement.

const userIsLoggedIn = user.isLoggedIn()
const userCanComment = user.score > 10

if (userIsLoggedIn && userCanComment) {
  // Comment
}

The code speaks by itself!

Thread Thread
joerter profile image
John Oerter

Yes! It's so easy to do and is a huge win for readability

Thread Thread
stephenmirving profile image
Info Comment marked as low quality/non-constructive by the community. View code of conduct
Stephen Irving

If a professional JavaScript developer isn't aware that using the + operator before a string that represents a number will cast it to a number, and doesn't just look it up the first time they see it so that they understand it for all future times, then they shouldn't be a developer at all. Full stop. Thats not a "trick", it is a basic feature of the language and at the moment it is both the most performant and shortest way to cast a string to a number. Why would you choose an objectively worse method to do something just so if some idiot, who doesn't understand the language and is unwilling to learn anything new, comes along they will be more able to understand it. With all due respect, that is an absolutely ridiculous precept to follow.

It is also just wrong when you say "I copy code three times before I think about making it generic." Wrong, wrong, wrong. DRY is probably the number one precept of programming to follow that they teach you in every 101 level CS course. Not repeating yourself is not "over-engineering", it is a basic practice that every programmer should be following 100% of the time. Why wait til you've repeated yourself just three times? Why not 5? 10? 100? What is it about the number three that makes that the cut-off point where you decide you've repeated yourself enough? The common refrain isn't "Don't Repeat Yourself But It's OK If You Do So Three Times".

Thread Thread
yvonnickfrin profile image
🦁 Yvonnick FRIN Author

I don't like your tone. I find it really offensive for learning developers. Despite it I will answer for other people reading it.

In teams you find really different kinds of developers (beginners, seniors, lead, ...). The codebase isn't only for experts. I prefer having simple code that anyone can read regardless of their level on the language or framework used on the project. This is healthier for the project life in my humble opinion.

About the "rule" of three times. I prefer see a code used in different situation before make it generic so my conception is driven by real usage rather than planning every use case possible even if I don't need it at the end which is a common mistake I encounter.

You talk a lot patterns but they are just a way to handle problematics. They aren't always the solution. Sometimes a context need you to act differently for exemple on my current job I have to lead a team of beginners and help them learning JavaScript as we develop an app. I prefer making simple code everyone on the team understand rather than making the perfect code or follow every programming idioms.

Thread Thread
4ortytwo profile image
Arthur

I keep seeing seniors advising other devs to change jobs and forget the idea of them being real devs. It really needs to stop, people require time to learn and if you nurture you juniors properly, you'll have the strongest team ever. This guy sounds like the type of person who'd laugh in the face of someone who's made a mistake and put them down for this. Can't envy his colleagues unless it's a viper nest filled with the Elite just like him.

Thread Thread
thomasjunkos profile image
Thomas Junkツ

@Yann Bertrand

Although, I know you just posted your code as an example and although I know it is really nitpicky from me, but when looking at your code:

const userIsLoggedIn = user.isLoggedIn()
const userCanComment = user.score > 10

if (userIsLoggedIn && userCanComment) {
  // Comment
}

I see two things:

  • you have a method isLoggedIn() on user. From my POV user.isLoggedIn() is equivalent to userIsLoggedIn. This is no win.

  • userCanComment is really better than user.score > 10 which is really bad. But, why is this no method on the user too?

So you would end up with

if (user.isLoggedIn() && user.canComment()) {
  // Comment
}

and no extra variables needed.

Thread Thread
moopet profile image
Ben Sinclair

@stephenmirving

then they shouldn't be a developer at all

That's a really unhelpful thing to say.

Pretending it's not... I'm a professional developer who has used Javascript on and off since it was first released (though it's not my primary language by any means). I wouldn't use a hack like that, because I think it's awkward and likely to cause confusion or problems farther down the line.

There are prefectly valid ways to do things that don't sacrifice readability; when someone tries to refactor it out later on because it seemingly does nothing, they'll be at fault for introducing a bug. I say the original author introduced the bug, and would pick that up in a code review.

Thread Thread
yannbertrand profile image
Yann Bertrand

Agreed! I was not inspired, thanks for going further 🙂

Thread Thread
jouana profile image
Antoine Jouan

I am agreed with your improvement expect for adding predicate to user class.
This will break Single Reponsability principle.
I think it's better to make a class for predicate which will manage specification and one class for user which will manage user state.
So if you want to keep this syntax then you can set predicate as extension of user class but in js it's little tricky and not simple for beginner.

Thread Thread
thomasjunkos profile image
Thomas Junkツ

I do not quite understand. Starting with "classes". You could do that without classes at all. Plain objects will do.