《Clean Code》閱讀：在大師們的眼中，什麼樣的代碼纔是好代碼

前幾天開始看Uncle Bob的《Clean Code》，在第一章裏，做者討論了這樣的一個問題：什麼樣的code纔是Clean code。對於這個問題，一千個Programmer可能會有一千個答案，因此做者請教了6個著名的專家，問問他們對於這個問題的見解，如下三個是我認爲不那麼虛的，比較有操做參考意義的回答：

1. Bjarne Stroustrup, C++之父

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and per- formance close to optimal so as not to tempt people to make the code messy with unprinci- pled optimizations. Clean code does one thing well.

這裏的幾個重點是：

• Elegant：意味着你的代碼看起來很舒服

• Efficient：這個可能跟Bjarne Stroustrup的領域有關，畢竟使用C++的地方大可能是對效率要求很高的領域。

• Error handling complete：完備的錯誤處理機制，這意味着關注細節。

• Does one thing well：就是咱們所說的，Single Responsibility！

2. Dave Thomas, 出版公司The Pragmatic Bookshelf Co-founder，《Pragmatic Programmer》（中文叫程序員修煉之道）、《Programming Ruby》做者。

Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and pro- vides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.

這裏的幾個重點是：

• Can be read and enhanced by others

• Unit and acceptance tests

• Meaningful names

• Minimal dependency, minimal API

這裏的test和Minimal API是咱們應該注意的東西，

3. Ron Jeffries 《Extreme Programming Installed》 《Extreme Programming Adventures in C#》的做者

In recent years I begin, and nearly end, with Beck’s rules of simple code. In priority order, simple code:
• Runs all the tests;
• Contains no duplication;
• Expresses all the design ideas that are in the system;
• Minimizes the number of entities such as classes, methods, functions, and the like.
... Of these, I focus mostly on duplication. When the same thing is done over and over, it’s a sign that there is an idea in our mind that is not well represented in the code. I try to figure out what it is. Then I try to express that idea more clearly.
Expressiveness to me includes meaningful names, and I am likely to change the names of things several times before I settle in.... I also look at whether an object or method is doing more than one thing. If it’s an object, it probably needs to be broken into two or more objects. If it’s a method, I will always use the Extract Method refactoring on it, resulting in one method that says more clearly what it does, and some submethods saying how it is done...

在這裏，Ron Jeffries甚至把test放在第一位。
至於做者的最後一條：Minimizes the number of entities such as classes, methods, functions, and the like。我認爲做者應該是有前提的。否則的話，若是以那個爲標準，那麼全部的代碼都放到一個類，一個方法裏面好了，這樣明顯是不行的。並且做者後面本身也提到，會把一個大的類分紅兩個小的，會用extract method來分解一個很長的方法。整體來講，應該大多數人都會認同：幾個小的類比一個大的類要好，幾個小的方法比一個大的方法要好。

下面3個回答相對來講就比較虛了，你們看看就好。

4. Grady Booch， 《Object Oriented Analysis and Design with Applications》做者

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

簡單直接，如詩通常， straightforward lines of control，說了等於沒說。abstraction，相對來講仍是比較實在的。

5. Michael Feathers, 《Working Effectively with Legacy Code》做者

I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by some- one who cares deeply about the craft.

這裏的重點是Care。可是什麼樣的代碼是被author care過得呢？這裏沒有明確的指標能夠依據，只能靠咱們本身去判斷。

6. Ward Cunningham, Wiki發明人，Fit發明人，eXtreme Programming共同發明人. Design Patterns、OO思想領袖。The godfather of all those who care about code.

You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.

「Pretty much what you expected」，可是每一個人expect的代碼的樣子都是不同的，一個初學者expected的代碼的樣子可能相對也會比較初級，難道那個也能稱做clean code嗎？I might have a different opinion.

總結一下，我我的認爲如下幾點，很是值得咱們參考：

1. Single Responsibility. 一個類只作它該作的事情，一個方法作一件事。

2. Minimal API：一個類對外暴露的接口應該是儘可能少的，其實這也就意味着多用Composition，少用繼承，由於繼承，意味着這個類繼承了父類全部的接口，這跟Minimal API明顯是相對的。

3. Unit Test：這不是一件可有可無的事情，不要說「僅僅是爲了測試」這樣的話。。。

4. Naming：這也是一件很是重要的事情，類名，方法名，變量名等等，這都是很是影響可讀性的。哪怕寫起來不大順手，也須要爲了更好的可讀性，設計一個更好的接口。爲何？由於讀代碼的時間比寫代碼的時間多出10倍不止，這個在書中也有提到，是經過人們對Emacs的使用狀況，真實統計出來的。從另一個角度來說，代碼寫出來是一次性的，而以後被閱讀的次數倒是沒法估計的。

5. No duplication: Duplication is the root of all evil in software design.

你們以爲，什麼樣的代碼纔是好代碼呢？

有任何意見或建議，或者發現文中任何問題，歡迎留言！

更多文章請訪問我的博客
做者：鄒小創
Github：https://github.com/ChrisZou郵件：happystriving@126.com