V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
noli
V2EX  ›  程序员

[收铜币] 什么时候变量起名长一点好?什么时候短一点好?

  •  
  •   noli · 2017-11-01 01:02:57 +08:00 · 4049 次点击
    这是一个创建于 2609 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我觉得有些时候起短一点好,例如写一些非常像数学中的函数的代码的时候。

    例如像

    var product = 
        from x in alst
        from y in blst
        select x * y ;
    
    product = [x * y for y in blst for x in alst]
    

    但有些时候,你又恨不得名字越清晰越明确越好。 例如据某位大 v 说他最近在搞一些 Windows 内核的代码,所有变量名都是辅音字母完全没有元音,

    例如(随便乱编的 ) wwMgrCtxKSz => windowsManagerContextKeySize

    集思广益,说说你现在写的代码大概是什么领域的,喜欢起名长一点还是短一点?

    36 条回复    2018-06-21 13:26:49 +08:00
    changwei
        1
    changwei  
       2017-11-01 02:47:01 +08:00 via Android
    如果是写 java,变量名可以写长一点。

    如果是写脚本语言,变量名可以写短一点。
    xiaowei4895
        2
    xiaowei4895  
       2017-11-01 03:24:29 +08:00
    支持都写长一点,理解起来直接易懂。
    andrewpsy
        3
    andrewpsy  
       2017-11-01 03:57:48 +08:00
    你例子里面的 alst 和 blst 尽量不要缩写。

    1. aList 才几个字母,alst 只节省了一个字母的空间却需要打出 lst 这种不熟悉的字母组合,而且看的时候脑子还要猜一下 lst 是 list 吧。
    2. 缩写尽量发生在 context 清晰的情况下,比如你的函数里 new 了个 class WindowsManagerContext,这个实例在你的函数里可以被缩写成 wmc 而不会引起大的困扰。
    3. 临时变量和众所周知的缩写用起来不需要太顾忌,比如 i,j,idx 等等。
    4. 尽量少用缩写,因为我喜欢 Zen of Python 的第二行:explicit is better than implicit。

    我很喜欢 Zen of Python 里面大部分条例。
    https://www.python.org/dev/peps/pep-0020/
    laoyur
        4
    laoyur  
       2017-11-01 06:55:16 +08:00   ❤️ 4
    默默地搜出了不久前写的最长的一个函数名:
    get_today_activity_count_for_accounts_created_in_the_day_of_n_days_ago_from_redis_cache
    linuxsteam
        5
    linuxsteam  
       2017-11-01 07:06:42 +08:00 via Android
    。。。
    linuxsteam
        6
    linuxsteam  
       2017-11-01 07:06:58 +08:00 via Android
    英文就好。
    q397064399
        7
    q397064399  
       2017-11-01 07:18:31 +08:00   ❤️ 1
    @laoyur #4 哈哈,没毛病,不过设计上有点问题,
    客户代码最好应该拿到三个接口

    首先是获得今天的活跃的账户集合,
    然后是获得 获得从某一天到某一天创建的账户集合,
    Redis 是实现细节,不要耦合进来,如果后续有其他的需求,例如不从 Redisi 里面取了 ,可以减少改动

    客户代码抽象的讲就是一个取并集的操作
    laoyur
        8
    laoyur  
       2017-11-01 07:52:54 +08:00
    @q397064399 #7 感谢指正
    内部项目,有从 db 直接 kiang 数据的版本,性能太屎就又搞了个 redis 的版本,旧接口还保留,不想去改动
    这个相当于一个工具函数,必须一记头搞定,不用分那么细
    q397064399
        9
    q397064399  
       2017-11-01 08:00:30 +08:00
    @laoyur #8 最近在公司里面 写代码 一些感想,
    对于业务来讲, 数据源跟数据源 拆分得越细,越明确越好, 这些都是描述这个逻辑的细节,
    业务逻辑最好只要干业务逻辑的事情,这样以后改起来也方便, 例如把 today_activity 变成了 last_three_day_activity
    dangyuluo
        10
    dangyuluo  
       2017-11-01 08:01:17 +08:00
    写代码定义变量以_开始,有一种系统底层的感觉
    mcfog
        11
    mcfog  
       2017-11-01 08:11:39 +08:00 via Android   ❤️ 1
    不管什么领域什么语言,也不管是变量还是类 /函数 /成员 /结构体等等,名字的长短应该和这个名字生效的 scope 正相关

    一行的 lambda/表达式的作用域里用单字母一点问题没有,反过来用几十个字母长的名字反而不舒服

    但只要,scope 超过 10 行,就应该老老实实写完整,如果是 global 的,更应该啰嗦一点

    另外除了语言层面的 scope,这里其实也应该考虑实际开发者 /项目层面,比如个人的 toy project 到公司的业务项目到开源项目,名字应该趋向越来越长,缩写的约定应该越来越少
    jeneser
        12
    jeneser  
       2017-11-01 08:14:19 +08:00 via Android
    JavaScript: 一直坚持写长的,毕竟是写给别人看的。如果需要,实际上线就用工具丑化压缩一下。
    purezhang
        13
    purezhang  
       2017-11-01 08:23:01 +08:00 via iPhone
    学习了
    ioven
        14
    ioven  
       2017-11-01 08:43:03 +08:00   ❤️ 2
    看作用域,范围越大变量名越长,反之范围越小变量名越短
    yulitian888
        15
    yulitian888  
       2017-11-01 08:56:27 +08:00
    名字有用长短来分辨好坏的吗?
    如果是的话,混淆器岂不是最佳短名方案?反之,按脸滚键盘就是最佳长名方案喽...
    可读性才是唯一标准!
    hadixlin
        16
    hadixlin  
       2017-11-01 09:00:50 +08:00 via iPhone
    @ioven 同意根据作用域决定长短的观点,比较科学
    hadixlin
        17
    hadixlin  
       2017-11-01 09:11:00 +08:00 via iPhone
    变量名起的好可以提升可读性,让人一眼知道这个变量表示什么最重要,变量声明语句是最能体现变量是什么的语句。如果变量的作用域比较大,那么意味着使用变量的地方离声明语句可能很远,读者往往需要回到声明语句才能确认变量意义,思维跳跃,所以需要信息更完整的(长)的名字。变量作用域小的情况与之相反。当使用一个变量的时候,考虑是否可以不通过看声明语句记起变量含意,如果不能就重构,增加变量名含意信息。变量名也是需要反复推敲的,也是重构的一部分。
    lwbjing
        18
    lwbjing  
       2017-11-01 09:13:15 +08:00
    @laoyur 再长点我的屏幕就要放不下了,哈哈。。
    hnbcinfo
        19
    hnbcinfo  
       2017-11-01 09:22:17 +08:00   ❤️ 1
    yinzishao17
        20
    yinzishao17  
       2017-11-01 09:44:35 +08:00
    没错,本地变量可以用短的,但是其他还是描述得更清楚,方便以后代码阅读和维护。而且,缩写应该也有一套规律,而不是想怎么缩就怎么缩
    AscenZ
        21
    AscenZ  
       2017-11-01 09:58:19 +08:00
    外面写长的,能顾名思义的
    一些代码块里面的可以写短的,例如 for 循环里面可以用单字母都行
    感觉和#19 差不多
    microhz
        22
    microhz  
       2017-11-01 10:27:43 +08:00
    长一点无所谓,意思一定要明确合理
    sorra
        23
    sorra  
       2017-11-01 11:00:55 +08:00
    需要设定一些合适的概括性的名字,一词顶五词,以解决变量名膨胀的问题。
    xa0082249956
        24
    xa0082249956  
       2017-11-01 12:09:07 +08:00 via Android
    作为一名 OIer 我发现我周围的人变量名 /函数名都是 x, y, z, a, b, c …而我都是… FindBestAns 什么的……但是或许这种时候短一点比较好?但是短一点我自己容易乱…
    saran
        25
    saran  
       2017-11-01 12:12:38 +08:00 via Android
    随心情
    wweir
        26
    wweir  
       2017-11-01 13:21:52 +08:00
    很多时候看到名字过长,需要的并不是缩写,而是从架构、功能等角度做一个更高层次的抽象。
    比如 #4,可能给我起名的话,会叫做 get_new_accounts_activity_counts,然后在隔壁加个注释,表明具体的内容。
    一直坚持,函数(变量)名是用来快速找到他的一个标识,用来表明它是做什么的,而不是要表明它具体做了什么

    缩写的话,很小的 scope 内使用的变量名,爱怎么缩写怎么缩写。作用域越大,变量名越要起好,避免缩写。
    jswh
        27
    jswh  
       2017-11-01 14:14:40 +08:00
    个人觉得变量名 /函数名在遵循团队规范的情况下,只有一个原则,如果你是第一次读这段代码,在不用注释的情况下能不能最大程度地理解要实现的功能。
    msg7086
        28
    msg7086  
       2017-11-01 14:30:19 +08:00
    逻辑复杂的时候我还会把一段逻辑直接扔进一个方法里,用方法调用代替变量名。
    siyang1982
        29
    siyang1982  
       2017-11-01 14:45:17 +08:00
    有 IDE,项目接触人多,不熟,或时间跨度长但接触频率不高的,可以长些。
    主要是为搜起来方便。
    siyang1982
        30
    siyang1982  
       2017-11-01 14:49:40 +08:00
    短的最大优点是,选择恰当的词有难度,在绞尽脑汁取名时,对其作用进行更深的思考。
    chenyu8674
        31
    chenyu8674  
       2017-11-01 15:28:17 +08:00
    局部变量 ijkxyz 漫天飞也无所谓,全局和函数名尽量做到通过名称能直接看出意义
    不然俩月后自己都不知道自己写的啥,别问我怎么知道的
    shenhongbang
        32
    shenhongbang  
       2017-11-01 16:32:07 +08:00
    长短应该和作用域成正比吧
    zjsxwc
        33
    zjsxwc  
       2017-11-01 16:39:50 +08:00
    写能让一年后的自己看得懂得变量名
    Easzz
        34
    Easzz  
       2017-11-01 16:55:05 +08:00
    我觉得长一点没关系吧,最重要的知道这个变量是什么意思。好的命名是自解释的,而不需要注释。
    woscaizi
        35
    woscaizi  
       2017-11-06 13:28:22 +08:00
    @laoyur 我们都驼峰。
    ShineSmile
        36
    ShineSmile  
       2018-06-21 13:26:49 +08:00
    参见变量作用域。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   876 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 21:48 · PVG 05:48 · LAX 13:48 · JFK 16:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.