I believe in the martial arts approach of mastery. first you learn the best practices and stick to them to the letter, till you master them. And after a while you get the feel of necessary patterns and bloating patterns.

As an example:

• design patterns are for humans not for machines and they are only there to compensate for flaws in the programming language
• Object orientation is for humans to break down complex communications inside of code-fragments which renders the communication into a tree.
• aesthetics of syntax is often chosen over aesthetic of functionality

The machine does not really care if the "jump to register" method is inside of a "reserved memory" or inside of Ring 0 or whatever .... that said. This is no excuse to not learn and practice the best practices the thing is you need to learn them so you know what you're talking about when you deviate from them or ignore them.

if you understand and choose against something on a logical basis it's better than not understanding something and deciding against it. This goes for every aspect in life.

You will always program in a way which is branded as bad idea by someone out there. So do not think about others, think about your problem and how to solve it.

As an example, see the completely opposing arguments in StandardJS vs Google Style Guide. I prefer the latter btw :)

I've never actually followed a design pattern/best practise - it's something I should look more into.
That said, I do come from an engineering background which has given me the ability to make sure that what I'm doing actually doing makes sense and not just there because it's a habit/bad habit.

For example, I prefer some of the K&R coding styles, such as the parenthesis placements. However, in javascript I tend to put a semi-colon, ";", after everything (even though it's not required) because I prefer the explicit nature that this provides.
I know some programmers will disagree with this because it's not technically correct for a machine. However, I do run this through a couple processors before publishing it. So it's purely there for readability.

Then there's the age old debate/heated argument of TABS vs spaces.

tl;dr - As long as you and your team come up with a set of standards to abide by then you'll be fine. It should all read as though one person wrote it.

1, No comment

I don't like to write comment for each of statement/function/class even before I heard the concept "clean code". Almost developers I work with don't think that's good idea.

2, Short variable name

I still like to name the variables with just one letter in the contexts (usually local) where the logic is clear and easy to understand. For example:

var formatCurrency = (num) => {
  let n = Number(num);
  if (!n || !bella.isNumber(n) || n < 0) {
    return '0.00';
  }
  return n.toFixed(2).replace(/./g, (c, i, a) => {
    return i && c !== '.' && (a.length - i) % 3 === 0 ? ',' + c : c;
  });
};

Line 58

Many developers I work with with don't think that's good idea.

I do something really basic really "wrong".

I unindent some html blocks where I feel like they are there own section or piece or whatever.

Basically I unindent everything that I would make a block if I was using a templating engine on the same project.

Some people might think this is horrible for readability, but I think it improves it.