这篇文章，是关于整洁代码函数书写的一些准则。
一、引言
以下引言的内容，有必要伴随这个系列的每一次更新，这次也不例外。
但我们知道，很多时候，理想很丰满，现实很骨感，也知道人在江湖，身不由己。因为项目的紧迫性，需求的多样性，我们无法时时刻刻都写出整洁的代码，保持自己输出的都是高质量、优雅的代码。
但若我们理解了代码整洁之道的精髓，我们会知道怎样让自己的代码更加优雅、整洁、易读、易扩展，知道真正整洁的代码应该是怎么样的，也许就会渐渐养成持续输出整洁代码的习惯。
而且或许你会发现，若你一直保持输出整洁代码的习惯，长期来看，会让你的整体效率和代码质量大大提升。
而其实，最好应该缩短成如下的样子：
总之，十行以内是整洁的函数比较合适的长度，若没有特殊情况，我们最好将单个函数控制在十行以内（这个问题比较两级，主要看个人喜好）。
评论区有一些讨论，也放到正文来吧。
“函数是否应该足够短小，算是《代码整洁之道》中最具争议的议题之一。
书写短小函数的时候，其实我们不要忽略一点，那就是，函数名名称本身就具描述性。短小的函数构成，如果要追根溯源了解内部实现，自然需要一层层找到最终的实现。但若是想大致知道这个函数到底做了什么，结合这个短小函数体内具描述性的一些函数名，应该也就一目了然了。试想，当你眼前的这个函数是几十上百上千行的庞然大物的时候，你能做到一眼就一目了然，将其大概做了什么了然于心吗数短小的一方面优点，在这里就体现出来了。
函数应该短小这个议题，仁者见仁智者见智，在实际编码过程中任何人都很难做到严格遵守，但大的方向，若想写出整洁的代码，应该去向短小的函数靠拢，对吧
2 单一职责
函数应该只做一件事情。只做一件事，做好这件事。
设计模式中有单一职责原则，我们可以把这条原则理解为代码整洁之道中的函数单一职责原则。
要判断函数是不是只做了一件事情，还有一个方法，就是看能否再拆出一个函数，该函数不仅只是单纯地重新诠释其实现。
3 命名合适且具描述性
“如果每个例程都让你感到深合己意，那就是整洁的代码。”要遵循这一原则，大半工作都在于为只做一件事的小函数取个好名字。函数越短小，功能越集中，就越便于取个好名字。
别害怕长名称。长而具有描述性的名称，比短而令人费解的名称好。而且长而具有描述性的名称，比描述性的长注释要好。且选择描述性的名称能理清你关于模块的设计思路，并帮你改进之。当然，如果短的名称已经足够说明问题，还是越短越好。
命名方式要保持一致。使用与模块名一脉相承的短语、名词和动词给函数命名。比如，includeSetupAndTeardownPages,includeSetupPages, includeSuiteSetupPage, and includeSetupPage等。这些名词使用了类似的措辞，依序讲述一个故事，就是是比较推崇的命名方式了。
4 参数尽可能少
最理想的函数参数形态是零参数，其次是单参数，再次是双参数，应尽量避免三参数及以上参数的函数，有足够的理由才能用三个以上参数（多参数函数）。
函数参数中出现标识符参数是非常不推崇的做法。有标识符参数的函数，很有可能不止在做一件事，标示如果标识符为true将这样做，标识符为false将那样做。正确的做法应该将有标识符参数的函数一分为二，对标识符为true和false分别开一个函数来处理。
5 避免重复
重复的代码会导致模块的臃肿，整个模块的可读性可能会应该重复的消除而得到提升。
其实可以这样说，重复可能是软件中一切邪恶的根源，许多原则与实践规则都是为控制与消除重复而创建的。仔细想一想，面向对象编程是如何将代码集中到基类，从而避免了冗余的。而面向方面编程（Aspect Oriented Programming）、面向组件编程（ComponentOriented Programming）多少也是消除重复的一种策略。这样看来，自子程序发明以来，软件开发领域的所有创新都是在不断尝试从源代码中消灭重复。
重复而啰嗦的代码，乃万恶之源，我们要尽力避免。
四、范例
有必要贴出一段书中推崇的整洁代码作为本次函数书写准则的范例。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！