introduce

  • This specification is constructed by vuepress framework.
  • See the Github project for specific rules, which are briefly described in this article.
  • The project is only a draft, only for reference, welcome suggestions.
  • Github link: github.com/zhuangweizh…

Why standardize

Years in the pit, feeling deep. Everyone has their own ideas, and everyone has their own habits. On a team without a lead, it’s often about poking fun at each other’s code, and then writing it yourself.

It seems that everyone is right and everyone has a good reason.

Over time, the project became more modular. My module, only I can read it!

So, why regulate? My personal understanding is:

Set a rule together that the team (or the majority, or the leader) can agree on and execute together. Follow-up, do not appear your personal habits! Don’t write it like that again! You don’t have to explain to anyone how elegant your writing is! All you have to do is follow suit!

Such as naming, humping and underlining, they never have absolute advantages or disadvantages. The team defines it and then executes.

Specification definition

How to define it is the key.

In my opinion, the process should be like this:

  • 1) Reference hundreds of long, Ali norms or Tencent norms, copy up.
  • 2) A person in charge, or a naive friend, compiled his/her first draft (mock version)
  • 3) The ridicule version starts the ridicule of the team. Discuss the pros and cons of each point.
  • 4) Sorting out the first draft. Then the practice of the scheme (how to constrain, detect, etc.)
  • 5) Final version (with a conclusion and no problems found in practice, it is not recommended to modify it several times)
  • 6) Code review
  • 7) Make fun of others for not using code that is properly handled

Purpose of specification

To paraphrase Baldwin’s article (juejin.cn/post/684490…

  • Disciplined code promotes teamwork;
  • Regular code reduces bug handling;
  • Regular code can reduce maintenance costs;
  • Normative code facilitates code review;
  • Getting into the habit of code specification helps programmers grow

The specification shared in this article

The specification shared in this article is only a draft.

  • 1) Naming specifications, including basic principles, directory, variable, style and other naming specifications
  • 2) Text specification, including indentation, quotation marks, spacing, etc
  • 3) Develop specifications, including principles, IDE, plug-in and other definitions.
  • 4) HTML specification, including basic syntax, attribute order, etc.
  • 5) CSS specification, including basic syntax, SCSS, BEM specification, yard class specification, etc.
  • 6) JS specification, including basic criteria, function methods, circular methods and other definitions.
  • 7) VUE specification, including basic principles, life cycle, cache scheme and other specifications.

Reference is welcome, and corrections and deficiencies are welcome in the provisional draft.