function
Short, the first rule of function is to be short.
Each function is clear at a glance, and each function only says one thing.
Also, each function takes you to the next function in sequence.
This is how short the function should be.
Code blocks and indentation
if statement, else statement, while statement
only do one thing
A function should do one thing, do it well, and only do one thing.
A function that only does one thing should be the most convenient to use and the best reusability.
It is the basic unit of a large combination.
One abstraction level per function
To ensure that a function does only one thing, the statements in the function must all be at the same level of abstraction.
Top-down code: Down rule j
We want each function to be followed by a function at the next level of abstraction, so that when viewing a list of functions, we can read down the level of abstraction.
switch statement
Use descriptive names
Be consistent in naming your functions, using phrase names or verbs that follow the module name.
function parameter
The ideal number of parameters is 0 parameters, followed by one, then two, and three should be avoided as much as possible.
General form of unary function
Identity parameter
binary function
parameter object
If the function appears to require two or three or more arguments,
It means that some of these parameters should be encapsulated as classes.
parameter list
verbs and keywords
Giving a function a good name will better explain the intent of the function, as well as the order and intent of the arguments.
No side effects
Weird temporal coupling and sequential dependencies
It is possible to appear in the function, and the function does more unrelated things
In a typical case, the session object is initialized during user password verification.
It's OK at the beginning of the session, but it may cause the program to fail elsewhere.
Output parameters
Splitting Instructions and Inquiries
Functions either do something or answer something, but not both.
Use exceptions instead of returning error codes (as they should)
Returning an error code from an imperative function violates the command-to-query separation rule.
Extract the Try/Catch block
Try/Catch代码块丑陋不堪，他们搞乱的代码结构，把错误处理和正常流程混为一谈。
最好把try/catch代码块主体部分抽离出来，另外形成函数。
错误处理就是一件事
函数应该只做一件事，错误处理就是一件事，因此处理错误的函数不该做其他事。
Error.java依赖磁铁
返回错误码通常暗示有个类或者枚举，定义了所有错误码。
这样的类就是一块磁铁，其他许多类都得导入和使用它。
当Error枚举修改时，所有其它的类都需要重新编译和部署。
使用异常代替错误码，新异常就可以从异常类派生出来，无需要重新编译或重新部署。
别重复自己
重复会导致代码臃肿，当需要改变时，要改变多次，增加了错误产生的几率。
重复可能是软件中一起邪恶的根源，许多原则与实践规则都是为控制与消除重复而创建。
结构化编程
遵循Edsger Dijkstra 的结构化编程规则
每个函数、函数中的每个代码块都应该有一个入口、一个出口。
函数中只有一个return瑜伽，循环中不能有break或continue语句，而且永远不能有任何goto语句。
但是小函数中，偶尔出现的return break或continue语句，比单入单出原则更具有表达力，没有坏处。
如何写出这样的函数
写代码和写被动东西很像，先想什么写什么，然后再打磨
写函数是，一开始都冗长而复杂，有太多缩进和嵌套循环，有过长的参数列表，名称是随意取的，也有重复的代码
然后打磨这些代码，分解函数就、修改名称、消除重复，缩短和重新安置方法，有事还拆散类。
最后遵循本章列出的规则，组装好这些函数。
并不从一开始就按照规则写函数，没人做得到
大师级程序员把系统当作故事来讲，而不是当作程序来写。
他们使用选定编程语言提供的工具构建一个更为丰富更具表达力的语言，用来讲那个故事。
那种领域特定语句的一个部分就是描述在系统中发生的各种星湖的函数层级。
遵循这些规则，函数会短小，有个好名字，而且被很好的归置，
真正的目标在于讲述系统的故事，而你编写的函数必须干净利落的拼装到一起，
形成一种精确而清晰的语言，帮助你讲故事。