Nodejs变成规范--建议

Nodejs并没有官方文档规定应用程序的代码风格,但是有一些事实上的约定。

  1. 缩进--两空格
  2. 行宽--80个字符
  3. 语句分隔符

    建议一律使用分号,哪怕一行只有一个语句,也不要省略分号

  4. 变量定义--永远使用var定义变量,并确保每个语句定义一个变量
  5. 变量名和属性名--小驼峰式命名法
  6. 函数--一般函数 小驼峰式;构造函数 大驼峰式
  7. 引号 -- 统一为单引号
  8. 关联数组的初始化

    var = { 放在一行, 下面每行一对键值,保持两空格缩进,以分号结尾, }; 最后单独另起一行;

    对于每对键值,除非键值名中有空格或者非法字符,否则一律不用引号。

  9. 等号 -- ===
  10. 命名函数

    尽量给构造函数和回调函数命名,在调试时可以清晰显示调用栈;

    回调函数,约定第一个参数是错误对象err。

  11. 对象定义 -- 尽量将所有成员函数通过原型定义,将属性在构造函数内定义,然后对构造函数使用new关键字创建对象;绝对不要把属性作为原型定义。
  12. 继承 -- 尽量使用util模块中的inherits函数。

Nodejs变成规范--建议

时间: 2024-10-10 16:49:00

Nodejs变成规范--建议的相关文章

Windows客户端C/C++编程规范“建议”——函数

1 函数 1.1 代码行数控制在80行及以内 等级:[要求] 说明:每个函数的代码行数控制应该控制在80行以内.如果超过这个限制函数内部逻辑一般可以拆分.如果试图超过这个标准,请列出理由.但理由不包含如下: 无法拆分. 流程内部逻辑复杂,无需拆分,即使拆分了,拆分的函数也不会被其他地方用到.(解释:拆分可以减少代码行数,提炼后的函数可以方便读者快速理解函数逻辑并定位问题.) 1.2 代码列数控制在100字符及以内 等级:[要求] 说明:每行代码不可以超过100字符.如果超过这个字符数,代码的美观

Windows客户端C/C++编程规范“建议”——指针

2 指针 2.1 尽量使用智能指针 等级:[推荐] 说明:正确使用智能指针可以省去指针管理的工作. 2.2 类成员变量指针释放后一定要置空 等级:[必须] 说明:如果类成员变量指针在释放后没有置空,将出现如下问题: a) 无法判断指针是否已经是野指针 b) Dump分析很难发现是野指针函数调用导致崩溃 2.3 正确使用delete和delete[] 等级:[必须] 说明:delete[]用于释放动态分配的数组,而delete用于释放对象.两者不可以混用. 2.4 使用指针前要判空 等级:[必须]

Windows客户端C/C++编程规范“建议”——函数调用

3 函数调用 3.1 谨慎使用递归方法 等级:[推荐] 说明:递归方式控制不当,可能会导致栈空间不够而崩溃.一般的递归都可以使用循环代替. 3.2 不要使用using namespace 等级:[必须] 说明:这是曾经教科书上的一种写法,但是该方法存在严重的缺陷.因为如果多个不同的namespace里定义了相同名字的变量或者函数.将导致无法预知和理解编译器最终使用的是哪个命名空间中的数据. 例子: //file1 namespace Space1{ int g_Private = 0; }; /

Windows客户端C/C++编程规范“建议”——前言

前言 工作中接触了很多编程规范.其中最有意思的是,公司最近发布了一版C/C++编程规范,然后我看到该规范的最后一段时,有这么一句:"该规范不适用于Windows平台开发".看来这份规范是由做其他平台开发的同学制定的.那么做Windows开发的人都去哪儿了?后来由于工作需要,项目组需要我制定一份编程规范.这也是我这系列博客的由来.(转载请指明出于breaksoftware的csdn博客) 说到"规范"",可能没多少人喜欢这样的东西.相信很多工程师和我一样,都

Windows客户端C/C++编程规范“建议”——表达式和运算

4 表达式和运算 4.1 比较操作中将常量设置为左值 等级:[推荐] 说明:编写代码时,如果将常量设置为右值.可能因马虎将"=="写成"="导致逻辑错误.这种场景下,编译器是不会报错的,代码检查也比较容易被忽视. 例子: std::string::size_type index = str.find("a"); if ( index = std::string::npos){ } 上例中写法可以执行,但是逻辑是错的.如下编写,可以借助编译器检查出

Windows客户端C/C++编程规范“建议”——结构

5 结构 5.1 不要使用goto 等级:[必须] 说明:在大型项目中,goto的滥用会导致灾难性后果.因为我们程序中一般不存在从一个函数体内部跳转到另一个函数体内部的场景,所以我们可以将跳转控制在函数内部,从而避免灾难. 例子: do { if ( False ) { break;// 相当于goto } } while (0); 5.2 不要利用异常机制实现流程的跳转 等级:[必须] 说明:该方法比较常见于防逆向等方面,但是我们普通编程方式应该严禁使用.否则将增加代码阅读的难度. (转载请指

Windows客户端C/C++编程规范“建议”——宏

6 宏 6.1 减少宏的使用 等级:[建议] 说明:宏的使用,将使得调试变得麻烦.所以在设计和使用宏的时候,请确保宏的逻辑是阅读者不会去关心细节的行为. 6.2 宏定义中字母需大写 等级:[必须] 说明:为了醒目表示它是一个宏,而不是一个函数. 6.3 使用const变量代替宏定义值 等级:[建议] 说明:在一个函数体内部使用的常量,最好使用const变量替代,而不是使用宏. 6.4 使用枚举代替一系列有关联的宏 等级:[建议] 说明:比如一个函数返回一系列表示状态的宏,则应该使用枚举类型替代.

Windows客户端C/C++编程规范“建议”——文件

7 文件 7.1 正确使用#include 等级:[推荐] 说明:#include <>和#include ""导致编译器在搜索文件时,搜索的路径顺序不同.所以需要正确使用#include,以避免包含错了头文件. 语法形式 操作 带引号的形式 预处理器按以下顺序搜索包含文件: 在包含 #include 语句的文件所在的同一目录中. 在当前打开的包含文件的目录中,采用与打开它们的顺序相反的顺序. 搜索从父包含文件的目录中开始进行,然后继续向上到任何祖父包含文件的目录. 跟随每

WindowsclientC/C++编程规范“建议”——前言

前言 工作中接触了非常多编程规范.当中最有意思的是,公司近期公布了一版C/C++编程规范,然后我看到该规范的最后一段时,有这么一句:"该规范不适用于Windows平台开发".看来这份规范是由做其它平台开发的同学制定的.那么做Windows开发的人都去哪儿了?后来因为工作须要,项目组须要我制定一份编程规范.这也是我这系列博客的由来.(转载请指明出于breaksoftware的csdn博客) 说到"规范"",可能没多少人喜欢这种东西.相信非常多project师