10 Clean code examples (Javascript).

Myself, I would call most of these "less code" examples, not necessarily "clean code". Imo, clean code is legible code. A lot of these examples require the developer more mental fatigue. Some of these I do, but others I definitely avoid, especially #10.

When dealing with lots of zeros it's also possible to use underscore to separate ranks:

const num= 10_000_000;

short ≠ clean≠ readable

2 Instead of

a = { [c > d ? 'foo' : 'bar']: 'apple' };

it's better to split it into couple lines

const key = c > d ? 'foo' : 'bar';
const a = { [key]: 'apple' };

4 might be even cleaner

const { x: a, y: b } = foo;

6 seems overcomplicated, maybe something like

const [a, b, c, d] = ['a', 'b', 'c', 'd'].map(document.getElementById)

7 questionable, I'd say if construction is easier to understand, especially for juniors joining the project

8 use ?? instead of || - that way you'll not override 0 value

9 less known JS feature - you may use underscore to divide long numbers

const a = 1_000_000;
console.log(a); // 1000000

bonus just use a debugger or create an IDE snippet.

On looking deeper, I find that roughly half of these are plain wrong. It's not even a matter of opinion.

For number 2, this:

// BAD
c > d ? a.foo = 'apple' : a.bar = 'apple'

assigns 'apple' to foo or bar depending on the values of c and d. It leaves the other keys of a alone.

This:

// BAD
a = { [c > d ? 'foo' : 'bar']: 'apple' }

reassigns a (which means it is not a const), wiping out all previous key-value pairs. It's also pretty unreadable. Both mutate a.

They are not equivalent.

Better would be to use the spread operator:

// BETTER
const key = c > d ? 'foo' : 'bar'
const b = {
  ...a,
  [key]: 'apple'
}

Number 3 is just plain wrong. const must be assigned when it is declared, so the example cannot occur in real code. Smart code avoids let as much as possible, and if necessary strives to assign at the same time as it is declared. So an actual example would be more like:

// BAD
export const foo = 'some bit of text',
  bar = 'some more text',
  kip = 666

This is difficult to read (worse if you try to do it on one line). So much cleaner to write:

// BETTER
export const foo = 'some bit of text'
export const bar = 'some more text'
export const kip = 666

At a glance I can see exactly how many variables I've declared and assigned and that each is exported and each is not reassignable.

Shorter or terser is not the same thing as cleaner, more intuitive, or more readable. Sometimes duplication is better.

Number 4 is needlessly verbose and difficult to read. This:

// BAD
const { ['x']: a, ['y']: b } = foo

Should be this:

// BETTER
const { x: a, y: b } = foo

Number 5 is OK, but number 6 is pointlessly mutable. Why? Instead of this:

// BAD
const elements = {};
['a', 'b', 'c', 'd'].forEach(item => elements = { 
  ...elements, 
  [item]: document.getElementById(item) 
});
const { a, b, c, d } = elements;

Do this:

// BETTER
const [a, b, c, d] =
  ['a', 'b', 'c', 'd'].map(id => document.getElementById(id))

The variables are positional, so no reason their names have to match the IDs. You can make them better. You need better variable (and ID) names in general. These are terrible examples.

Number 7: instead of this:

// BAD
foo && doSomething()

But the full if statement is more obviously a guard and more scannable. Don't make terseness the enemy of readability.

// BEST
if (foo) {
  doSomething()
}

Number 8 is OK, but number 9 needs work. Who can read this?

// BAD
const SALARY = 15e7,
TAX = 15e6

How many people can do the math in their head? Few, I bet. But use the underscore and both the magnitude and the difference in magnitudes become clear:

// BETTER
const SALARY = 150_000_000
const TAX = 15_000_000

Re number 10, assigning the value of one variable to another is generally something to avoid as it's not clear what you're assigning (unless you've named the variables very well). But even if you're assigning, say, a string, it is better to stack them. This:

// BAD
a = b = c = 'some text

Is easily missed and takes a moment to parse. And you probably have to keep reminding yourself that a, b, and c have the same value. (Why on Earth would you need 3 variables with identical values -- unless you're mutating them, which... just don't.)

Much better:

// BETTER
const duplicateA = 'some text'
const duplicateB = 'some text'
const duplicateC = 'some text'

The bonus is half a good idea, and half a bad one. Instead of this:

// BAD
const { ['log']: c } = console
c("something")

Do this:

// BETTER
const log = console.log

log('something)

Now you know what it's doing.

I guess posts like this spur discussion, but for the unwary newbie they are strewn with land mines, doing them a disservice. So BEGINNERS BEWARE! Much of what you read online is written by people who haven't really done their homework. Don't let their mistakes be yours.

I think these are great easter eggs one might use for code golf. The fact Javascript can do these things is probably worthwhile knowing to be more comfortable with the language.

However most of these are trick shot one liners that I'd probably point out as being too fiddly if I saw them in a code review.

Snippet 2 took me long enough to understand what was going on that I'd probably just flag it without going any further to even check if the logic was correct. However the assignment within the ternary (the example of "wrong" code) is also the type of thing I'd consider overly complicated. A nice, clear if statement would've been fine.

Snippet 8 is another where I would far prefer to read the first, "wrong" example and would understand it straight away.

Snippet 6 has been mentioned several times, but the "correct" example is not only more complicated, but actually far less efficient. The "wrong" example does 4 simple assignments, the Javascript engine will be able to optimise these 4 lines really easily. Your "correct" code:

• creates a new object
• creates a new array object
• iterates over that new array with a new function
• spreads and reassigns the object every time into yet another new object
• finally dumps the object, assigning the values to the local scope

The Javascript engine uses more CPU cycles running it and has to allocate more memory to store all that extra state, and even worse, the garbage collector now has a whole mess to clean up afterwards that doesn't get used ever again.

Just to balance things out, #7, #9 and your bonus tip are genuinely useful shortcuts, that make things easier to read and work with, and I use all three in everyday development. Great things to point out!

I think the main takeaway is that clever tricks are fun to work out and discover, but they're rarely better than the simplest possible code. Also "Clean code" !== shortest code. In fact, it's often better to have 5 lines instead of one if it makes it clearer what's going on. After all, if I want my code smaller and shorter, I'll put it through a minifier and an uglifier before I ship it to production, and let the computers deal with the one liners!

Like it.

6 could be better by just creating the object directly. Its faster and better to read.

Also dont to 10. If u coding like that there is a good chance u get race conditions. Also by working with objects:

let a = b = c = {"a":"b"}
a.a = "p"

console.log(c)
// { a: "p" }

I think clean code is still a very debatable topic. To me, personally, clean code is code with improved readability or improved contextual information:

Example:

const g  = 9.81 // unclear
const GRAVITY_OF_EARTH = 9.81 // clear

Same goes for preparing structures for commenting code:

hard to read

if (condition) {
  // long block comments about 
  // what this branch actually does
  ...
} else {
  // long block comments about 
  // what this branch actually does
  ...
}

easier to read:

// long block comments about 
// what this branch actually does

if (condition) {
  ...
}

// long block comments about 
// what this branch actually does

else {
  ...
}

Number 4...?! what is going on there.. it should be as follows:

var foo = {x:1, y:2}
var {x:a, y:b} = foo
console.log(a,b)

Everything is fine, except 6. There is no need to create a new object, new array, loop over them and so on, this is neither clean, neither fast.

Full heartedly disagree with 7, not every developer knows JS specific code shortening syntax, but every developer knows an If statement, it honestly frustrates me when a developer goes out of their way to reduce code only for it to become less readable. Code readability trumps trying to reduce lines of code IMO