變量名是有害的

我沒法論證, 從最近接觸到的一些思想裏感覺到變量名是不少問題的來源
若是要反駁, 至少看一下我文章裏幾個連接對應的演講或者博客
另外若是把這個想法用在如今的編程上, 多半會是錯的, 這篇文章只說想法

編程語言的熵

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
原來咱們覺得須要代碼才能輸入邏輯, 實際上能夠經過設計交互來實現
同時, 圖形界面很是直觀, 很難想象文字符號能如此易懂

過去的半個世紀, 編程的發展都是創建在文本的解析跟編譯之上 少許的圖形編程, 只是在特定的領域, 至今沒有被大多數人使用 文本固然有着圖形很難大到的抽象計算的表達能力, 但是, 圖形交互豐富以後呢? 編程當中不少元素是解決問題固有的複雜度, 咱們很難再進行簡化 但設計和管理變量名很大程度是編程方式形成的複雜度 當更好的方案被設計出來表達計算的邏輯, 變量名應該會淡出人們的視野