腾讯Alloy团队代码规范

概述

我个人很看重代码规范,因为代码是写给别人看的,按规范写别人才更容易理解。之前苦于没有代码规范的资料,现在在github上面看到了腾讯Alloy团队的代码规范,于是学习了一下,并记录下我自己还没怎么注意的地方,供以后开发时参考,相信对其他人也有用。

顺便说下,这里是腾讯Alloy团队推荐的sublime3配置

命名规则

  1. 文件命名全部采用小写方式, 以下划线分隔,有复数结构时,要采用负数命名法。

HTML

  1. 属性名,使用双引号,不要使用单引号;全小写,用中划线做分隔符。
  2. 不要在自动闭合标签结尾处使用斜线。
  3. doctype大写。
  4. 在html标签上加上lang属性。
  5. 声明一个明确的字符编码,通常指定为‘UTF-8‘。
  6. 用meta标签指定页面应该用什么版本的IE来渲染(比如content="IE=Edge");
  7. 在引入CSS和JS时不需要指明type。
  8. 属性应该按照特定的顺序出现以保证易读性,class>id>name>data-*>src等
  9. boolean属性不需要声明取值。
  10. 避免用js生成标签。
  11. 在编写HTML代码时,需要尽量避免多余的父节点。

css,scss

  1. 属性声明顺序
  2. 以下几种情况需要换行:(1)‘{‘后和‘}‘前(2)每个属性独占一行(3)多个规则的分隔符‘,‘后。
  3. 注释统一用‘/* */‘(scss中也不要用‘//‘)。
  4. 最外层统一使用双引号。
  5. 类名使用小写字母,以中划线分隔;id采用驼峰式命名;scss中的变量、函数、混合、placeholder采用驼峰式命名。
  6. 颜色16进制用小写字母;颜色16进制尽量用简写。
  7. 除了margin和padding,都不需要使用属性简写,尽量分开声明。
  8. 尽量将媒体查询的规则靠近与他们相关的规则,不要放进独立样式文件,也不要扔在底部。
  9. @import 引入的文件不需要开头的‘_‘和结尾的‘.scss‘。
  10. 声明顺序:@extend;不包含 @content 的 @include;包含 @content 的 @include;自身属性;嵌套规则。
  11. 去掉小数点前面的0。
  12. 属性值‘0‘后面不要加单位。
  13. 同个属性不同前缀的写法需要在垂直方向保持对齐,无前缀的标准属性应该写在有前缀的属性后面。
  14. 用 border: 0; 代替 border: none;
  15. 发布的代码中不要有 @import。
  16. 尽量少用‘*‘选择器。

JavaScript

  1. return后面需要加分号。
  2. 这些关键字后要留一个空格:if, else, for, while, do, switch, case, try, catch, finally, with, return, typeof。
  3. ‘}‘前需要换行。
  4. 单行注释缩进与下一行代码保持一致。
  5. 多行注释最少三行, ‘*‘后跟一个空格。
  6. 最外层统一使用单引号。
  7. 这些字符串一律按这里的写法,不小写或大写:‘ID‘,‘URL‘,‘Android‘, ‘iOS‘。
  8. 构造函数,大写第一个字母
  9. 常量全大写,用下划线连接。
  10. 对象属性名不需要加引号;数组、对象最后不要有逗号。
  11. 永远不要直接使用undefined进行变量判断;使用typeof和字符串‘undefined‘对变量进行判断。
  12. for-in里一定要有hasOwnProperty的判断。
  13. 不要在同个作用域下声明同名变量。
  14. 不要在一些不需要的地方加括号,例:delete(a.b)。
  15. 数组中不要存在空元素。(有疑问???)
  16. 换行符统一用‘LF‘,即‘/n‘。
  17. 对上下文this的引用只能使用‘_this‘, ‘that‘, ‘self‘其中一个来命名。
  18. 一个函数作用域中所有的变量声明尽量提到函数首部,用一个var声明,不允许出现两个连续的var声明。比如:
    function doSomethingWithItems(items) {
    // use one var
    var value = 10,
        result = value + 10,
        i,
        len;
    
    for (i = 0, len = items.length; i < len; i++) {
        result += 10;
    }
    }

原文地址:https://www.cnblogs.com/yangzhou33/p/8536943.html

时间: 2024-10-12 18:21:25

腾讯Alloy团队代码规范的相关文章

团队开发前端VUE项目代码规范

团队开发前端VUE项目代码规范 2018年09月22日 20:18:11 我的小英短 阅读数 1658 一.规范目的: 统一编码风格,命名规范,注释要求,在团队协作中输出可读性强,易维护,风格一致的代码 二.开发SRC目录: 1.Vuex目录 (状态树配置) 2.Router目录(路由配置) 3.Pages目录 (放置主路由组件 注意命名规范) 4.Common目录 (放置静态文件) 5.Config目录 (全局配置项,路由拦截,报错信息,等枚举信息) 6.Api目录 ( 相关全局请求调用配置.

PHP团队 编码规范 &amp; 代码风格规范

一.基本约定 1.源文件 (1).纯PHP代码源文件只使用 <?php 标签,省略关闭标签 ?> : (2).源文件中PHP代码的编码格式必须是无BOM的UTF-8格式: (3).使用 Unix LF(换行符)作为行结束符: (4).一个源文件只做一种类型的声明,即,这个文件专门用来声明Class, 那个文件专门用来设置配置信息,别混在一起写: 2.缩进 使用Tab键来缩进,每个Tab键长度设置为4个空格: 3.行 一行推荐的是最多写120个字符,多于这个字符就应该换行了,一般的编辑器是可以设

iOS团队开发代码规范

iOS 开发代码规范 1.命名 https://github.com/Chinamobo/iOS-Team-Norms/blob/master/CodeStyle.md#naming-basic-principle https://github.com/foxsofter/ios-code-style https://github.com/andy0323/iOS-Code-Specification 新建.h,.m文件时,文件名称应与

PHP 代码规范、流程规范、git规范

代码规范.git规范.teambition规范.yii规范 1. 命名规范 (1).变量命名规范 1.变量使用驼峰命名法 禁止使用拼音或者拼音加数字 2.变量也应具有描述性,杜绝一切拼音.或拼音英文混杂的命名方式 3.变量包数字.字母和下划线字符,不允许使用其他字符,变量命名最好使用项目 中有据可查的英文缩写方式, 尽可以要使用一目了然容易理解的形式: 4.变量以字母开头,如果变量包多个单词,首字母小写,当包多个单词时,后面 的每个单词的首字母大写. 例如 :$itSports 5.变量使用有效

作业三: 代码规范、代码复审、PSP

(1) 是否需要有代码规范         1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西.(反对) 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规

两人合作之代码规范

代码规范 现代软件经过几十年的发展,一个软件由一个人单枪匹马完成,已经很少见了,软件都是在相互合作中完成的.合作的最小单位是两个人,两个工程师在一起,做的最多的事情就是"看代码",每个人都能看"比人的代码",并且发表意见.但是每个人对于什么是"好"的代码规范未必认同,这时我们有必要给出一个基准线-----什么是好的代码规范和设计规范. 1,写干净整洁的代码 1.1 代码格式化,包括多级代码缩进.大括号(比如C系代码),为了提高代码的美观型和易读性

代码规范的重要性

一个规范的代码,通常能起到事半功倍的作用: 一.规范的代码可以促进团队合作 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉.显然的,规范的代码在团队的合作开发中是非常有益而且必要的. 二.规范

项目经理的管理技巧-代码规范

一.系统里面存在的糟糕代码情况有: 1. 代码规范,命名规范和注释 2. 公用代码的抽取和封装 3. 性能低下的代码 4. 表现层.业务层.数据持久层位置存放混乱问题 二.问题 岗位调动,接手一个新的项目组.旧项目一踏糊涂,全部无规范和设计. 组成员各做各的,毫无团队协作能力,更别说团队凝聚力.简直不能更糟糕. 新项目.新成员,新项目重新做了明确规范和框架设计,但组员很多时候不能很好的按照规范进行开发 我有强迫症  三.开始犯的错误,也是最笨的做法 定时核查,自己看到不正确代码同时指出,让开发优

代码规范

1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉. 2.我是个艺术家,手艺人,我有自己的规范和原则 每一个