# 前言

为什么要写编码规范呢？我希望在一个团队里面能形成一种规范，小到程序编码格式（如是否驼峰还是横杆，css 属性书写时候的顺序），大到一个团队里面协调配合进行组件开发（如模块化、组件化编程、方便团队合作和修改代码）。每个团队都应该具备有这么一套规范，我通俗称他为团队默契。当你掌握了一套编码规范，并以之为习惯，我相信这不仅是对你编码生涯的一个产生较大的影响，而且还有对你的职业生涯有个美好的开端。

# 简要

总体分为：css 篇、js 篇、编码篇。同时提一下：遇到不懂或没有见过的技术，请查阅文档，请查阅文档，请查阅文档，重要的事情说三次。

# 前方高能〇

css 篇： css 编码设置

在编写 css 的头部添加 UTF-8 编码

@charset "utf-8";

类名命名空间规范

布局：以 g 为命名空间，如：g-wrap,g-header,g-content 工具：以 u 为命名空间，表示不耦合、可复用的辅助工具，如：u-clearfix,u-ellipsis,u-text-right 组件：以 m 为命名空间，表示可复用、移植的组件模块，如：m-header、m-slide、m-aside-post 状态：以 s 为命名空间，表示动态的、具有交互实质的状态（简单理解即：动态取值），如：s-current、s-selected，s-option，钩子：以 h 为命名空间，表示特定给 JavaScript 调用的类名，只作为钩子调用，如：h-request,h-open,h-slide

类名组合方式

统一小写字母，并以横杆（-）来链接，如：

g-header，g-topbar

选择器当一个规则包含多个选择器时，每个选择器独占一行。、+、~、> 选择器的两边各保留一个空格。如：

.g-header > .g-header-des,
.g-content ~ .g-footer {}

规则声明块

当规则声明块中有多个样式声明时，每条样式独占一行。

在规则声明块的左大括号 { 前加一个空格。
在样式属性的冒号 : 后面加上一个空格，前面不加空格。
在每条样式后面都以分号 ; 结尾。
规则声明块的右大括号 } 独占一行。
每个规则声明间用空行分隔。
所有最外层引号使用单引号 ' 。
当一个属性有多个属性值时，以逗号 , 分隔属性值，每个逗号后添加一个空格，当单个属性值过长时，每个属性值独占一行。

如：

.g-footer,
.g-header {
  position: relative;
}

.g-content {
  background:
    linear-gradient(135deg, deeppink 25%, transparent 25%) -50px 0,
    linear-gradient(225deg, deeppink 25%, transparent 25%) -50px 0,
    linear-gradient(315deg, deeppink 25%, transparent 25%),
    linear-gradient(45deg, deeppink 25%, transparent 25%);
  }

.g-content::before {
  content: '';
}

数值与单位

当属性值或颜色参数为 0 - 1 之间的数时，省略小数点前的 0 。

	color: rgba(255, 255, 255, 0.5)

	color: rgba(255, 255, 255, .5);


当长度值为 0 时省略单位。


	margin: 0px auto

	margin: 0 auto


十六进制的颜色属性值使用小写和尽量简写。


	color: #ffcc00

	color: #fc0

样式属性顺序单个样式规则下的属性在书写时，应按功能进行分组，

并以 Positioning Model > Box Model > Typographic > Visual 的顺序书写，

提高代码的可读性。如果包含 content 属性，应放在最前面。因为从排序从开头到结尾，能影响不仅的就是 model，其次是内容排版，最好 visual 只是一个视觉展示。 Positioning Model (布局方式、位置，相关属性)：position / top / right / bottom / left / z-index / display / float / ... Box Model (盒模型，相关属性)：width / height / padding / margin / border / overflow / ... Typographic (文本排版，相关属性)：font / line-height / text-align / word-wrap / ... Visual (视觉外观，相关属性)：color / background / list-style / transform / animation / transition / ...

排列结构如：

Positioning Model | Box Model | Typographic | Visual

代码案例如：

g-header {
	position : relative ;
	display：flex;
	left： 100px;
	margin : 0;
	border : 1px solid #f0f0f0;
	z-index : 100;
	height ：36px;
	line-height : 36px;
	font-size : 14px;
	color : #fff;
	animation : .5s ease all;
}

合理使用使用引号

在某些样式中，会出现一些含有空格的关键字或者中文关键字。

font-family 内使用引号当字体名字中间有空格，中文名字体及 Unicode 字符编码表示的中文字体，为了保证兼容性，都建议在字体两端添加单引号或者双引号：如果路径里面有空格，旧版 IE 是无法识别的，会导致路径失效，建议不管是否存在空格，都添加上单引号或者双引号：

body {
  font-family: 'Microsoft YaHei', '黑体-简', '\5b8b\4f53';
}


background-image 的 url 内使用引号
div {
  background-image: url('...');
}

避免使用 !important 除去某些极特殊的情况，尽量不要不要使用 !important。

代码注释单行注释星号与内容之间必须保留一个空格。如：

/* 表格隔行变色 */

多行注释星号要一列对齐，星号与内容之间必须保留一个空格。如：

/**
 * Sometimes you need to include optional context for the entire component. Do that up here if it's important enough.
 */

规则声明块内注释使用 // 注释，// 后面加上一个空格，注释独立一行。如：

.g-footer {
    border: 0;
    // ....
}

文件注释文件顶部必须包含文件注释，用 @name 标识文件说明。星号要一列对齐，星号与内容之间必须保留一个空格，标识符冒号与内容之间必须保留一个空格。如：

/**
 * @name: 文件名或模块名
 * @description: 文件或模块描述
 * @author: author-name(mail-name@domain.com)
 *          author-name2(mail-name2@domain.com)
 * @update: 2015-04-29 00:02
 */

@description 为文件或模块描述。 @update 为可选项，建议每次改动都更新一下。当该业务项目主要由固定的一个或多个人负责时，需要添加@author 标识，一方面是尊重劳动成果，另一方面方便在需要时快速定位责任人。

css 框架

建议使用 sass 或 stylus 框架

使用 SASS ，经常会预先定义好一些常用公用组件类，譬如清除浮动，水平垂直居中，文字 ellipsis。又或者多个元素具有同样的样式，我们希望能够少写这部分代码，公共部分抽离出来只写一次，达到复用。但是复用的方式在 SASS 中有多种，那么是使用单独使用一个类定义，给需要的标签添加，还是使用 @include 或者 @extend 在定义的类中引入一个 @mixin，或者一个 @function 呢？基于让 CSS 更简洁以及代码的复用考虑，采用上面的使用 %placeholders 定义，使用 @extend 引用的方案。

%placeholders，只是一个占位符，只要不通过 @extend 调用，编译后不会产生任何代码量
使用 @extend 引用，则是因为每次调用相同的 %placeholders 时，编译出来相同的 CSS 样式会进行合并（反之，如果使用 @include 调用定义好的 @mixin，编译出来相同的 CSS 样式不会进行合并）
这里的组件类特指那些不会动态改变的 CSS 样式，注意与那些可以通过传参生成不同数值样式的 @mixin 方法进行区分

元素嵌套格式尽量避免使用标签名如：在给最里层的标签命名书写样式的时候，我们有两种选择：

.g-content {
	.g-content-list {
		li {
			...
		}
	}
}

或者是

	.g-content {
		.g-content-list {
			.item {
				...
			}
		}
	}

也就是，编译之后生成了下面这两个，到底使用哪个好呢？

.g-content .g-content-list li { }
.g-content .g-content-list .item { }

基于 CSS 选择器的解析规则（从右向左），建议使用上述第二种 .g-content .g-content-list .item { } ，避免使用通用标签名作为选择器的一环可以提高 CSS 匹配性能。

浏览器的排版引擎解析 CSS 是基于从右向左（right-to-left）的规则，这么做是为了使样式规则能够更快地与渲染树上的节点匹配。

我觉得不同的规范都有各自的长处与缺陷，对待所谓的规范最好的方式不是人云亦云，拿来就用，而是应该结合实际情况及需求，取长补短，取其精华去其糟粕。

JyLie

Choose mode

前端编码规范

前端编码规范

# 前言

# 简要

# 前方高能〇