javascript - 这个问题是关于代码规范或者说代码习惯
大家讲道理
大家讲道理 2017-04-10 14:26:13
[JavaScript讨论组]

楼主是一名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个问题的能力,需要怎么加强?大家集思广益,如何才能写出高质量的代码,可以维护的代码。

大家讲道理
大家讲道理

光阴似箭催人老,日月如移越少年。

全部回复(3)
黄舟

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加到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啊……

PHPz

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

提到的三个例子:

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

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

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

热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责申明 举报中心 意见反馈 讲师合作 广告合作 最新更新
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送

Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号