变量名是有害的

我没法论证, 从最近接触到的一些思想里感觉到变量名是不少问题的来源
若是要反驳, 至少看一下我文章里几个连接对应的演讲或者博客
另外若是把这个想法用在如今的编程上, 多半会是错的, 这篇文章只说想法

编程语言的熵

Joe Armstrong 老爷子在 StrangeLoop2014 有个演讲, 我转到微博了
http://weibo.com/1651843872/BnVdW8JTu
里边说到从前那样配置的电脑, 60ms 就能开机了, 如今的电脑反而要几秒几分钟
这些年已经有太多太多的代码了, 就像是熵增同样不可逆转
而内存上的状态数量, 简直比宇宙原子个数还要多, 因此程序员必然迫不得已

那么有没有什么办法, 把代码积累起来的混乱清除干净呢?
好比说经常使用的逻辑, 显然咱们重复了上千遍, 实际上它们应该是同样的
对这类代码, 是否能有一个工具, 将其分析简化到简单的结果呢?
然而像文件压缩同样, 老是有个极限, 取决于软件的熵, 也就是复杂度
变量名就是很明显的一个熵的来源, 其中包含了各类各样的信息
因而这条路往下就走不通了

演讲的意思听不大明白, 可是 Software Entropy 的概念说得很形象
另外一个相关的话题是破窗理论, 一旦代码中有混乱, 混乱很是容易扩大
回到变量名的问题上来, 我感到变量名确实带来了巨大的复杂度
编程语言早期想经过抽象符号来取代硬件地址, 可能自由度给得太大了
静态语言编译以后, 有的变量名会消失, 但还会有类型之类多种命名
动态语言当中, 变量名,方法名,数据字段名称, 充斥着整个运行时
此外还有事件, 文件, 网络等等各类能够有命名的复杂度的地方

存在变量名就须要考虑是否重名的问题, 甚至由重名形成的 bug
团队当中变量名也可能成为开发的成本, 由于须要制定规范达成统一
以及变量名增多之后, 管理变量名甚至成为软件复杂度的部分
虽然软件生长过程当中, 带来复杂度的因素不少, 好比业务, 平台, 框架
可是变量名复杂度的增加更像是其中特别浪费的一项

Backbone 绑定节点关系

我在写 Backbone 时有一个明显的例子, 就是在 View 当中须要定义变量名
这些变量名有若干个做用:

• 特殊的节点, 用于被 CSS 选择器选中以添加样式
• 被 jQuery 选择器选中, 执行 DOM 操做
• 做为监听事件的标识, 也是借助 jQuery

这些变量名有着实实在在的麻烦, 比较容易重名, 字符的数量也不少
另外让我比较难受的是, 借助已有技术, 大部分名字应该就是很容易去掉的:

• CSS 样式, 咱们在 Sketch 当中只有极少的变量, 样式就作好了
  样式一般和节点一一, 不值得大量选择器去概括样式
• DOM 操做, 在 React 当中能够自动完成, 并不须要手动制定标识用于更新
• 事件监听, 好比 React 当中, 或者早期的 ASP 的 onClick 写法,
  事件绑定也是和节点对应的, 用一个名字反而增长了成本
  还有一种手法是 iOS 当中经过拖拽控件进行绑定, 也能够省掉名称

这个例子里名称几乎都是为了帮助程序结构化, 强制使用的名字
由于拆分之后, 两个元素之间固有的关系被截断, 依靠名字才能从新创建
但这样拆分的成本就是须要人工维护大量的名词
React 内部实现中虽然用了字符串形式的 id, 但维护成本极少

函数式编程

函数式编程除了做为值的函数, 还有不可变数据, 还有隔离反作用等等
不可变数据 immutable 很是有意思, 由于作网页日常都是修改数据状态的
因此真的很难想象都是 Erlang 那样不可变还怎么编程
实际上总有办法的, 好比不断建立新的做用域以及拷贝变量等等
并且在特定的场景, 好比 React 当中, 不可变数据明显是很好的方案

数据不可变一样在并行编程当中, 用来保证数据一致性
数据不会被改变, 意味着数据随时能被缓存下来, 避免掉重复的计算
另外一方面, 数据不可变意味着对比数据是否相等只需对比内存地址
可变的数据, 好比 JavaScript 的对象, 对比就很是麻烦跟低效

接受不可变数据好处以后, 能够注意到, 变量正是数据改变的一个缘由
由于有个变量, 就存在一个指向相应区域的引用, 容易做为状态进行更改
假如没有变量, 就没有到数据的引用, 也就不能进行修改了

固然实际当中, Haskell 有变量但不能修改, Go 能够有常量
有变量名和可变并不对等, 甚至在 JavaScript 也可能设定属性只读
但我认为这样也存在一种机会, 假如去掉变量名, 程序会更直观

图形化编程

Chris Granger 有个采访里讲为何对于普通人来讲编程那么难
http://podcasts.thoughtbot.com/giantrobots/111
他发现, 做用域的概念对于非程序员来讲很难理解, 他们更习惯全局的域
好比电子表格当中进行计算, 直接在格子上计算就看到结果, 没有变量参与
还有数学公式, 全部的符号在全局都是一个意思, 并不为公式设置做用域

不过在他作的将来编程语言的草稿当中, 他调整的不止是做用域
在名字叫作 Aurora 的例子当中, 数据再也不以变量的形式传递, 看视频:
http://weibo.com/1651843872/AFf1b1EZ5
而是经过拖拽, 将数据引用到下方的表达式当中用在计算
在这样的环境当中, 变量名不存在, 用户看到的只有数据, 很是直接

这个在 Chris 另外一篇文章有提到, 就是编程为何复杂, 怎么解决?
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
有中文翻译, 原文大概更明确, 他认为主要是三点:

• 程序的过程是不可观察的
• 代码并非直观的
• 同时程序的算法会很复杂

另外有一点是工具的门槛, 每一个写代码的阶段都太慢, 但也许不算编程自己的问题
在 Aurora 当中, 由于没有变量, 人们看到的和理解的都是数据自己
因而程序的数据转化是很是直观的, 每个步骤都能看到

借助图形界面, 有更多状况下咱们能够简化掉编程当中不直观的概念
这一点在 Bret Victor 诸多的演讲当中能看出来
https://github.com/coffee-js/languages/wiki/Bret-Victor-Videos
原来咱们觉得须要代码才能输入逻辑, 实际上能够经过设计交互来实现
同时, 图形界面很是直观, 很难想象文字符号能如此易懂

过去的半个世纪, 编程的发展都是创建在文本的解析跟编译之上 少许的图形编程, 只是在特定的领域, 至今没有被大多数人使用 文本固然有着图形很难大到的抽象计算的表达能力, 但是, 图形交互丰富以后呢? 编程当中不少元素是解决问题固有的复杂度, 咱们很难再进行简化 但设计和管理变量名很大程度是编程方式形成的复杂度 当更好的方案被设计出来表达计算的逻辑, 变量名应该会淡出人们的视野