ホームページ  >  に質問  >  本文

javascript - 如何写出优雅的前端程序?

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

高洛峰高洛峰2749日前427

全員に返信(4)返信します

  • 迷茫

    迷茫2017-04-10 13:13:17

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

    非JS特有

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

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

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

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

    JS特有

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

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

    • 明确语义,避免一切不明确意图的语法,如果可能尽量使用strict模式
    • 注意为变量创建副本,函数调用尤其要小心不要污染原参数
    • 小心命名,可以把名字简单的起长一点,最终一定要避免重写掉并非JS保留字的undefined, require, define等,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)));
    

    返事
    0
  • 大家讲道理

    大家讲道理2017-04-10 13:13:17

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

    返事
    0
  • PHP中文网

    PHP中文网2017-04-10 13:13:17

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

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

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

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

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

    所有符号各就各位
    第一眼的就是空格太少,我推荐三个工具:
    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,这是学习经验、共同提高 最快的办法。

    返事
    0
  • 高洛峰

    高洛峰2017-04-10 13:13:17

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

    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: 其实我是来测试 插入代码为啥不换行滴...

    返事
    0
  • キャンセル返事