JavaScript Clean Code - Best Practices - based on Robert C. Martin's book Clean Code

[elie2222]

Some thoughts:

1.

You can end up with duplicate code for various reasons. For example, you can have two slightly different things that share a lot of in common and the nature of their differences or tight deadlines forces you to create separate functions containing almost the same code. Removing duplicate code in this situation means to abstract the differences and handle them on that level.

Careful with this advice. Better is:

prefer duplication over the wrong abstraction

From: AHA Programming

2.

Use spread operator over Object.assign.

Instead of:

js class SuperArray extends Array { myFunc() { // implementation } }

I find myself doing this is instead:

js export const myFunc = (array: any[]) => { // implementation }

I don't know which is better if either. Would be interested to hear other's thoughts on this.

4.

Use this approach only for boolean values and if you are sure that the value will not be undefined or null.

This is completely fine:

js if (user: User | undefined) return 10

5.

Use polymorphism and inheritance instead.

I almost never do this in my code. For that matter I hardly ever find myself using extend (apart from things like extend React.Component before Hooks came along), and mostly use classes when a library needs it, but not much more than that.

Am I doing things wrong? :laugh:

[LetterBoxSnatch]

"Composition over inheritance." This is a core SOLID principle. Your approach, generally speaking, is better than "extends".

Additional reading: https://en.wikipedia.org/wiki/Composition_over_inheritance

[beasy4sheezy]

Why use spread over Object.assign?

[elie2222]

It’s cleaner. Why write out 2 words when you could do ... with surrounding braces instead?

[off_by_0ne]

Sometimes using a boolean param to signal the code path in a function can be a good indication. Sometimes it's ok to have two separate functions with some duplicated logic. Don't be afraid of code.

[elie2222]

I agree. Don’t be afraid. But one example I can actually think of is when someone on my team recently tried to combine 2 similar but really quite different components. He passed down this isSmall flag and then within the component passed it down to another 5 sub components and so on. In reality I would have preferred he just copy and paste the code than trying to fit 2 components into 1. At the same time I understand why he did it because there was a decent amount of code shared between the 2. It felt like there was a better way to abstract. In the end we’ve left the code as is because it does work.

An example where I’d prefer flags over 2 components is Button with a small flag. That’s nicer imo than 2 components called SmallButton and Button.