我的問題有Bash和PowerShell腳本，但我想它也適用於其他語言。代碼結構：我應該使用很多函數來提高可讀性嗎？
我的理解是，函數的目的是多次執行相同的（或非常相似的）任務。這樣可以減少腳本中的代碼量，同時也便於維護。
考慮到這一點，如果您發現您的腳本只調用一次函數，那麼沒有理由使該函數存在作爲函數。相反，您應該使用該函數的代碼並將其放在該函數被調用的位置。
說了這麼多，這是我的問題：
如果我有一個複雜的腳本，我應該移動的每段代碼到它自己的功能，即使每個功能纔會被調用一次？這會大大增加腳本的可讀性，因爲它的邏輯（函數）將全部位於腳本的頂部，而執行的流程將位於腳本的底部。由於50行代碼將僅由1行代表，因此理解腳本正在做什麼會容易得多。
其他人這樣做嗎？這種方法有缺點嗎？
功能還增加了可讀性。所以bash腳本可能會更好看，如果它讀取更容易遵循：
getParams()
startTask()
doSomethingElse()
finishTask()
# implement functions below
即使功能的實現是簡單的，它讀取更好。
函數執行定義明確的任務。如果你有一個可以完成5個不同事情的大型函數，它強烈建議它應該調用5個較小的函數。
我的理解是，函數的目的是多次執行相同的（或非常相似的）任務。
嗯，這是我的理解，一個函數是一個離散的實體，執行一個特定的，明確的任務。
考慮到這一點，如果您發現腳本在最少一次調用給定的函數，那麼它正在完成它的工作。
代碼可讀性的確是一個主要問題，通常（現在）比代碼或性能的數量更重要。更不用說內聯函數調用可能不一定有明顯的性能優勢（特定語言）。所以很多開發者（我冒昧地說，這個品種更好:-)創建像你描述的小函數/方法，將他們的代碼劃分爲邏輯上相關的部分。
讀此書
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
下面是從書中一些報價。
「Small！ 函數的第一條規則是它們應該很小，函數的第二條規則是 它們應該比它小。「
」功能應該做一件事。他們應該做IT WELL.THEY應該只做到這一點。」
關注能夠閱讀和容易理解你的代碼。
有明確的，可讀的代碼絕對比害怕的函數調用開銷回報。這只是一個不成熟的優化。
此外，函數的目標是完成特定的任務。任務可以是一個子任務，沒有什麼錯！
據我所知是有關，函數表示成爲較大程序的一部分的一系列步驟。 回到你的問題，我非常贊同函數提高可讀性和可重用性。但同時將所有東西分解成碎片可能不是一個好習慣。 最後，我想給出一個聲明：「任何過量都不是有益的！」
函數被調用一次沒有錯。這不是性能問題，它增加了代碼的可讀性。 – Mchl 2011-01-06 17:33:57