Javascript代码复审(review)

一、概要部分

  a) 代码符合需求和规格说明书吗?

  b) 代码设计是否考虑周全?

  c) 代码可读性如何?

  d) 代码容易维护吗?

  e) 每一行代码都执行并检查过了吗?

二、设计规范部分

  a) 设计是否遵从已知的模式或项目中常用的模式?

  b) 有没有硬编码或字符串/数字等存在?(使用与配置相分离,只需改配置文件而不需改代码)

  c) 代码有没有依赖于某一平台,是否影响将来的移植?(浏览器兼容性)

  d) 新写的代码是否出现已有相似功能可以调用却没有调用的情况?(重复编码)

  e) 有没有无用代码可以清除?(利用代码控制工具保存原来的老代码)

三、代码规范部分

  a) 缩进

    四个空格

  b) 行宽

    100个字符

  c) 括号

    复杂的条件表达式中应该用括号清楚地表示优先级

  d) 大括号

    if(true){

      Some();

    }else{

      Some();

    }

  e) 分行

    多个变量多行定义

  f) 命名

    字符串sVar

    数字型iVar

    布尔型bVar

    数组aVar

    对象oVar

  g) 下划线

    在私有变量或者局部变量中使用。示例:_iVar

  h) 大小写

    类、变量  名词  Member

    函数  动词/动宾组合  getMember

  i) 注释

    1.不要解释程序是怎么工作的(How)

    2.应该解释程序做什么(What)和为什么这样做(Why)

    3.需要特别注意的地方

    4.不要用中文及特殊字符

    5.双斜线后要加一个空格后在写内容

    6.意义复杂变量需注明是表示什么的变量

    7.方法需注明

      @todo: 需要做的事情

      @author: 作者(必填)

      @review: 记录复审时发现的问题

      @bug: 记录已经出现的问题

      @param: 对入参的说明(必填)

      @return: 对出参的说明(必填)

      @exception: 抛出异常的类型

      @deprecated: 不建议使用该方法

      示例:

/**

 * 函数功能简述

 *

 * 具体描述一些细节

 *

 * @param    {string}  address     地址

 * @param    {array}   com         商品数组

 * @param    {string}  pay_status  支付方式

 * @returns  void

 *

 * @date     20170707

 * @author   xxx<[email protected]>

 */

    8.简单明了,含义准确

    9.注释形式统一

    10.注释与代码同步更新

    11.发布前删除无用注释

  j) 函数

    1.只做一件事,并且要做好

    2.验证参数正确性

    3.断言,方法可能失败的时候要写相应的空判断,再执行接下来的代码

四、具体代码部分

  a) 有没有对错误进行处理?

  b) 参数传递有无错误?

  c) 边界条件是如何处理的?循环有没有可能出现死循环?

  d) 有没有使用断言来保证我们认为不变的条件真的得到满足?

  e) 数据结构中有没有用不到的元素?

五、效能

  a) 代码到效能如何?最坏的情况是怎样的?

  b) 代码尤其是循环中是否有明显可优化的部分?

  c) 对系统和网络的调用是否会超时,如何处理?

六、可读性

  a) 代码的可读性如何?

  b) 有没有足够的注释?

七、可测试性

  a) 是否需要或创建新的单元测试?

时间: 2025-01-08 03:11:33

Javascript代码复审(review)的相关文章

代码规范、代码复审、PSP

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

Javascript代码规范

1. 前言 JavaScript一直有着广泛的应用,特别是在浏览器端的行为管理.本文档的目标是使JavaScript代码风格保持一致,容易被理解和被维护. 虽然本文档是针对JavaScript设计的,但是在使用各种JavaScript的预编译语言时(如TypeScript等)时,适用的部分也应尽量遵循本文档的约定. 任何问题或建议,欢迎跟我们讨论 2. 代码风格 2.1. 文件 ·[建议] JavaScript 文件使用无 BOM 的 UTF-8 编码. 解释 UTF-8 编码具有更广泛的适应性

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

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

FineUI(专业版)实现百变通知框(无JavaScript代码)!

曾经,有网友抱怨FineUI中连个通知框都没有,当用户进行某个操作成功时给个右下角的提示很不方便. 强大的设置参数 现在,FineUI(专业版)提供了强大的通知框机制,一个小小的通知框居然有多达 16 种不同的设置,可见威力之强大. 下面通过一张图片来简单概括一下: 1. 模式或者非模式对话框2. 消息图标可显示(消息.警告.问题.错误.成功),也可隐藏3. 正在加载图片可显示隐藏4. 消息正文可自定义5. 对话框标题可自定义6. 关闭图标可显示隐藏7. 标题栏可拖动8. 标题栏可隐藏9. 弹出

编写简洁的 JavaScript 代码

作者:尹锋链接:https://www.zhihu.com/question/20635785/answer/223515216来源:知乎著作权归作者所有.商业转载请联系作者获得授权,非商业转载请注明出处. 避免使用 js 糟粕和鸡肋 这些年来,随着 HTML5 和 Node.js 的发展,JavaScript 在各个领域遍地开花,已经从"世界上最被误解的语言"变成了"世界上最流行的语言".但是由于历史原因,JavaScript 语言设计中还是有一些糟粕和鸡肋,比如

MVC项目实践(七)——代码复审和运行测试

本次所有的工作都是我们小组分工完成的.同样我们主管代码复审的同学也负责任的在我们完成编码工作之后认真的完成了代码复审的工作. 以下是本次运行截图 选择业务的首页 选择队伍的页面 添加队伍的页面 计分页面 观众详情页面 查询队伍的页面 查询比赛的页面 查询具体比分的页面 以上为主要的页面测试结果.之前设计功能都能够实现.就是美化工作还没做.有些简陋.

代码示例:一些简单技巧优化JavaScript编译器工作详解,让你写出高性能运行的更快JavaScript代码

告诉你一些简单的技巧来优化JavaScript编译器工作,从而让你的JavaScript代码运行的更快.尤其是在你游戏中发现帧率下降或是当垃圾回收器有大量的工作要完成的时候. 单一同态: 当你定义了一个两个参数的函数,编译器会接受你的定义,如果函数参数的类型.个数或者返回值的类型改变编译器的工作会变得艰难.通常情况下,单一同态的数据结构和个数相同的参数会让你的程序会更好的工作. function example(a, b) { // 期望a,b都为数值类型 console.log(++a * +

javascript代码放置位置对程序的影响

在编写html文档时,javascript可以放置的位置有两个地方<head>或者<body>,但是放置的地方,会对 JavaScript 代码的正常执行会有一定影响.由于 HTML 文档是由浏览器从上到下依次载入的,javascript的放置位置主要影响获取网页元素.如果你的代码中包含获取网页元素的代码例如document.getElementById(),那么你需要确保你的javascript代码要在你想要获取的元素的位置之后.如过在你想要获取的元素的位置之前调用这个些代码,由

javascript代码规范 [转]

原文:http://www.css88.com/archives/5366 全局命名空间污染与 IIFE 总是将代码包裹成一个 IIFE(Immediately-Invoked Function Expression),用以创建独立隔绝的定义域.这一举措可防止全局命名空间被污染. IIFE 还可确保你的代码不会轻易被其它全局命名空间里的代码所修改(i.e. 第三方库,window 引用,被覆盖的未定义的关键字等等). 不推荐 1 var x = 10, 2 y = 100; 3 4 // Dec