The art of readable code摘要 -- 簡化迴圈與邏輯

making control flow easy to read (使得流程容易理解)
the order of arguments in conditionals

the order of if/else blocks

the ?: conditional expression (a.k.a. “ternary operator”)
建議不要使用，易懂比省空間重要得多

avoid do/while loops (避免使用避免使用do/while)
把condition放在前面比較好

returning early from a function (儘早回傳value)

the infamous goto (惡名昭彰的goto)
在linux kernel內有不少goto，但是他們使用goto通常是跳到"結尾"，並不是當作插入流程控制

minimize nesting (減少loop nesting)
可以簡潔流程
是否你新增的程式碼夠清楚明白嗎?不要因為增加簡單處理而增加很多的理解程式是複雜度

can you follow the flow of execution? (你能夠理解流程嗎?)
一些高階的手法，有其必要的代價，如果可以的話，使用簡單的模式，避免使用他們

• Programming construct=>How high-level program flow gets obscured
• threading=>It’s unclear what code is executed when.
• signal/interrupt=>handlers Certain code might be executed at any time.
• exceptions=>Execution can bubble up through multiple function calls.
• function pointers & anonymous functions=>It’s hard to know exactly what code is going to run because that isn’t known at compile time.
• virtual methods=>object.virtualMethod() might invoke code of an unknown subclass.

breaking down giant expressions (分解太長的表示表示式)
explaining variables (示意變數)
if line.split(':')[0].strip() == "root": ...改為username = line.split(':')[0].strip()
讓一個變數來表達他的用意

summary variables (結論變數)
final boolean user_owns_document = (request.user.id == document.owner_id);
如果條件要反覆使用到，使用一個變數取代他

using de morgan’s laws (使用de morgan定理)
使用de morgan's laws化簡條件判斷式

abusing short-circuit logic (避免濫用"短路"邏輯)
避免誤用短路邏輯，因為短路邏輯會造成其他邏輯部分沒有執行，尤其如果邏輯判斷內的每個method/function都期望他們被執行到

example: wrestling with complicated logic
嘗試為複雜的邏輯找到優雅的表示法

breaking down giant statements  (拆解太長的表示式)
試著使用explaining variables跟summary variables來取代跟化簡太長的表示式

another creative way to simplify expressions (另一種簡化表示式的創意方式)
適當的使用MACRO來以更簡潔的方式簡化expression

variables and readability (變數以及可能性)
eliminating variables (減少變數)
如果使用了explaining variables以及summary variables，要注意是否這個變數有存在的必要，如果他們沒有長期存在的意義，或許直接使用expression會比較好

shrink the scope of your variables (縮小變數的範圍)
儘量減少variable的生命週期以及範圍，如果沒有存在的必要，就不要讓它存在

prefer write-once variables (使用常數)
多使用constant，因為愈少操作，出錯機率愈少

a final example
=============我的心得=============
這部分有很多語言相依的實例，但是有些已經開始牽涉到執行以及正確性了，不是單單可讀性的問題

比方說summary/explaining variables的使用，曾經有人建議不要使用，理由是，每一次使用summary/explaining variables等同增加犯錯的風險，他們堅持使用function call好過用variable傳遞。其實我覺得使用這些變數的確有這樣的風險，但是同時又可以增加效能以及可讀性，作者自己也在eliminating variables提出幾個類似反例例子

所以上面的技巧使用很端看場合決定，沒有一個絕對好的答案，都是有一些trade-off存在

至於有些部分我沒有節錄是因為感覺書上"技巧"實在有點太過over了