讓多餘的標記選用
 |
||
|
讓多餘的標記選用 |
|
if 語句後跟著 'then'，而在一個 while 以及 for 語句後跟著 'do'。這些完全是多餘的，我建議讓它們變成選用的。它們加重了我們肌腱不必要的磨損，讓代碼更難讀（眼睛比較容易辨別開頭和結尾）。沒有它們，代碼會更簡潔，更容易讀
local n = 10
if n > 5
for i=1,n
local x = n
while x > i
x = x - 1
io.write(x)
end
io.write('\n')
end
end
這是 Lua 代碼的一項小改動（LuaPowerPatches），增加 Lua 的效能（微不足道，但可以證實），且完全向後相容。
我發現有 do 和 then 比較好讀。你讀的時候可以比較容易掃視。比較容易看出區塊的開頭和結尾，而且你會知道一個範圍是在 do 和 end 之間。你不需要評估表達式，來看它們是否完整（例如因為結尾的分號是選用的）。當然可以加括弧來保證表達式是完整的，但這樣一來它們又是選用的和多餘的了。——NDT
我不覺得比較好讀。
首先，在寫得好的 C/Pascal/Lua/... 中，要辨識區塊很難，感謝縮排。Python 甚至將縮排當做區塊範圍的唯一指標。它確實有效。
說實話，我發現很難相信你會去找 'then' 和 'do' 關鍵字，來看區塊的開頭在哪裡。我的眼睛會掃描代碼的左側來決定區塊的結構，將 'if', 'for' 和 'while' 語句與它們相對應的 'end' 語句配對，單純透過縮排來做。只有有錯誤時，某些地方會讓我懷疑縮排有誤導性，我才開始掃描代碼的右側。
當然，我不會在每一行放好幾個語句。也許如果我做了，我就會被迫養成忽略縮排、掃描分隔符號的習慣，才能找出我代碼的結構。但我比較喜歡一致地設定代碼的格式，相信這樣可以讓辨識更輕鬆。
所以，區塊結構透過一致的格式變得透明後，我們還可以如何幫助快速辨識呢？把一個語句的重要部分放在一行的開頭和結尾，那裡眼睛最容易看到它們。選擇好的變數名稱也套用相同的原則
foobar1 foobar2優於
foo1bar foo2bar同樣地
if a if e優於
if a then if e then即使你不同意，只想把它歸咎於品味問題，我還是不認為為什麼它不應該變成選用的。它完全不會傷害 Lua。——EricTetz
我也不覺得有 "then" 標記的 lua 代碼更好讀。把它變成選用的，沒什麼正當理由不這麼做。——DanHollis?
同意。如果可以的話，我希望可以像在 Python 或 Ruby 中寫「def」，而不是「function」——它比較簡短。——YuraSokolov？
我發現當有多個條件時，then 簡潔易讀，例如：
if
(cond1 == val1) and
(cond2 ~= val2) or
(cond3 <= val3)
then
-- code block
end
為了語法的連貫性，我投票贊成保留它。但另一方面，您也可以對省略的括號說同樣的話——SajberToffe？
then 在 Lua 4 中完全是多餘的，但當語法更改為允許呼叫和賦值語句以括弧的表達式開頭時，這種情況就有所改變；此變更表示 ; 語句終止符僅半選擇性地出現。以下沒有 then 就無法寫出來，因為 ; 只出現在語句後面；沒有 then，它會模稜兩可
if x then (funcs[x] or default_func)() end
而且，do 在 for 或 while 語句中不能是選擇性的，因為區塊本身可以以 do 語句開始
while x > 100 do
do
local y = f(x)
g(y)
h(y)
end
-- ...
end
上述程式碼限制 y 的生命週期，如果 y 是巨集物件，並且 while 迴圈的剩餘部分相當耗時的話，這可能會很有用。
如果 do 不能是選擇性的，則唯一明確的可能性是強制或禁止；如果它是禁止的，那麼在 if 語句中註明的模糊性將無法解決。
C 必須以 ( ) 將條件包圍，並使用 { 和 } 而不是 do/then 和 end 來解決在條件式後面加上語句的模糊性；它還要求語句以 ; 結尾。最後，它幾乎是一種大同小異——相對吸引力取決於您是否偏愛標點符號而不是英文單字。