我的问题有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