程序員們總說的代碼要優雅，這個優雅到底指什麼？

01-08

程序員們總說的代碼要優雅，這個優雅到底指什麼？

一直很信奉一句話：優雅介面，骯髒實現。

就跟寫作文一樣，字跡要工整，分段要合理，條理要清晰，要言簡意賅，不說廢話。

儘可能少地減少嵌套

儘可能少地定義變數

儘可能少地傳遞參數

儘可能短地命名變數

相似代碼只出現一次

每一行代碼長度一致

打開文件，沒有或者很少嵌套，if else，for，縮進，這些都直觀得說明所看到的各語句在相同或者接近的抽象層次上（abstraction level），比如非常常見的執行邏輯

items = getItems() A


validItems : array =   B

for (... items ...) {

  isValid? = ....

  if (isValid) {

    validItems.push(item)

  } else {

   ....

  }

}

render(validItems) C

稍稍改一下B，把for循環移除掉

validItems = items.filter(item =&> { isValid? = ... ... })

改過後，讀到這句的時候整體感更強了，代碼的意圖也更加明顯，所以可以說「優雅一點」了。

不過，外面的代碼只關心從items里取到符合條件的item放到validItems里， for循環和filter里的都是細節，不應該暴露與A和C暴露在一個層次上的。

如果把取validItems的細節全部隱藏起來：

items = getItems() validItems = getValidItems(items) render(validItems)

讀這三句代碼就沒有思維切換和打斷，沒有顛簸感，代碼更「平整流暢」。 —— 這就是「優雅」，tight，concise，clear。

所以，這是優雅的：

把大象拿起來（）打開冰箱門（）把大象放進冰箱（）關上冰箱門（）

節制，說得不多，也一點不少，不過度暴露，就像一個有修養的女士。

* 支持你自己（https://www.linkev.com/?a_aid=itlr）

The Zen of Python

Python 之禪

Beautiful is better than ugly.

美勝於丑

Explicit is better than implicit.

顯勝於隱

Simple is better than complex.

簡勝於繁

Complex is better than complicated.

繁勝於雜

Flat is better than nested.

平勝於迭

Sparse is better than dense.

疏勝於密

Readability counts.

讀勝於寫

Special cases aren"t special enough to break the rules.

規則勝於特例

Although practicality beats purity.

實用勝於單純

Errors should never pass silently.

告錯勝於沉默

Unless explicitly silenced.

沉默勝於吵鬧

In the face of ambiguity, refuse the temptation to guess.

拒絕勝於猜測

There should be one-- and preferably only one --obvious way to do it.

唯一勝於顯然

Although that way may not be obvious at first unless you"re Dutch.

顯然不是荷蘭

Now is better than never.

現在勝於永不

Although never is often better than *right* now.

永不勝於匆猝

If the implementation is hard to explain, it"s a bad idea.

凡值得說,必易於說

If the implementation is easy to explain, it may be a good idea.

反之則不然

Namespaces are one honking great idea -- let"s do more of those!

名可名, 請常名

首先要遵守團隊約定的代碼風格
能做到自解釋，即不需要注釋
優雅的代碼實現後，這段代碼不能增不能減。這一點比較偏向完美。

每一個寄存器都是有它特定的作用的！自從32位彙編以來就禮崩樂壞了，你們這些異端！

優雅是和你自身的審美水平有關的, 從我的感受來看, 第一階段是看起來優雅: 比如變數名, 縮進, 文件組織, 等等都是合理一致等; 第二階段是隨著你審美水平的提升, 你對於一些非表象的代碼也有了區別美醜的能力, 比如你對低效的代碼的敏感: 多餘的分支判斷, 不合理的分支排放順序, Cache不友好的操作, 調用了低效的函數等; 那麼終極階段也就是第三階段: 你對於怎麼做才是最優雅的有了一些敏感度, 我想不出什麼好的例子, 就舉個"特別"不恰當的例子, 比如使用了JS去寫一個日誌文件處理函數, 這無論你的JS寫的多優雅, 這個事情本身就是不優雅的. 以上是我的一些個人看法, 有反對意見的隨便來評, 你們開心就好

優秀的程序員們能通過優雅的代碼互相感受到對方的思考、靈感和審美

我所理解的代碼優雅就是，自己看著段落清楚，意義明白，別人看著沒有障礙，益於修改！

我想這跟數學家要求數學證明也要優雅差不多。英國數學家 Hardy 曾經說，there is no permanent place in the world for ugly mathematics.

我想人類經過百萬年進化出來的心智和認知，對於什麼是美，我們雖然難以形容，但是見到都能夠認出。就好像人體的美、自然的美、音樂的美，乃至數學證明的美，代碼的美。生而為人，我們天然能夠感知。

我記得一個學建築的朋友曾經跟我說，一個建築，如果看著是不美的，那麼幾乎肯定不是一個好的設計。

簡潔，方便debug

換行。

噪音少就是優雅。當然了，這並不一定會讓沒有受過正確教育的人更容易理解。

自己開心，別人開心

看來第一個例子爭議很大。這個例子說的是「能用一個函數完成的功能不要分成兩個，而且這兩個函數代碼90%都是重複的」。為了更能說明問題，換個函數名稱吧。

－－－－－－－－

舉例子

**不優雅的**

void navigateToHome(); void navigateToEnd();

優雅的

void navigateTo(const Place* place);

不優雅的

... if(user != NULL) showWindow(true); else showWindow(false); ...

優雅的

showWindow(user!=NULL);

不優雅的

if (cond1) { if (cond2) { /* code */ // do something ... } else { return; } } else { return; }

優雅的

if (!cond1) return;


if (!cond2)

    return;

// do something...

不優雅的

bool enabled; ... if(enabled==true) { // do something }

優雅的

if(enabled) { // do something }

不優雅的

void foo (int a, int b, char c, long d, long e, int f);

優雅的

struct _FOOArg { int a, int b, char c, long d, long e, int f, };

void foo(const struct _FOOArg* arg);

to be continued...

不能像東野圭吾寫的小說似的那麼優雅，他的優雅我們不懂！

感覺很難具體定義這個優雅。

相傳白居易的詩，能讓不識字的老奶奶讀懂。

我認為的優雅就是能讓普通人一看就明白這是在做什麼。

另外，我信奉的信條是：代碼是用來讀的，是用來交流思想的，不只是用來運行的。

對於模式控，你得把23個模式都用全了才叫優雅。

對於模板控，你得從類到函數，全都上模板才叫優雅。

對於文檔控，你得給每個類，每個函數和每個成員寫上注釋才叫優雅。

對於C控，你得寫出嵌套超過10層的宏才叫優雅。

對於python控，你得用上超過30個開源庫才叫優雅。

對於PHP控，你得寫出誰都看不懂，但就是能幹活的代碼才叫優雅。

代碼整潔和代碼簡潔

是程序員畢生的追求

看似容易，實則很難

相同的功能怎麼用最少的代碼實現，並且又容易讀懂？背後需要的是強大的功底和歲月的積累！

做到這兩條，代碼想不優雅都難