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

[🦁 Yvonnick FRIN]

Thank you John! What are your other favorite methods? I'm curious.

[John Oerter]

My second most used method is splitting up code into separate functions/methods. And in C# or other OOP languages, I make heavy use of interfaces and separate classes. I practice TDD, and this really helps me see where to split functionality for maximum readability.

Another trick I use quite often is moving conditional expressions into methods/functions. So instead of:

if (score === 10) {
  // do something with a strike
}

I prefer to say:

if (isStrike(score)) {
  // do something for strike
}

I think this really takes a mental load off when other developers are trying to understand the conditional. What about you?

[🦁 Yvonnick FRIN]

TDD really makes the difference. I think code don't need to be perfect. It only needs to follow a few statements:

• Single responsibility principle (It is related to what you said about splitting code into different functions)
• Avoid over engineering (I prefer copying a same code at least three times before thinking about making it generic)
• Keep code simple so beginners can understand it easily (I take care to avoid tricks like + before a variable to cast it in Number for example)

In my humble opinion following these help keeping a codebase maintainable 👌

[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!

[John Oerter]

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

[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".

[🦁 Yvonnick FRIN]

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.

[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.

[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.

[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.

[Yann Bertrand]

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

[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.

[Thomas Junkツ]

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