I have been asked to document coding standards for javascript at my organization level. Does maintaining coding standards at my organization level sound worth enough? kind of old timers? with the way, how javascript evolving with frameworks like AngularJS, should we just refer the industry standard instead of keeping them at organization? I see them getting outdated quite often.

  • down voter, do you think, this question does not belong here?can you guide me with your comment? Oct 14, 2016 at 11:53
  • My guess is the downvoter is the same hard-of-thinking person who also voted to close as they feel it's unclear what you are asking.
    – David Arno
    Oct 14, 2016 at 12:25
  • 4
    Use an industry standard, not an in-house one. Oct 14, 2016 at 13:48
  • 1
    You probably want every JS programmer in your organization to contribute ideas, put them together, and then have a group of seniors to sort through the more important ones. That is, if guidelines such as coding standards are too far away from reality, or if there is no practical path to move reality toward that goal, the guideline's existence hasn't made anything better. (You might argue that new code could benefit from this, but reality is that new code based on new guideline will soon be asked to be refactored toward the older, realistic style, in the name of consistency.)
    – rwong
    Oct 15, 2016 at 7:47
  • Could you reformulate the question slightly to favor objective answers and avoid opinion based debates (e.g. "worth enough", "old timers", vs. "pros & cons" and "current practice") ? The latter is prohibited on programmer's exchange but your question is really interesting.
    – Christophe
    Oct 15, 2016 at 10:37

3 Answers 3


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.