Organization level Coding Standard

Coding standards generally have two aims

1. They try to set a common style guide for the code.
   Having a common style makes it easier for people to understand the codebase as a whole, because they don’t get distracted by trivialities like changes in indentation or brace placement.

   It is paramount that a common style gets used within a team, but if you often exchange code and/or people between teams then a common style guide for the company as a whole can be advantageous as well.

2. They guide people in language constructs that should be avoided because they are know to cause a high incidence of bugs.

   In a coding standard for JavaScript, I can easily see a prohibition against using == for equality comparisons. The most important part here is the explanation why the prohibition exists.

Apart from having a coding standard, you also need to think about how to enforce the rules in that coding standard. The strong preference here is to have tooling in place that can enforce the rules automatically.

Some observations and my conclusions:

Different styles of JS approach
While one team might work on pretty new Angular Typescript Stuff, another team might have older software to maintain. And there is team culture as well. There will be just not one standard for all. People even will look in other languages and adapt patterns from there. So no need for one standard

A standard need to be enforced
So if you all want to have standards or have realized that a bunch of pseudo standards, that no one really adheres to, are not helping. Get down and speak (opt in – as a group of interested devs) why and how you see the standards. Nail them down. In a .jshint file. Don’t commit code that gets hint errors. A commit is a bunch of lines of code changes and there is really nothing to a little check of that. Just get used to not sh** into your CVS/SVN/GIT anymore. I would go for less enforced rules in ugly repos and a clear set of a bit more in others. Let room for interpretation: Tabs or Spaces? Don’t even bother. Everyone make sure it is either or and not Tabs AND Spaces.

Every team/repo can have a own standard
There is a social component to this. Standards will evolve, and developers with growing skills tend to have a small number of relative strict ones. Give the teams, maybe i a forum, a bit of a leverage and space to exchange ideas and things get better. If you are in charge of such a initiative, find ways to monitor success of teams adhering to the standards (code climate etc). Basically every repo should give a simple guess how clean it is, according to your self imposed rules.

TL;TR: Let Teams/Projects define standards, give them the tools to
enforce them and help keeping the code structured as everyone on
the team expects. Some reasoning with own company culture, tech and
approach helps here finding sensible defaults.

Over time, I have come to believe the biggest reason to have a coding standard is to minimize trivial diffs when reviewing / merging files into your scm system.

I do think for that reason alone, a style / format based standard is worth it.

I also strongly recommend using a common (everyone in the team uses the same tool and version and configure) source formatting tool to enforce (to a reasonable extent) these standards.

A best practices coding standard is a more fraught endevour. Practices change, and what was once okay can fall out of favor. What then? You have a lot of non-compliant code. I’d tread lighter here, and leave the standards to organization specific needs (e.g., can not use a 3rd party library unless approved by architect for X).