少妇精品毛片aaaa在线观看,国产极品高清无码

[導(dǎo)讀]來源：碼洞下面的這篇文章內(nèi)容由中國最具爭議性的計算機(jī)天才王垠老師精心創(chuàng)作，可謂字字珠璣用心苦良，文章篇幅較長，希望大家能認(rèn)真閱讀，值得收藏。?編程是一種創(chuàng)造性的工作，是一門藝術(shù)。精通任何一門藝術(shù)，都需要很多的練習(xí)和領(lǐng)悟，所以這里提出的“智慧”，并不是號稱一天瘦十斤的減肥藥，它并不...

來源：碼洞

下面的這篇文章內(nèi)容由中國最具爭議性的計算機(jī)天才王垠老師精心創(chuàng)作，可謂字字珠璣用心苦良，文章篇幅較長，希望大家能認(rèn)真閱讀，值得收藏。?

編程是一種創(chuàng)造性的工作，是一門藝術(shù)。精通任何一門藝術(shù)，都需要很多的練習(xí)和領(lǐng)悟，所以這里提出的“智慧”，并不是號稱一天瘦十斤的減肥藥，它并不能代替你自己的勤奮。然而由于軟件行業(yè)喜歡標(biāo)新立異，喜歡把簡單的事情搞復(fù)雜，我希望這些文字能給迷惑中的人們指出一些正確的方向，讓他們少走一些彎路，基本做到一分耕耘一分收獲。

>>>>?

反復(fù)推敲代碼

有些人喜歡炫耀自己寫了多少多少萬行的代碼，仿佛代碼的數(shù)量是衡量編程水平的標(biāo)準(zhǔn)。然而，如果你總是匆匆寫出代碼，卻從來不回頭去推敲，修改和提煉，其實是不可能提高編程水平的。你會制造出越來越多平庸甚至糟糕的代碼。在這種意義上，很多人所謂的“工作經(jīng)驗”，跟他代碼的質(zhì)量其實不一定成正比。如果有幾十年的工作經(jīng)驗，卻從來不回頭去提煉和反思自己的代碼，那么他也許還不如一個只有一兩年經(jīng)驗，卻喜歡反復(fù)推敲，仔細(xì)領(lǐng)悟的人。

有位文豪說得好：“看一個作家的水平，不是看他發(fā)表了多少文字，而要看他的廢紙簍里扔掉了多少。” 我覺得同樣的理論適用于編程。好的程序員，他們刪掉的代碼，比留下來的還要多很多。如果你看見一個人寫了很多代碼，卻沒有刪掉多少，那他的代碼一定有很多垃圾。

就像文學(xué)作品一樣，代碼是不可能一蹴而就的。靈感似乎總是零零星星，陸陸續(xù)續(xù)到來的。任何人都不可能一筆呵成，就算再厲害的程序員，也需要經(jīng)過一段時間，才能發(fā)現(xiàn)最簡單優(yōu)雅的寫法。有時候你反復(fù)提煉一段代碼，覺得到了頂峰，沒法再改進(jìn)了，可是過了幾個月再回頭來看，又發(fā)現(xiàn)好多可以改進(jìn)和簡化的地方。這跟寫文章一模一樣，回頭看幾個月或者幾年前寫的東西，你總能發(fā)現(xiàn)一些改進(jìn)。

所以如果反復(fù)提煉代碼已經(jīng)不再有進(jìn)展，那么你可以暫時把它放下。過幾個星期或者幾個月再回頭來看，也許就有煥然一新的靈感。這樣反反復(fù)復(fù)很多次之后，你就積累起了靈感和智慧，從而能夠在遇到新問題的時候直接朝正確，或者接近正確的方向前進(jìn)。

寫優(yōu)雅的代碼

人們都討厭“面條代碼”（spaghetti code），因為它就像面條一樣繞來繞去，沒法理清頭緒。那么優(yōu)雅的代碼一般是什么形狀的呢？經(jīng)過多年的觀察，我發(fā)現(xiàn)優(yōu)雅的代碼，在形狀上有一些明顯的特征。

如果我們忽略具體的內(nèi)容，從大體結(jié)構(gòu)上來看，優(yōu)雅的代碼看起來就像是一些整整齊齊，套在一起的盒子。如果跟整理房間做一個類比，就很容易理解。如果你把所有物品都丟在一個很大的抽屜里，那么它們就會全都混在一起。你就很難整理，很難迅速的找到需要的東西。但是如果你在抽屜里再放幾個小盒子，把物品分門別類放進(jìn)去，那么它們就不會到處亂跑，你就可以比較容易的找到和管理它們。

優(yōu)雅的代碼的另一個特征是，它的邏輯大體上看起來，是枝丫分明的樹狀結(jié)構(gòu)（tree）。這是因為程序所做的幾乎一切事情，都是信息的傳遞和分支。你可以把代碼看成是一個電路，電流經(jīng)過導(dǎo)線，分流或者匯合。如果你是這樣思考的，你的代碼里就會比較少出現(xiàn)只有一個分支的if語句，它看起來就會像這個樣子：

if (...) {
?if (...) {
? ?...
?} else {
? ?...
?}
} else if (...) {
?...
} else {
?...
}

注意到了嗎？在我的代碼里面，if語句幾乎總是有兩個分支。它們有可能嵌套，有多層的縮進(jìn)，而且else分支里面有可能出現(xiàn)少量重復(fù)的代碼。然而這樣的結(jié)構(gòu)，邏輯卻非常嚴(yán)密和清晰。在后面我會告訴你為什么if語句最好有兩個分支。

寫模塊化的代碼

有些人吵著鬧著要讓程序“模塊化”，結(jié)果他們的做法是把代碼分部到多個文件和目錄里面，然后把這些目錄或者文件叫做“module”。他們甚至把這些目錄分放在不同的VCS repo里面。結(jié)果這樣的作法并沒有帶來合作的流暢，而是帶來了許多的麻煩。這是因為他們其實并不理解什么叫做“模塊”，膚淺的把代碼切割開來，分放在不同的位置，其實非但不能達(dá)到模塊化的目的，而且制造了不必要的麻煩。

真正的模塊化，并不是文本意義上的，而是邏輯意義上的。一個模塊應(yīng)該像一個電路芯片，它有定義良好的輸入和輸出。實際上一種很好的模塊化方法早已經(jīng)存在，它的名字叫做“函數(shù)”。每一個函數(shù)都有明確的輸入（參數(shù)）和輸出（返回值），同一個文件里可以包含多個函數(shù)，所以你其實根本不需要把代碼分開在多個文件或者目錄里面，同樣可以完成代碼的模塊化。我可以把代碼全都寫在同一個文件里，卻仍然是非常模塊化的代碼。

想要達(dá)到很好的模塊化，你需要做到以下幾點：

避免寫太長的函數(shù)。如果發(fā)現(xiàn)函數(shù)太大了，就應(yīng)該把它拆分成幾個更小的。通常我寫的函數(shù)長度都不超過40行。對比一下，一般筆記本電腦屏幕所能容納的代碼行數(shù)是50行。我可以一目了然的看見一個40行的函數(shù)，而不需要滾屏。只有40行而不是50行的原因是，我的眼球不轉(zhuǎn)的話，最大的視角只看得到40行代碼。
如果我看代碼不轉(zhuǎn)眼球的話，我就能把整片代碼完整的映射到我的視覺神經(jīng)里，這樣就算忽然閉上眼睛，我也能看得見這段代碼。我發(fā)現(xiàn)閉上眼睛的時候，大腦能夠更加有效地處理代碼，你能想象這段代碼可以變成什么其它的形狀。40行并不是一個很大的限制，因為函數(shù)里面比較復(fù)雜的部分，往往早就被我提取出去，做成了更小的函數(shù)，然后從原來的函數(shù)里面調(diào)用。
制造小的工具函數(shù)。如果你仔細(xì)觀察代碼，就會發(fā)現(xiàn)其實里面有很多的重復(fù)。這些常用的代碼，不管它有多短，提取出去做成函數(shù)，都可能是會有好處的。有些幫助函數(shù)也許就只有兩行，然而它們卻能大大簡化主要函數(shù)里面的邏輯。
有些人不喜歡使用小的函數(shù)，因為他們想避免函數(shù)調(diào)用的開銷，結(jié)果他們寫出幾百行之大的函數(shù)。這是一種過時的觀念?，F(xiàn)代的編譯器都能自動的把小的函數(shù)內(nèi)聯(lián)（inline）到調(diào)用它的地方，所以根本不產(chǎn)生函數(shù)調(diào)用，也就不會產(chǎn)生任何多余的開銷。
同樣的一些人，也愛使用宏（macro）來代替小函數(shù)，這也是一種過時的觀念。在早期的C語言編譯器里，只有宏是靜態(tài)“內(nèi)聯(lián)”的，所以他們使用宏，其實是為了達(dá)到內(nèi)聯(lián)的目的。然而能否內(nèi)聯(lián)，其實并不是宏與函數(shù)的根本區(qū)別。宏與函數(shù)有著巨大的區(qū)別（這個我以后再講），應(yīng)該盡量避免使用宏。為了內(nèi)聯(lián)而使用宏，其實是濫用了宏，這會引起各種各樣的麻煩，比如使程序難以理解，難以調(diào)試，容易出錯等等。
每個函數(shù)只做一件簡單的事情。有些人喜歡制造一些“通用”的函數(shù)，既可以做這個又可以做那個，它的內(nèi)部依據(jù)某些變量和條件，來“選擇”這個函數(shù)所要做的事情。比如，你也許寫出這樣的函數(shù)：
void foo() {
?if (getOS().equals("MacOS")) {
? ?a();
?} else {
? ?b();
?}
?c();
?if (getOS().equals("MacOS")) {
? ?d();
?} else {
? ?e();
?}
}
寫這個函數(shù)的人，根據(jù)系統(tǒng)是否為“MacOS”來做不同的事情。你可以看出這個函數(shù)里，其實只有c()是兩種系統(tǒng)共有的，而其它的a(), b(), d(), e()都屬于不同的分支。
這種“復(fù)用”其實是有害的。如果一個函數(shù)可能做兩種事情，它們之間共同點少于它們的不同點，那你最好就寫兩個不同的函數(shù)，否則這個函數(shù)的邏輯就不會很清晰，容易出現(xiàn)錯誤。其實，上面這個函數(shù)可以改寫成兩個函數(shù)：
void fooMacOS() {
?a();
?c();
?d();
}
和
void fooOther() {
?b();
?c();
?e();
}
如果你發(fā)現(xiàn)兩件事情大部分內(nèi)容相同，只有少數(shù)不同，多半時候你可以把相同的部分提取出去，做成一個輔助函數(shù)。比如，如果你有個函數(shù)是這樣：
void foo() {
?a();
?b()
?c();
?if (getOS().equals("MacOS")) {
? ?d();
?} else {
? ?e();
?}
}
其中a()，b()，c()都是一樣的，只有d()和e()根據(jù)系統(tǒng)有所不同。那么你可以把a(bǔ)()，b()，c()提取出去：
void preFoo() {
?a();
?b()
?c();
然后制造兩個函數(shù)：
void fooMacOS() {
?preFoo();
?d();
}
和
void fooOther() {
?preFoo();
?e();
}
這樣一來，我們既共享了代碼，又做到了每個函數(shù)只做一件簡單的事情。這樣的代碼，邏輯就更加清晰。
避免使用全局變量和類成員（class member）來傳遞信息，盡量使用局部變量和參數(shù)。有些人寫代碼，經(jīng)常用類成員來傳遞信息，就像這樣：
class A {
? String x;

? void findX() {
? ? ?...
? ? ?x = ...;
? }

? void foo() {
? ? findX();
? ? ...
? ? print(x);
? }
}
首先，他使用findX()，把一個值寫入成員x。然后，使用x的值。這樣，x就變成了findX和print之間的數(shù)據(jù)通道。由于x屬于class A，這樣程序就失去了模塊化的結(jié)構(gòu)。由于這兩個函數(shù)依賴于成員x，它們不再有明確的輸入和輸出，而是依賴全局的數(shù)據(jù)。findX和foo不再能夠離開class A而存在，而且由于類成員還有可能被其他代碼改變，代碼變得難以理解，難以確保正確性。
如果你使用局部變量而不是類成員來傳遞信息，那么這兩個函數(shù)就不需要依賴于某一個class，而且更加容易理解，不易出錯：
String findX() {
? ?...
? ?x = ...;
? ?return x;
}
void foo() {
? String x = findX();
? print(x);
}

寫可讀的代碼

有些人以為寫很多注釋就可以讓代碼更加可讀，然而卻發(fā)現(xiàn)事與愿違。注釋不但沒能讓代碼變得可讀，反而由于大量的注釋充斥在代碼中間，讓程序變得障眼難讀。而且代碼的邏輯一旦修改，就會有很多的注釋變得過時，需要更新。修改注釋是相當(dāng)大的負(fù)擔(dān)，所以大量的注釋，反而成為了妨礙改進(jìn)代碼的絆腳石。

實際上，真正優(yōu)雅可讀的代碼，是幾乎不需要注釋的。如果你發(fā)現(xiàn)需要寫很多注釋，那么你的代碼肯定是含混晦澀，邏輯不清晰的。其實，程序語言相比自然語言，是更加強(qiáng)大而嚴(yán)謹(jǐn)?shù)模鋵嵕哂凶匀徽Z言最主要的元素：主語，謂語，賓語，名詞，動詞，如果，那么，否則，是，不是，…… 所以如果你充分利用了程序語言的表達(dá)能力，你完全可以用程序本身來表達(dá)它到底在干什么，而不需要自然語言的輔助。

有少數(shù)的時候，你也許會為了繞過其他一些代碼的設(shè)計問題，采用一些違反直覺的作法。這時候你可以使用很短注釋，說明為什么要寫成那奇怪的樣子。這樣的情況應(yīng)該少出現(xiàn)，否則這意味著整個代碼的設(shè)計都有問題。

如果沒能合理利用程序語言提供的優(yōu)勢，你會發(fā)現(xiàn)程序還是很難懂，以至于需要寫注釋。所以我現(xiàn)在告訴你一些要點，也許可以幫助你大大減少寫注釋的必要：

使用有意義的函數(shù)和變量名字。如果你的函數(shù)和變量的名字，能夠切實的描述它們的邏輯，那么你就不需要寫注釋來解釋它在干什么。比如：
// put elephant1 into fridge2
put(elephant1, fridge2);
由于我的函數(shù)名put，加上兩個有意義的變量名elephant1和fridge2，已經(jīng)說明了這是在干什么（把大象放進(jìn)冰箱），所以上面那句注釋完全沒有必要。
局部變量應(yīng)該盡量接近使用它的地方。有些人喜歡在函數(shù)最開頭定義很多局部變量，然后在下面很遠(yuǎn)的地方使用它，就像這個樣子：
void foo() {
?int index = ...;
?...
?...
?bar(index);
?...
}
由于這中間都沒有使用過index，也沒有改變過它所依賴的數(shù)據(jù)，所以這個變量定義，其實可以挪到接近使用它的地方：
void foo() {
?...
?...
?int index = ...;
?bar(index);
?...
}
這樣讀者看到bar(index)，不需要向上看很遠(yuǎn)就能發(fā)現(xiàn)index是如何算出來的。而且這種短距離，可以加強(qiáng)讀者對于這里的“計算順序”的理解。否則如果index在頂上，讀者可能會懷疑，它其實保存了某種會變化的數(shù)據(jù)，或者它后來又被修改過。如果index放在下面，讀者就清楚的知道，index并不是保存了什么可變的值，而且它算出來之后就沒變過。
如果你看透了局部變量的本質(zhì)——它們就是電路里的導(dǎo)線，那你就能更好的理解近距離的好處。變量定義離用的地方越近，導(dǎo)線的長度就越短。你不需要摸著一根導(dǎo)線，繞來繞去找很遠(yuǎn)，就能發(fā)現(xiàn)接收它的端口，這樣的電路就更容易理解。
局部變量名字應(yīng)該簡短。這貌似跟第一點相沖突，簡短的變量名怎么可能有意義呢？注意我這里說的是局部變量，因為它們處于局部，再加上第2點已經(jīng)把它放到離使用位置盡量近的地方，所以根據(jù)上下文你就會容易知道它的意思：
比如，你有一個局部變量，表示一個操作是否成功：
boolean successInDeleteFile = deleteFile("foo.txt");
if (successInDeleteFile) {
?...
} else {
?...
}
這個局部變量successInDeleteFile大可不必這么啰嗦。因為它只用過一次，而且用它的地方就在下面一行，所以讀者可以輕松發(fā)現(xiàn)它是deleteFile返回的結(jié)果。如果你把它改名為success，其實讀者根據(jù)一點上下文，也知道它表示”success in deleteFile”。所以你可以把它改成這樣：
boolean success = deleteFile("foo.txt");
if (success) {
?...
} else {
?...
}
這樣的寫法不但沒漏掉任何有用的語義信息，而且更加易讀。successInDeleteFile這種“camelCase”，如果超過了三個單詞連在一起，其實是很礙眼的東西。所以如果你能用一個單詞表示同樣的意義，那當(dāng)然更好。
不要重用局部變量。很多人寫代碼不喜歡定義新的局部變量，而喜歡“重用”同一個局部變量，通過反復(fù)對它們進(jìn)行賦值，來表示完全不同意思。比如這樣寫：
String msg;
if (...) {
?msg = "succeed";
?log.info(msg);
} else {
?msg = "failed";
?log.info(msg);
}
雖然這樣在邏輯上是沒有問題的，然而卻不易理解，容易混淆。變量msg兩次被賦值，表示完全不同的兩個值。它們立即被log.info使用，沒有傳遞到其它地方去。這種賦值的做法，把局部變量的作用域不必要的增大，讓人以為它可能在將來改變，也許會在其它地方被使用。更好的做法，其實是定義兩個變量：
if (...) {
?String msg = "succeed";
?log.info(msg);
} else {
?String msg = "failed";
?log.info(msg);
}
由于這兩個msg變量的作用域僅限于它們所處的if語句分支，你可以很清楚的看到這兩個msg被使用的范圍，而且知道它們之間沒有任何關(guān)系。
把復(fù)雜的邏輯提取出去，做成“幫助函數(shù)”。有些人寫的函數(shù)很長，以至于看不清楚里面的語句在干什么，所以他們誤以為需要寫注釋。如果你仔細(xì)觀察這些代碼，就會發(fā)現(xiàn)不清晰的那片代碼，往往可以被提取出去，做成一個函數(shù)，然后在原來的地方調(diào)用。由于函數(shù)有一個名字，這樣你就可以使用有意義的函數(shù)名來代替注釋。舉一個例子：
...
// put elephant1 into fridge2
openDoor(fridge2);
if (elephant1.alive()) {
?...
} else {
? ...
}
closeDoor(fridge2);
...
如果你把這片代碼提出去定義成一個函數(shù)：
void put(Elephant elephant, Fridge fridge) {
?openDoor(fridge);
?if (elephant.alive()) {
? ?...
?} else {
? ? ...
?}
?closeDoor(fridge);
}
這樣原來的代碼就可以改成：
...
put(elephant1, fridge2);
...
更加清晰，而且注釋也沒必要了。
把復(fù)雜的表達(dá)式提取出去，做成中間變量。有些人聽說“函數(shù)式編程”是個好東西，也不理解它的真正含義，就在代碼里大量使用嵌套的函數(shù)。像這樣：
Pizza pizza = makePizza(crust(salt(), butter()),
? topping(onion(), tomato(), sausage()));
這樣的代碼一行太長，而且嵌套太多，不容易看清楚。其實訓(xùn)練有素的函數(shù)式程序員，都知道中間變量的好處，不會盲目的使用嵌套的函數(shù)。他們會把這代碼變成這樣：
Crust crust = crust(salt(), butter());
Topping topping = topping(onion(), tomato(), sausage());
Pizza pizza = makePizza(crust, topping);
這樣寫，不但有效地控制了單行代碼的長度，而且由于引入的中間變量具有“意義”，步驟清晰，變得很容易理解。
在合理的地方換行。對于絕大部分的程序語言，代碼的邏輯是和空白字符無關(guān)的，所以你可以在幾乎任何地方換行，你也可以不換行。這樣的語言設(shè)計是個好東西，因為它給了程序員自由控制自己代碼格式的能力。然而，它也引起了一些問題，因為很多人不知道如何合理的換行。