phpstudy集成环境

 首页 > 这个问题是关于代码规范或者说代码习惯

这个问题是关于代码规范或者说代码习惯

楼主是一名javascript coder,最近遇到一个问题，是关乎代码的规范和风格的，需要从业在代码领悟多年的大侠指点一二，望打通我的几根血脉，茅舍顿开。

说明：其实这个问题不好表达，也不好描述。

我思考了几天整理了一些问题，大致是：思维逻辑，代码规范，规范标准

1.思维逻辑
比如 1+2+3....100咱们写一个1加到100的代码：

function sum1(n){
    var n = 0;
    for(var i = 1; i <=n;i++){
        n = n + i;
    }
    return n;
}

function add(n){
    return (1+n)*n/2;
}

这属于 逻辑思维方面的，这2个都可以实现功能，但是第二种更加优美，简洁，这方面的能力需要怎么提高。

2.代码规范
比如：一个方法只用了一次，但是楼主深受ruby和asp影响，喜欢什么都写成方法，如：

function show(n){
    fn(n);
}

function fn(str){
    console.log(str)
}

完全可以写成这样：

function show(n){
    console.log(n);
}

我这是举例，我肯定不会因为一个console.log就单独写个方法，只是举例

3.规范标准
比如：什么时候用方法封装，依据是什么，什么时候应该把代码归类，比如 处理一组Img的方法，咱们应该：

var img = {
    getimg:function(){},
    setimg:function(){}
}

楼主对于上面3个问题的能力，需要怎么加强？大家集思广益，如何才能写出高质量的代码，可以维护的代码。

js 的 code style
https://github.com/airbnb/javascript
关于1，方法2某种意义上并不优美。很多问题无法用数学公式来表达，好算法才是重要的。
关于2，见开头，其中还列举了很多公司的code style
关于3，不可能有统一的依据，相关oo书籍可以提供思路，但并不存在银弹，否则就不会有那么多糟糕设计的项目了

关于第一点，数学能力在编程上的体现应该不是这个样子的。就好比这个李白喝酒的问题，固然可以用数学 组合数之类的来搞定，但做为程序员更应该掌握的是动态规划，因为组合数之类的数学技巧如果改改参数弄点小数点乃至无理数出来很容易就崩溃了。
如果说1加到100的话，那么程序员应该掌握的是map-reduce，而不是(1+n)*n/2，因为只有map-reduce才能同样适用于1000W条复杂记录的统计，(1+n)*n/2不行

第二点我觉得如果一个函数只会被用在一个地方，又给他起了个名字，那最好是有明确含义的，而且确实会需要改变他的行为的。console.log单独封一下我觉得很好，没啥问题。因为IE或者正式环境的情况下确实可能会要改这个行为

但这只是最好，并不强制，只要你封装函数没有多到影响代码理解的程度，我觉得都OK

第三点我觉得不能算纯粹的个人能力，应该是团队的能力。团队内部应该花时间讨论一套编码规范和风格，封装的惯例，粒度的选择等指导性原则，然后成员共同遵守并维护之。

最后我要顶一下被 @oyanglulu 踩的TDD。TDD对于Javascript来说相当重要，因为缺乏编译和类型安全机制，Javascript的代码重构尤其是公共代码的重构经常伴随著很大的风险，TDD是控制这种风险从而降低重构成本，提升代码质量的有力工具。

另外速读了一下那篇描述TPP的文章，通篇在描述怎么写正确地TDD啊……

最重要的原则是YAGNI(Ain't Gonna Need It), 如果没有要求就不要写多任何一个字, 这才是最clean的代码.

  1. 第一个实现其实更好,YAGNI算法,题意有让你用乘法么,根本没有任何东西trigger你想到要公式.这其实是过度设计,没有看出来哪里优美.
  2. 还是YAGNI
  3. 还是YAGNI
    总而言之,用最简单的实现目标,然后再TPP
    重构,重构的过程就会transform出你刚好需要的设计,而不是先设计

什么时候该 transform 呢,这个优先级会告诉你
({}–>nil) 无代码->nil
(nil->constant) nil搞不定上constant
(constant->constant+) 简单constant搞不定上复杂constant
(constant->scalar) constant还搞不定上变量
(statement->statements) 一句搞不定上多句.
(unconditional->if) 无状态语句搞不定上if
(scalar->array) 变量不行上数组
(array->container) 数组不行上容器
(statement->recursion) 语句搞不定上递归
(if->while) if不行上循环
(expression->function) 表达式不行换函数
(variable->assignment) 优先级最低的改变量值

ref: Uncle Bob的解释 http://blog.8thlight.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html

TDD is dead, long live TPP

tl;dr

  1. 算法
  2. 抽象
  3. 同2
  1. 第二种看着简洁，但未必永远都最好；在本例中当然是好的，大部分时候也应该是除了可读性之外都更优于第一种的，然而即使是第一种，好程序员也不应该写成那个样子，还有改善空间。说到可读性方面也要看受众：对于数学不好的的人，比如我，看第一种更容易明白。但对于数学基础扎实的人，第二种应该也没什么障碍吧。因此，若你追求第二种写法，就去提高用数学解决／表达问题的能力。这方面我很差，就不多扯了。
  2. 抽取更小粒度的方法是重构里最基础最常用的技巧，应否抽取是要看上下文的。基本上只要有可重用的机会，抽取出来就是 OK 的。你举的例子，我明白你的意思，但由于缺少上下文，所以无法说好与坏。现实中的选择，也是要取决于实际的代码环境，没有必然的规则。
  3. 第2条实际上是从一个方面体现了你的抽象思维能力，第3条也是类似的——从代码组织的层面。我觉得这方面的话题真是见仁见智，而且很多时候并不是自己决定就 OK 了，还得看身边的人。

说白了，你写的代码如果只是你自己看，你写成什么样都无所谓，只要它能用；如果糟糕的结构和组织性带来了性能和维护上的问题，你自然会慢慢改善它——但是好代码都不是一次写成的。另一方面，如果你不是只给自己看，你要考虑和团队之间的协作等问题，那么代码风格或规范之类的东西应该是来自整个团队的共识。有时候你不得不妥协退化，或者努力学习进步，一切都是为了让大家能够说“同一个宇宙的语言”，否则你会很痛苦，用不了多久就会心灰意冷。

题主应该是有受 Ruby 语言影响的人，上个月 RailsConf 开场时 DHH 作的 Keynote Presentation 不知道你看了没有？如果没有，去看看吧，你要的答案里面就有：Writing Software - RailsConf 2014 by DHH

原则(最先想到的两个): 简洁, 易读

提到的三个例子:

  1. 方法2简洁, 优美! 虽然没有方法1那么直观易读, 但对数学好点的同学应该问题不大...
  2. 如果是JS, 为什么不试试 var show = console.log ?
  3. 封装的目的是重用, 需要重用的时候就要考虑封装了...

题主说的三点都不算规范吧, 感觉像设计...

水平有限, 大神轻喷...

经验不丰富，因此没法给题主太好的建议，但是最近在阅读一本书，我认为对规范代码很有益处。
《clean code》 - 中文名为 《代码整洁之道》
PDF 版下载地址：http://pan.baidu.com/s/1mg2Ym1M
豆瓣书评地址：http://book.douban.com/subject/3032825/

最近还总结了一篇这方面的博文：《浅谈代码整洁之道》
当然写得很肤浅，希望能与题主一起交流下这方面的心得和体会。:)

还有在这方面我觉得我的好朋友 - @公子 很有想法，公子是我在 PHP 方面的学习榜样，也是我在代码规范方面的引路人，我觉得可以邀请他来给些建议。

【热门文章】
【热门文章】