phpstudy集成环境

 首页 > 如何写出优雅的前端程序？

如何写出优雅的前端程序？

如何写出优雅的前端程序？特别是在Web App这样的业务场景之下，JavaScript代码就更加重要了。
怎么样才能够写出健壮的，可维护的的前端程序。希望可以从各个方面进行解答，而不单单是在编码规范这一个方面。

我觉得相比于写法的各有特色;

var PI = 3.14, win = window, obj = {};

obj.methodSomething = function () {};

jQuery("").m().m().m();

(function() {})();

vs

var PI = 3.14
var win = window
var obj = {
  methodSomething: function() { }
, k: null
}

;!function() {}()

风格不同是一层面,更难的是如何清晰的表达出想法,
最理想的"代码即文档"
ps: 其实我是来测试 插入代码为啥不换行滴...

1）必要的注释
2）命名规范
3）缩进换行
4）对齐
5）使用代码美化工具（如果有的话）

感觉 这个答案是你想要的，上次在 知乎看到过

----------------下面就引用下 知乎的答案---------

我觉得写好代码和作文章差不多，无外乎：工整、优雅、拒绝重复、惜字如金。
几个小建议：

态度
对代码有感情，每一行都应该尽心尽力，并且还要有把所有代码扔垃圾篓之后再重写两遍的冲动——一旦有了这种冲动之后，什么都挡不住你，连吃喝拉撒时，问题都会浮现到你脑子里，你就会不由自主地解决它们……
能对自己的代码提出怀疑本身就是一件了不起的事！加油！

少写代码
提前设计能有助于少写代码，增强全局感。
而代码写得少还能防止失控——感觉不对时就应该停下来，腾出时间来思考，为什么会偏离最先的想法。

所有符号各就各位
第一眼的就是空格太少，我推荐三个工具：
http://jsbeautifier.org 可以给你的代码格式化，记得用 diff 工具对照一下，格式化前后的区别；
SublimeLinter 可以动态地在编写时给出 JSHint 提示（出错行高亮）；
Grunt 可以在文件变更时给出 JSHint 检验（声音以及桌面通知）；
一旦把 lint 校验做为提交代码的必要过程，排版就会有本质的提高。

遵行惯用法
注释符号 // 后应该空一格；
防止变量提升，应先声明后使用（JSHint 会提醒出 _height 存在变量提升以及定义后未使用的错误）；
不应该使用硬编码，并且重复几次（ ID 后缀名可以定义到常量里，用大写字母）；
不应该有两个配置属性，含义不明（this.opts 和 this._options）；
若两次以上引用同一对象的属性，应该定义到局部变量再引用（var options = this._options）；
不应该同时使用两种属性命名风格（colModel 和 table_body）；
局部变量名应该尽可能短，而方法名应该尽可能完整（不应该同时即有 fromatTpl 又有 parseTemplate）；
局部变量名不需要用下划线开头，仅对象私有属性和私有方法有此必要；
变量名不需要带类型属性（_thdoms 叫 ths 就好）；
使用 JavaScript 时，for 循环基本可以避免（比如 jQuery 有 $.each, $.map，$.filter, $.grep 等等高阶函数可用）；
jQuery 对象名习惯以 $ 开头，以便区分 DOM 对象；
jQuery 查询应尽量使用 context （如 this.$table = $('table', this.$element) ）；
jQuery DOM 操作和原生 DOM 操作不应该混用（已经使用 jQuery 的情况，就应该坚持使用 jQuery 来操作 DOM，避免丑陋的原生操作）；
DOM 元素构造出来，也不应该再到文档中查询一遍了（图上的构造太复杂，一眼真看不懂）；

Code Review
把程序写正确还只是跨出了第一步。把代码交给你的同事和朋友 review，这是学习经验、共同提高 最快的办法。

健壮和可维护，要从两个方面来谈。

非JS特有

还是那句老生常谈：“高内聚，低耦合”。

你的模块依赖其他模块的程度越低，接口越少越明确，传递的内容越显而易见，整个程序就越容易维护。

群里 @怡红公子 等群友曾经讨论得出过这样一个结论：“如果觉得代码恶心但是可用，就把代码隐藏（封装）起来”。我觉得这很可行。

从这个意义上讲，Sea.js等模块依赖性管理的组件，是写JS大程序最为不可缺少的基础工具。

JS特有

不客气的说，JS是设计极其恶劣，充满着各种隐喻、假设和不良特性的，一门粗制滥造的有用语言。“JavaScript is VERY faulty”，不止我一个人这么说。

所以提到JS本身的可维护性，重要的就在于一定要躲开JS的若干大坑。例如：

如果要全方位的解答，大致也就像这样“只有原则没有细则”，全方位的都写出来真的太多。

“希望从各个方面得到解答”的问法，气氛上犹如“请从头到尾教我怎么做一个网站”，是Help Vampire的典型表现，还是希望尽量避免。

回答还是要看问题来取舍的，要不然岂不是这样的问题，都可以找一篇《优秀JS代码的xxx条原则》复制粘贴？

别笑，国内最大的低质量问答社区——百度知道就是这样做的！

以下解答以我一时想得起来的为限，全部关于如何对抗“一坨一坨”的观感：

  1. 合理为代码增加空格和空行，例如for (i=0; i<n; i++)观感肯定优于for(i=0;i<n;i++)。
  2. 疯狂的将JS模块化。如果觉得一段代码观感恶心，又碍于实用不好去掉，就提取成单独的函数，甚至单做JS文件。如有必要，可使用Sea.js等工具帮助进行JS模块化。
  3. 疯狂的使用面向对象，替代面向过程。有助于同类代码·数据的内聚，以及方便直接表意。例如，array1.tail(5)观感肯定优于array_tail(array1, 5)。（只是随意的例子，array操作似乎真的不必如此大费周章）
  4. 使用Underscore.js、Zepto等库替代一些常见任务。原则是尽量轻量、好用、外部依赖少，从这一点上看现在的jQuery是必须慎用的。
  5. 可以尽量支持链式表达。例如obj2 = obj1.filt1().filt2().filt3()肯定优于右边的「代码段1」或「代码段2」。

「代码段1」

obj2 = obj1.filt1();
obj2 = obj2.filt2();
obj2 = obj2.filt3();

「代码段2」

obj2 = cls1_filt3(cls1_filt2(cls1_filt1(obj1)));
【热门文章】
【热门文章】