note for "The Art of Readable Code" - CH13 Writing Less Code

The most readable code is no code at all.

Programmer最重要的技能之一就是知道哪些code不用寫，因為寫出來就要測試&維護，越小的程式碼越容易被維護，coupling程度越低越好，最好彼此獨立，有幾個方向:

1. Create as much generic “utility” code as possible to remove duplicated code. (See Chapter 10, Extracting Unrelated Subproblems.)
2. Remove unused code or useless features. (See the following sidebar.)
3. Keep your project compartmentalized into disconnected subprojects.
4. Generally, be conscious of the “weight” of your codebase. Keep it light and nimble.

Be Familiar with the Libraries Around You

每隔一段時間應該要花一下時間，讀一下你的 standard library，目的在於能對standard library的API有概念，以便在coding時能聯想到,並大量且反覆地使用這些library。

參考資料:
• The Art of Readable Code

note for "The Art of Readable Code" - CH12 Turning Thoughts into Code

You do not really understand something unless you can explain it to your grandmother. 
  — Albert Einstein  

先用口語描述演算法後，再轉成程式碼，能讓programmer寫出更自然的code，也有助於找出可以分解的子問題。

 We are reading three row iterators in parallel.
 Whenever the rows' times don't line up, advance the rows so they do line up.
 Then print the aligned rows, and advance the rows again.
 Keep doing this until there are no more matching rows left.

上述口語轉成的code為

def PrintStockTransactions(): 
    stock_iter = ...
    price_iter = ... 
    num_shares_iter = ...

    while True:
        time = AdvanceToMatchingTime(stock_iter, price_iter, num_shares_iter) 
        if time is None:
            return
        # Print the aligned rows.
        print "@", time,
        print stock_iter.ticker_symbol,
        print price_iter.price,
        print num_shares_iter.number_of_shares
        stock_iter.NextRow()
        price_iter.NextRow()
        num_shares_iter.NextRow()

參考資料:
• The Art of Readable Code

note for "The Art of Readable Code" - CH11 One Task at a Time

Code should be organized so that it’s doing only one task at a time.舉個投票例子，投UP則+1，Down則-1，結果為所有投票總和，如果依據該rule，則code應該是

var vote_changed = function (vote) {
    var score = get_score();
    score += vote_value(vote);
    set_score(score);
};

基本上這個章節的概念跟前一章節差不多"將子問題抽離，讓function專注在處理問題本身上面"。其餘細節就不贅述了。

參考資料:
• The Art of Readable Code

note for "The Art of Readable Code" - CH10 Extracting Unrelated Subproblems

將子問題抽離，讓function專注在處理問題本身上面，首先要先了解這個function的"目的"，接著抽離與"目的"無關的子問題，將這些子問題一一寫成獨立的function，如:（簡單說就主程式專注在邏輯上，細節部分就一一寫成sub function處理）

// Return which element of 'array' is closest to the given latitude/longitude.
// Models the Earth as a perfect sphere.
var findClosestLocation = function (lat, lng, array) {
    var closest;
    var closest_dist = Number.MAX_VALUE;
    for (var i = 0; i < array.length; i += 1) {
        // Convert both points to radians.
        var lat_rad = radians(lat);
        var lng_rad = radians(lng);
        var lat2_rad = radians(array[i].latitude);
        var lng2_rad = radians(array[i].longitude);
        // Use the "Spherical Law of Cosines" formula.
        var dist = Math.acos(Math.sin(lat_rad) * Math.sin(lat2_rad) +
                             Math.cos(lat_rad) * Math.cos(lat2_rad) *
                             Math.cos(lng2_rad - lng_rad));
        if (dist < closest_dist) {
             closest = array[i];
             closest_dist = dist;
        }
    }
    return closest;
};

抽離後的code
var spherical_distance = function (lat1, lng1, lat2, lng2) {
    var lat1_rad = radians(lat1);
    var lng1_rad = radians(lng1);
    var lat2_rad = radians(lat2);
    var lng2_rad = radians(lng2);
    // Use the "Spherical Law of Cosines" formula.
    return Math.acos(Math.sin(lat1_rad) * Math.sin(lat2_rad) +
                     Math.cos(lat1_rad) * Math.cos(lat2_rad) *
};

var findClosestLocation = function (lat, lng, array) {
    var closest;
    var closest_dist = Number.MAX_VALUE;
    for (var i = 0; i < array.length; i += 1) {
        var dist = spherical_distance(lat, lng, array[i].latitude, array[i].longitude);
        if (dist < closest_dist) {
            closest = array[i];
            closest_dist = dist;
        }
    }
    return closest;
};

抽離這些子問題的另一個好處容易優化，比如有更好的方式去運算spherical_distance()或是變更findClosestLocation()的運算邏輯。建立通用的function也是一個很好也很重要的習慣，當你開發一個新的program時，就可以運用這些通用function，快速建立一個prototype。

Simplifying an Existing Interface & Reshaping an Interface to Your Needs

如果既有的API不好用，那就包裝他或改寫他吧，我在A Wrap for service/thread也包裝了一些API，讓自己易於開發，有必要也會進行Reshaping/Re-factor等等步驟。

參考資料:
• The Art of Readable Code

Table Of Content for tag "Design Patterns with C "

• A pattern for state machine
• A pattern for state machine II - SM framework
• A pattern for state machine III - SM framework
• An Sample Code for Syslogd - A log pattern with categorize, level and format
• An Sample Code for Syslogd - A log pattern with categorize, level and format II
• An Sample Code for threads control - A Wrap for service/threadstart/stop/periodical run
• An Sample Code for notification-chain
• A pattern for command table

note for "The Art of Readable Code" - CH9 Variables and Readability

減少不必要的變數可以增加閱讀性, 比如

root_message.last_view_time = datetime.datetime.now()
會比下面code更容易理解
now = datetime.datetime.now()
root_message.last_view_time = now

下面還有幾個需要優化的的例子, 可以好好思考如何改善.

boolean done = false;
while (/* condition */ && !done) {
    ...
    if (...) {
        done = true;
        continue;
    }
}
與
var remove_one = function (array, value_to_remove) {
    var index_to_remove = null;
    for (var i = 0; i < array.length; i += 1) {
        if (array[i] === value_to_remove) {
            index_to_remove = i;
            break;
        }
    }
    if (index_to_remove !== null) {
        array.splice(index_to_remove, 1); 
    }
};

programmer都知道要盡量限縮變數的範圍, 因為可視範圍小, 要記住的變數數量也會減少, 也且可以避免global/local variable用錯的窘境.

submitted = false; // Note: global variable
var submit_form = function (form_name) {
    if (submitted) {
        return;  // don't double-submit the form
    }
    ...
    submitted = true;
};
可以被修改成
var submit_form = (function () {
    var submitted = false; // Note: can only be accessed by the function below
    return function (form_name) {
        if (submitted) {
            return;  // don't double-submit the form
        }
        ...
        submitted = true; 
    };
}());

參考資料:
1. The Art of Readable Code

Table Of Content for tag "The Art of Readable Code"

這是一本好書, 建議每個programmer都應該買來翻一翻

• CH1, Code Should Be Easy to Understand
• CH2, Pack information into your names
• CH3, Names That Can’t Be Misconstrued
• CH4, Aesthetics
• CH5, Knowing What to Comment
• CH6, Making Comments Precise and Compact
• CH7, Making Control Flow Easy to Read
• CH8, Breaking Down Giant Expressions
• CH9, Variables and Readability
• CH10, Extracting Unrelated Subproblems
• CH11, One Task at a Time
• CH12 Turning Thoughts into Code
• CH13 Writing Less Code

note for "The Art of Readable Code" - CH8 Breaking Down Giant Expressions

Explaining Variables

coding主要的主軸是readable, 其餘都是次要的, 而利用額外的變數, 來解釋某個較小的表示式, 就被稱為"explaining variable". 比如

username = line.split(':')[0].strip() if username == "root":
會比下面這行容易理解
if line.split(':')[0].strip() == "root":
上面的username就被稱為"explaining variable"

Summary Variables

利用額外的變數, 來解釋某個表示式, 稱為"Summary Variables", 比如

final boolean user_owns_document = (request.user.id == document.owner_id);
if (user_owns_document) {
// user can edit this document...
}
這裡的user_owns_document就被稱為Summary Variables, 當然你也可以不斷的使用(request.user.id == document.owner_id)

Using De Morgan’s Laws

1) not (a or b or c) ⇔ (not a) and (not b) and (not c)
2) not (a and b and c) ⇔ (not a) or (not b) or (not c)
我們可以多利用Morgan’s Laws簡化一些判斷式, 當然一切還是以readable為前提, 比如

if (!file_exists || is_protected) Error("Sorry, could not read file.");
會比下面這行容易理解
if (!(file_exists && !is_protected)) Error("Sorry, could not read file.");

Finding a More Elegant Approach

有時候我們反向思考可以找到更好的

// Check if 'begin' or 'end' falls inside 'other'.
bool Range::OverlapsWith(Range other) {
    return (begin >= other.begin && begin lt; other.end) || 
        (end > other.begin && end lt;= other.end)
}
換個方式寫會更好閱讀
bool Range::OverlapsWith(Range other) {
    if (other.end <= begin) return false;  // They end before we begin
    if (other.begin >= end) return false;  // They begin after we end
    return true;  // Only possibility left: they overlap
}

Simplify Expressions

有時候我們可以用MARCO增加閱讀性, 比如

void AddStats(const Stats& add_from, Stats* add_to) {
    #define ADD_FIELD(field) add_to->set_##field(add_from.field() + add_to->field())
    ADD_FIELD(total_memory);
    ADD_FIELD(free_memory);
    ADD_FIELD(swap_memory);
    ADD_FIELD(status_string);
    ADD_FIELD(num_processes);
    ...
    #undef ADD_FIELD
}
比下面這例子容易閱讀
void AddStats(const Stats& add_from, Stats* add_to) {
    add_to->set_total_memory(add_from.total_memory() + add_to->total_memory());
    add_to->set_free_memory(add_from.free_memory() + add_to->free_memory());
    add_to->set_swap_memory(add_from.swap_memory() + add_to->swap_memory());
    add_to->set_status_string(add_from.status_string() + add_to->status_string());
    add_to->set_num_processes(add_from.num_processes() + add_to->num_processes());
     ...
}

coding主要的主軸是readable, 其餘都是次要的, 而利用額外的變數, 來解釋某表示式, 或利用MACRO更容易閱讀, 以及換個方式寫, 都是手段

參考資料:
1. The Art of Readable Code

note for "The Art of Readable Code" - CH7 Making Control Flow Easy to Read

CH7, Making Control Flow Easy to Read

The Order of Arguments in Conditionals
if (a > b) 左側通常是會有變化數值, 右側是比較基準, 通常是常數,

如 if (length >= 10)
會比下面這行容易閱讀 
if (10 <= length)

returning early from a function 與 minimize nesting
盡量讓function提早返回與減少巢狀結構可以增加閱讀性, 如

if (do_auth() != true) {
    do_auth_failed();
    return;
}

if (permission_check() != SUPER) {
    do_permission_check_failed();
    return;
}

do_something();

會比下面寫法容易閱讀
if (do_auth() == true) {
    if (check_permission() == SUPER) {
        do_something();
    } else {
        do_permission_check_failed();
    {
} else {
    do_auth_failed();
}

參考資料:
1. The Art of Readable Code

note for "The Art of Readable Code" - CH6 Making Comments Precise and Compact

CH6, Making Comments Precise and Compact

Comments should have a high information-to-space ratio.當你準備寫註解時, 請盡可能的精簡, 因為註解會佔版面, 而且需要時間了解

// CategoryType -> (score, weight)
typedef hash_map<int, pair<float, float> > ScoreMap;
會比下面例子精簡
// The int is the CategoryType.
// The first float in the inner pair is the 'score',
// the second is the 'weight'.
typedef hash_map<int, pair<float, float> > ScoreMap;

// Return the number of lines in this file.
int CountLines(string filename) { ... }
這段註解不精確, 因為一行有很多種定義, 下面例子會相對精準
// Count how many newline bytes ('\n') are in the file.
int CountLines(string filename) { ... }

Use Input/Output Examples That Illustrate Corner Cases有時候用範例當註解可以更容易讓人理解,比如

// Rearrange 'v' so that elements < pivot come before those >= pivot;
// Then return the largest 'i' for which v[i] < pivot (or -1 if none are < pivot)
// Example: Partition([8 5 9 8 2], 8) might result in [5 2 | 8 9 8] and return 1
int Partition(vector<int>* v, int pivot);

"Named Function Parameter” Comments即在function參數上加上註解

Connect(/* timeout_ms = */ 10, /* use_encryption = */ false);

參考資料:
1. The Art of Readable Code

note for "The Art of Readable Code" - CH5 Knowing What to Comment

CH5, Knowing What to Comment

The purpose of commenting is to help the reader know as much as the writer did.千萬別為了註解而註解, 因為凌亂的畫面, 不會讓人對程式碼更清晰

無意義的註解範例

// The class definition for Account
    class Account {
      public:
        // Constructor
Account();
        // Set the profit member to a new value
        void SetProfit(double profit);
        // Return the profit from this Account
        double GetProfit();
    };

不要註解不好的名稱, 直接修正名稱

// Enforce limits on the Reply as stated in the Request,
// such as the number of items returned, or total byte size, etc. 
void CleanReply(Request request, Reply reply);
直接修改上述function name從CleanReply()改為EnforceLimitsFromRequest()會比註解一堆來得有意義,
// Make sure 'reply' meets the count/byte/etc. limits from the 'request' 
void EnforceLimitsFromRequest(Request request, Reply reply);

Recording Your Thoughts / directory commentary,註解重要的紀錄,比如以下幾個註解

// This heuristic might miss a few words. That's OK; solving this 100% is hard.
...
// This class is getting messy. Maybe we should create a 'ResourceNode' subclass to
// help organize things.
...

Comment the Flaws in Your Code,程式會不斷的被修改, 不要害怕記錄這些需要改進的地方, 以下是常用的標記

TODO:	Stuff I haven’t gotten around to yet
FIXME:	Known-broken code here
HACK:	Admittedly inelegant solution to a problem
XXX:	Danger! major problem here

// TODO: move this into sched_fork()
...
// FIXME: do we need to worry about rq being invalidated by the
...

Summary Comments,對一些code給予一些comment, 比如

# Find all the items that customers purchased for themselves.
    for customer_id in all_customers:
        for sale in all_sales[customer_id].sales:
            if sale.recipient == customer_id:
                ...

def GenerateUserReport():
    # Acquire a lock for this user
    ...

    # Read user's info from the database
    ...

    # Write info to a file
    ...

    # Release the lock for this user
    ...

參考資料:
1. The Art of Readable Code

note for "The Art of Readable Code" - CH3 & CH4

CH3, Names That Can’t Be Misconstrued

Actively scrutinize your names by asking yourself, “What other meanings could someone interpret from this name?”

1. 比如results = Database.all_objects.filter("year <= 2011")的結果是<= 2011還是過濾了<= 2011的結果？如果用select()或exclude()會更為明確



2. 對於含有邊界意思的, 可以使用"min_"與"max_"加以辨識.



3. 對於閉區間使用first與end, 而半開放區間使用begin與end, 因為這些已經在C++中成為慣例了.



4. 關於bool則可以加上is, has, can, should等意思會更明確, 如

bool user_is_authed = true
會比下面這行更容易被明確
bool read_password = true




5. get*()(開頭的function), 通常指直接回傳內部成員, 如果還需要計算, 最好改用compute*()或count*(),

CH4, Aesthetics

這個章節是在講述, 好的排版會讓人更容易看懂code, 以下是我摘要的幾個範例

1. 給予參數一些註解

public class PerformanceTester {
   // TcpConnectionSimulator(throughput, latency, jitter, packet_loss)
   //                            [Kbps]   [ms]     [ms]    [percent]
   public static final TcpConnectionSimulator wifi =
       new TcpConnectionSimulator(500,     80,     200,     1);
   public static final TcpConnectionSimulator t3_fiber =
       new TcpConnectionSimulator(45000,   10,       0,     0);
   public static final TcpConnectionSimulator cell =
       new TcpConnectionSimulator(100,    400,     250,     5);
}



2. 讓參數對齊

CheckFullName("Doug Adams"  , "Mr. Douglas Adams" , "");
CheckFullName(" Jake Brown ", "Mr. Jake Brown III", "");
CheckFullName("No Such Guy" , ""                  , "no match found");
CheckFullName("John"        , ""                  , "more than one result");



3. 段落分明

def suggest_new_friends(user, email_password):
  # Get the user's friends' email addresses.
  friends = user.friends()
  friend_emails = set(f.email for f in friends)

  # Import all email addresses from this user's email account.
  contacts = import_contacts(user.email, email_password)
  contact_emails = set(c.email for c in contacts)

  # Find matching users that they aren't already friends with.
  non_friend_emails = contact_emails - friend_emails
  suggested_friends = User.objects.select(email__in=non_friend_emails)

Consistent style is more important than the “right” style. 無論你是用什麼coding style, 一致性會比你用“對”的style更重要.

參考資料:
• The Art of Readable Code

note for "The Art of Readable Code" - CH1 & CH2

CH1, Code Should Be Easy to Understand

Code should be written to minimize the time it would take for someone else to understand it.

越容易理解的code是越好的, 雖然減少程式碼數量是很好的目標, 但是縮短理解的時間是更為重要的, 甚至於超越效能, 比如

bucket = FindBucket(key);
if (bucket != NULL) assert(!bucket->IsOccupied());
會比下面這行更容易被理解
assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());

CH2, Pack information into your names

提高可讀性可以從"好的名稱", "好的註解", "簡潔的編排方式"著手, 比如, 將資訊放入名稱中

void download_page(url);
或
void fetch_page(url);
會比下面這行更容易被理解
void get_page(url);

名稱選擇上也需要注意, 比如open(), begin(), create(), launch()會比start()來的明確, 盡量用明確的命名, 比如tmp_file會比tmp更明確, 比如

var start = (new Date()).getTime();
...
var elasped = (new Date()).getTime();
..
會比下面這行更容易被明確
var ms_start = (new Date()).getTime();
...
var ms_elasped = (new Date()).getTime();
..

排除不必要的詞彙, 比如

ToString();
會比下面這行更簡潔
ConveterToString();

ServerLoop();
會比下面這行更簡潔
DoServerLoop();

我也習慣在static function,使用"_"開頭, 比如

static void _sleep();
void sleep();

Pack information into your names的幾個重點

• Use specific words—for example, instead of Get, words like Fetch or Download might be
better, depending on the context.
• Avoid generic names like tmp and retval, unless there’s a specific reason to use them.
• Use concrete names that describe things in more detail—the name ServerCanStart() is
vague compared to CanListenOnPort().
• Attach important details to variable names—for example, append _ms to a variable
whose value is in milliseconds or prepend raw_ to an unprocessed variable that needs
escaping.
• Use longer names for larger scopes—don’t use cryptic one- or two-letter names for
variables that span multiple screens; shorter names are better for variables that span only
a few lines.
• Use capitalization, underscores, and so on in a meaningful way—for example, you
can append “_” to class members to distinguish them from local variables.

參考資料:
• The Art of Readable Code