重构-改善既有代码设计_实用代码重构，第2部分-可读性

重构-改善既有代码设计

In part one of this series I introduced what constitutes good code. As the series on code refactoring continues we’ll dive into each of the three aspects and see how to refactor for each of them in order: readability, extensibility, and efficiency. In this part, the focus is on refactoring your code for better readability.

在本系列的第一部分中，我介绍了什么是好的代码。 随着有关代码重构的系列文章的继续，我们将深入研究这三个方面的每一个，并了解如何按顺序对它们进行重构：可读性，可扩展性和效率。 在这一部分中，重点是重构代码以提高可读性。

Recall the definition of readability: readable code follows some well-known style and documentation practices. To help you start refactoring your code for readability, I’ve prepared this list of questions you should ask yourself throughout the development, testing, and review process.

回顾可读性的定义：可读代码遵循一些众所周知的样式和文档惯例。 为了帮助您开始重构代码以提高可读性，我准备了以下问题列表，您应该在开发，测试和审查过程中自问。

一般 (General)

1. Does the code follow a standard guideline for style, syntax, and documentation?

1.代码是否遵循有关样式，语法和文档的标准准则？

You should be using a coding standard, preferably a public one like PSR-1/2. For any common practice that is not defined in the standard and you are enforcing in your code, write a brief note on it for yourself and your team.

您应该使用编码标准，最好是像PSR-1 / 2这样的公共标准。 对于标准中未定义且您正在执行的任何常规做法，请为您自己和您的团队编写简短的说明。

2. Are you using standard syntax for constructs, or an alien syntax?

2.您是否使用标准语法进行构造，还是使用外来语法？

In PHP you may have several styles for writing various constructs (like PHP alternative syntax for control structures). If you are using alien syntax, for example using the alternative syntax only inside HTML templates and the C-style syntax in standard code, document this to avoid ambiguity. Better yet, stick to only one style. I prefer using the C-style syntax throughout all of my projects and avoid alien syntax all together.

在PHP中，您可能有几种编写各种构造的样式(例如，用于控制结构PHP替代语法)。 如果使用的是外来语法，例如仅在HTML模板内部使用替代语法，以及在标准代码中使用C样式语法，请记录此内容以避免歧义。 更好的是，仅坚持一种风格。 我更喜欢在我的所有项目中使用C样式的语法，并且避免一起使用外来语法。

3. Does each file have a header comment documenting its role in the project?

3.每个文件是否都有标题注释，说明其在项目中的作用？

As a minimum, you should include a header comment with the following in each code file:

至少，您应该在每个代码文件中包含带有以下内容的标题注释：

• Application name, version, and a brief description.
  应用程序名称，版本和简要说明。
• File relation to other files and to which package/group it belongs if any.
  与其他文件的文件关系，以及它所属的包/组。

4. Is global code kept to a minimum?

4.全局代码是否保持最少？

Global code is fine for quick scripting and single-file solutions, but when you build complex web applications, global code can become your biggest headache. Keep it to a minimum as much as possible.

全局代码适用于快速脚本编写和单文件解决方案，但是当您构建复杂的Web应用程序时，全局代码可能会成为您最大的麻烦。 尽可能减少它。

If global code contains blocks other than functions and class definitions, like control structures, then you should refactor your code into functions or classes as well. As a general rule of thumb, don’t include control structures in global code.

如果全局代码包含除函数和类定义之外的其他块(例如控件结构)，那么您也应该将代码重构为函数或类。 根据一般经验，不要在全局代码中包含控制结构。

命名 (Naming)

1. Do the names of your classes, variables, etc. follow a standard pattern/style throughout your code?

1.在整个代码中，类的名称，变量等是否遵循标准的模式/样式？

Variables, constants, functions, methods, classes, and namespaces should all follow a unified style of naming for over the whole code base, and would likely be part of the general coding standard you are using else you need to enforce it.

变量，常量，函数，方法，类和名称空间应在整个代码库中都遵循统一的命名方式，并且可能是您正在使用的通用编码标准的一部分，否则您需要强制实施。

2. Are names meaningful and unambiguous?

2.名称有意义且明确吗？

The names you use for variables, functions, etc. should be meaningful. Don’t create names like $abc, rather use names like $count, getFile() which are good and understandable. An exception to this would be variables with well-known behavior, such as counter variables $i/$j/$k in a loop.

您用于变量，函数等的名称应该有意义。 不要创建诸如$abc类的名称，而应使用诸如$count ， getFile()类的好名称并且易于理解。 例外情况是具有众所周知行为的变量，例如循环中的计数器变量$i / $j / $k 。

3. Are names too long or too short?

3.名称是否太长或太短？

Variable names and constants should be on average around 8-12 character long. Some exceptions might reach 25 chars, but more than that is unreadable and cumbersome, so if you have any which are very long (or very short) then you should rethink its usage. Thinking about usage helps craft better names.

变量名称和常量的平均长度应在8到12个字符之间。 某些异常可能达到25个字符，但超出此范围是不可读且麻烦的，因此，如果您有任何非常长(或很短)的字符，则应重新考虑其用法。 考虑使用方法有助于制作更好的名称。

The names of methods/functions should be on average around 15-25 character long, though some exceptions might reach 30. As with variable names, you should re-think any longer/shorter ones.

方法/函数的名称平均应长约15-25个字符，尽管有些例外可能达到30个。与变量名一样，您应该重新考虑任何长/短的变量/名称。

Class names should be as short as possible and expressed as nouns. If you are following a coding standard then follow its conventions for classes, otherwise your class name should be around 10-15 chars.

类名应尽可能短，并以名词表示。 如果您遵循编码标准，则请遵循其类的约定，否则您的类名称应为10-15个字符。

表达方式 (Expressions)

1. Do expressions follow a standard pattern/style?

1.表达式是否遵循标准的模式/样式？

How you write expressions and format them is crucial for code readability. Some prefer to add a space before and after operators, like $counter = 15; while some pefer no space at all. Whichever you choose, be consistent throughout all of your code.

如何编写表达式并设置其格式对于代码的可读性至关重要。 有些人喜欢在运算符前后添加一个空格，例如$counter = 15; 而有些则根本没有空间。 无论您选择哪种方式，都应在所有代码中保持一致。

2. Are expressions easy to understand, or are they too complicated?

2.表达式易于理解还是过于复杂？

For too complicated/too long expressions, split the expression across multiple lines. As a general rule, if your expression contains three or more different operands, you should probably write a comment for it for the sake of understanding it in the future. Of course, updating the comment when you update the expression is important, too. Don’t miss that! :)

对于过于复杂/太长的表达式，请将表达式分成多行。 通常，如果您的表达式包含三个或更多不同的操作数，则您可能应该为此写一个注释，以便将来理解它。 当然，更新表达式时更新注释也很重要。 不要错过！ :)

代码块 (Code blocks)

1. Do code blocks follow a standard pattern/style?

1.代码块是否遵循标准的样式/样式？

Code blocks are the basic building blocks of your code base. You should review how each should look before writing a single line and stick to that since the human eye is more sensitive to style than the content itself. Stick to your standard on where to put brackets, spaces, etc. Your eyes will read through the constructs faster when regular rules are applied and you’ll be able to understanding it easier.

代码块是代码库的基本构建块。 您应该在编写单行之前检查每个外观，并坚持这一行，因为人眼比内容本身对样式更敏感。 坚持在放置括号，空格等位置的标准。当应用常规规则时，您的眼睛会更快地阅读结构，并且您将更容易理解它。

2. Are blocks longer than 20-25 lines on average?

2.块平均长于20-25行吗？

If your code blocks are longer than 30 lines, I would recommend refactoring it at least once, though you may need to refactor more than a single iteration to get better code. Some exceptions might reach 50 lines or a bit more, but they are still exceptions and shouldn’t be habit. Longer code isn’t as readable; small chunks of code are more readable and maintainable than large ones.

如果您的代码块长于30行，我建议至少重构一次，尽管您可能需要重构一次以上才能获得更好的代码。 一些异常可能达到50行或更多，但它们仍然是异常，不应该成为习惯。 较长的代码不那么可读。 小代码块比大代码更具可读性和可维护性。

3. Are code blocks well commented to explain what functionality they add?

3.是否对代码块进行了注释，以说明它们添加了哪些功能？

In perfect code, each code block should say in words what it achieves in code. Keep this as a rule, but we all know that life’s not perfect so you might just need to do this for code blocks which are longer than the average (more than 20-25 lines), or any which perform a complex task. This is left to your sense, but I myself prefer adding a single line comment before any block briefing the future-reader of its intention, unless it’s trivial.

在完美的代码中，每个代码块都应该用语言说出它在代码中所取得的成就。 坚持这一原则，但是我们都知道生活并不完美，因此您可能只需要对比平均长度(超过20至25行)长的代码块或执行复杂任务的代码块执行此操作。 这是您可以理解的，但是我本人更喜欢在向未来读者介绍其意图的任何块之前添加一行注释，除非这很琐碎。

摘要 (Summary)

Now you can start refactoring code to make it more readable using this article as a checklist as a starting point. There’s no excuse for your code to not always be in a healthy state regarding readability. I would even recommend you put these questions in a spreadsheet along with your source code and schedule refactoring tasks based on it, or just use it whenever you feel like your code is not healthy.

现在，您可以开始使用本文的清单作为起点，来重构代码以使其更具可读性。 您的代码没有任何理由不能始终保持良好的可读性。 我什至建议您将这些问题与源代码一起放在电子表格中，并根据它安排重构任务，或者只是在感觉代码不健康时就使用它。

In the upcoming parts of we’ll focus on refactoring for extensibility and efficiency. Stay tuned!

在接下来的部分中，我们将专注于重构以提高可扩展性和效率。 敬请关注！

Image via Fotolia

图片来自Fotolia

翻译自: https://www.sitepoint.com/practical-code-refactoring-2/

重构-改善既有代码设计