@@ -628,3 +628,156 @@ eval()和Function构造函数还有一个区别,就是eval()可以修改作用
628628> 关于分号应当注意:和花括号一样,应当总是使用分号,尽管在JavaScript解析代码时会补全行末省略的分号。严格遵守这条规则,可以让代码更加严谨,同时可以避免前面例子中所出现的歧义。
629629
630630### 空格
631+
632+ 空格的使用同样有助于改善代码的可读性和一致性。在写英文句子的时候,在逗号和句号后面会使用间隔。在JavaScript中,你可以按照同样的逻辑在表达式(相当于逗号)和语句结束(相对于完成了某个“想法”)后面添加间隔。
633+
634+ 适合使用空格的地方包括:
635+
636+ - for循环中的分号之后,比如 ` for (var i = 0; i < 10; i += 1) {...} `
637+ - for循环中初始化多个变量,比如 ` for (var i = 0, max = 10; i < max; i += 1) {...} `
638+ - 分隔数组项的逗号之后,` var a = [1, 2, 3]; `
639+ - 对象属性后的逗号以及名值对之间的冒号之后,` var o = {a: 1, b: 2}; `
640+ - 函数参数中,` myFunc(a, b, c) `
641+ - 函数声明的花括号之前,` function myFunc() {} `
642+ - 匿名函数表达式function之后,` var myFunc = function () {}; `
643+
644+ 另外,我们推荐在运算符和操作数之间添加空格。也就是说在+, -, * , =, <, >, <=, >=, ===, !==, &&, ||, +=符号前后都添加空格。
645+
646+ // generous and consistent spacing
647+ // makes the code easier to read
648+ // allowing it to "breathe"
649+ var d = 0,
650+ a = b + 1;
651+ if (a && b && c) {
652+ d = a % c;
653+ a += d;
654+ }
655+
656+ // antipattern
657+ // missing or inconsistent spaces
658+ // make the code confusing
659+ var d= 0,
660+ a =b+1;
661+ if (a&& b&&c) {
662+ d=a %c;
663+ a+= d;
664+ }
665+
666+ 最后,还应当注意,最好在花括号旁边添加空格:
667+
668+ - 在函数、if-else语句、循环、对象直接量的左花括号之前补充空格({)
669+ - 在右花括号和else和while之间补充空格
670+
671+ > 垂直空白的使用经常被我们忽略,你可以使用空行来将代码单元分隔开,就像文学作品中使用段落作分隔一样。
672+
673+ ## 命名规范
674+
675+ 另外一种可以提升你代码的可预测性和可维护性的方法是采用命名规范。也就是说变量和函数的命名都遵照同种习惯。
676+
677+ 下面是一些建议的命名规范,你可以原样采用,也可以根据自己的喜好作调整。同样,遵循规范要比规范本身更加重要。
678+
679+ ### 构造器命名中的大小写
680+
681+ JavaScript中没有类,但有构造函数,可以通过new来调用构造函数:
682+
683+ var adam = new Person();
684+
685+ 由于构造函数毕竟还是函数,不管我们将它用作构造器还是函数,当然希望只通过函数名就可分辨出它是构造器还是普通函数。
686+
687+ 首字母大写可以提示你这是一个构造函数,而首字母小写的函数一般只认为它是普通的函数,不应该通过new来调用它:
688+
689+ function MyConstructor() {...}
690+ function myFunction() {...}
691+
692+ 下一章将介绍一些强制将函数用作构造器的编程模式,但遵守我们所提到的命名规范会更好的帮助程序员阅读源码。
693+
694+ ### 单词分隔
695+
696+ 当你的变量名或函数名中含有多个单词时,单词之间的分隔也应当遵循统一的约定。最常见的做法是“驼峰式”命名,单词都是小写,每个单词的首字母是大写。
697+
698+ 对于构造函数,可以使用“大驼峰式”命名,比如MyConstructor(),对于函数和方法,可以采用“小驼峰式”命名,比如myFunction(),calculateArea()和getFirstName()。
699+
700+ 那么对于那些不是函数的变量应当如何命名呢?变量名通常采用小驼峰式命名,还有一个不错的做法是,变量所有字母都是小写,单词之间用下划线分隔,比如,first_name,favorite_bands和old_company_name,这种方法可以帮助你区分函数和其他标识符——原始数据类型或对象。
701+
702+ ECMAScript的属性和方法均使用Camel标记法,尽管多字的属性名称是罕见的(正则表达式对象的lastIndex和ignoreCase属性)。
703+
704+ 在ECMAScript中的属性和方法均使用驼峰式命名,尽管包含多单词的属性名称(正则表达式对象中的lastIndex和ignoreCase)并不常见。
705+
706+ ### 其他命名风格
707+
708+ 有时开发人员使用命名规范来弥补或代替语言特性的不足。
709+
710+ 比如,JavaScript中无法定义常量(尽管有一些内置常量比如Number.MAX_VALUE),所以开发者都采用了这种命名习惯,对于那些程序运行周期内不会更改的变量使用全大写字母来命名。比如:
711+
712+ // precious constants, please don't touch
713+ var PI = 3.14,
714+ MAX_WIDTH = 800;
715+
716+ 除了使用大写字母的命名方式之外,还有另一种命名规约:全局变量都大写。这种命名方式和“减少全局变量”的约定相辅相成,并让全局变量很容易辨认。
717+
718+ 除了常量和全局变量的命名惯例,这里讨论另外一种命名惯例,即私有变量的命名。尽管在JavaScript是可以实现真正的私有变量的,但开发人员更喜欢在私有成员或方法名之前加上下划线前缀,比如下面的例子:
719+
720+ var person = {
721+ getName: function () {
722+ return this._getFirst() + ' ' + this._getLast();
723+ },
724+ _getFirst: function () {
725+ // ...
726+ },
727+ _getLast: function () {
728+ // ...
729+ }
730+ };
731+
732+ 在这个例子中,getName()的身份是一个公有方法,属于稳定的API,而_getFirst()和_getLast()则是私有方法。尽管这两个方法本质上和公有方法无异,但在方法名前加下划线前缀就是为了警告用户不要直接使用这两个私有方法,因为不能保证它们在下一个版本中还能正常工作。JSLint会对私有方法作检查,除非设置了JSLint的nomen选项为false。
733+
734+ 下面介绍一些_private风格写法的变种:
735+
736+ - 在名字尾部添加下划下以表明私有,比如name_和getElements_ ()
737+ - 使用一个下划线前缀表明受保护的属性_protected,用两个下划线前缀表明私有属性__ private
738+ - 在Firefox中实现了一些非标准的内置属性,这些属性在开头和结束都有两个下划线,比如__ proto__ 和__ parent__
739+
740+ ## 书写注释
741+
742+ 写代码就要写注释,即便你认为你的代码不会被别人读到。当你对一个问题非常熟悉时,你会很快找到问题代码,但当过了几个星期后再来读这段代码,则需要绞尽脑汁的回想代码的逻辑。
743+
744+ 你不必对显而易见的代码作过多的注释:每个变量和每一行都作注释。但你需要对所有的函数、他们的参数和返回值补充注释,对于那些有趣的或怪异的算法和技术也应当配备注释。对于阅读你的代码的其他人来说,注释就是一种提示,只要阅读注释、函数名以及参数,就算不读代码也能大概理解程序的逻辑。比如,这里有五到六行代码完成了某个功能,如果提供了一行描述这段代码功能的注释,读程序的人就不必再去关注代码的细节实现了。代码注释的写法并没有硬性规定,有些代码片段(比如正则表达式)的确需要比代码本身还多的注释。
745+
746+ > 由于过时的注释会带来很多误导,这比不写注释还糟糕。因此保持注释时刻更新的习惯非常重要,尽管对很多人来说这很难做到。
747+
748+ 在下一小节我们会讲到,注释可以自动生成文档。
749+
750+ ## 书写API文档
751+
752+ 很多人都觉得写文档是一件枯燥且吃力不讨好的事情,但实际情况不是这样。我们可以通过代码注释自动生成文档,这样就不用再去专门写文档了。很多人觉得这是一个不错的点子,因为根据某些关键字和格式化的文档自动生成可阅读的参考手册本身就是“某种编程”。
753+
754+ 传统的APIdoc诞生自Java世界,这个工具名叫“javadoc”,和Java SDK(软件开发工具包)一起提供。但这个创意迅速被其他语言借鉴。JavaScript领域有两个非常优秀的开源工具,它们是JSDoc Toolkit(http://code.google.com/p/jsdoc-toolkit/)和YUIDoc(http://yuilibrary.com/projects/yuidoc)。
755+
756+ 生成API文档的过程包括:
757+
758+ - 以特定的格式来组织书写源代码
759+ - 运行工具来对代码和注释进行解析
760+ - 发布工具运行的结果,通常是HTML页面
761+
762+ 你需要学习这种特殊的语法,包括十几种标签,写法类似于:
763+
764+ /**
765+ * @tag value
766+ */
767+
768+ 比如,有一个函数reverse(),可以对字符串进行反序操作。它的参数和返回值都是字符串。给它补充注释如下:
769+
770+ /**
771+ * Reverse a string
772+ *
773+ * @param {String} input String to reverse
774+ * @return {String} The reversed string
775+ */
776+ var reverse = function (input) {
777+ // ...
778+ return output;
779+ };
780+
781+
782+
783+
0 commit comments