This is a mishmash of coding standards (at ABC CO we use tabs!) randomly sprinkled with best practices. It's important to standardize on things without one way necessarily being better than another. The organization also seems a bit rushed. For example, not exposing the DB schema in a URL shouldn't really go into the section on encoding. Moreover, SQL injection is almost never fixed by using an escaping function, as by far the most common problem with SQL injection is letting the client specify field and column names, or things that aren't quoted (e.g. numerical id's) and so don't benefit from escaping.
I don't want to discourage any company from setting and documenting coding standards, but this particular document feels a bit rushed and could use adherence to best practices of its own. For example,
1. If making an opinionated mandate, provide a link to an explanation
2. Consistently provide links to examples
3. Maybe do some spell-checking: "Hallo"?
4. Try to maintain a uniform level of specificity
E.g. in the section on URL security, there is this vague comment:
"Attackers can tamper with any part of an HTTP request, including the URL, query string,"
Which, while a true, doesn't describe what the programmer should or shouldn't do. It's just hanging there. Compare with the weird specificity of listing git commands in section 1.
That tells me the author knew a lot about checking stuff into git, but was a bit out of his/her league when it came to Security, so they just made generic security statements while giving precise instructions for using git.
A lot of companies these days create "Best practices" guidelines just to boost their online recognition. Very often I find these guidelines useless or even harming.
Basically every statement that says "Never do A" or "Always do B" without providing any justification for it. Documents like this only contribute to holy wars between junior developers by creating an impression that they should blindly obey some random set rules rather than forming balanced opinions.
This document should rather be called:
"Some practices for JavaScript projects that work for devs at Hive but might not necessarily work for you."
It's fine to have company wide coding standards. You don't need to call them "Best Practices", "Our practices" is enough. You can iterate and find out which of these are OK through experience and feedback. Some of the rules here are very specific and just wont work well in the general case (e.g. directory organization, which should probably be decided at a lower level than a company wide policy). Others are too vague to be usefully actionable (security stuff). Having developers instead of legal read Licenses and decide which projects are OK to include in your source seems dangerous.
All the big companies have style guides, but protocols are harder to transplant because it's not reasonable for smaller companies to follow the same practices as big companies.
I wouldn't adopt more process overhead without a specific reason.
E.g. if you are having quality issues where R&D is shipping stuff before it's ready, then institute a more formal process of sign-off for a release so R&D needs approval from QA.
If you are having problems making builds repeatable, then start standardizing the environments with golden images, put everything in version control, etc.
If you have issues with licenses for third party code, a 3PP (Third party program) process with sign off from legal/other teams (security would be nice).
For each set of problems, there are processes designed to address those. You will also encounter less resistance when the process is a solution to a problem rather than adherence to a best practice. I also wouldn't try to adopt processes just to satisfy a general desire for more process, because there are costs to adopting process overhead, especially the cost of becoming a bit dumber, as an organization, each time you adopt a process to formalize what was previously a judgement call by some decision maker.
I don't want to discourage any company from setting and documenting coding standards, but this particular document feels a bit rushed and could use adherence to best practices of its own. For example,
1. If making an opinionated mandate, provide a link to an explanation
2. Consistently provide links to examples
3. Maybe do some spell-checking: "Hallo"?
4. Try to maintain a uniform level of specificity
E.g. in the section on URL security, there is this vague comment: "Attackers can tamper with any part of an HTTP request, including the URL, query string,"
Which, while a true, doesn't describe what the programmer should or shouldn't do. It's just hanging there. Compare with the weird specificity of listing git commands in section 1.
That tells me the author knew a lot about checking stuff into git, but was a bit out of his/her league when it came to Security, so they just made generic security statements while giving precise instructions for using git.