让代码更好_1个干净的代码，我们都可以成为更好的编码员-CSDN博客

让代码更好

Definition of the clean: “free from dirt, marks, or stains.”

清洁的 定义 ：“没有污垢，痕迹或污渍。”

Write clean code is for me what makes us better coders, it took me a while to figure out how much I could be a better developer by just really caring when I write a single line of code. We tend to ignore and forget that the code we write today is going to be read by someone else in the future, or even by ourselves.

对我来说，编写干净的代码是什么使我们成为更好的编码人员，所以花了我一段时间才弄清楚，只要编写一行代码，我就能真正成为一名更好的开发人员。我们倾向于忽略并忘记我们今天编写的代码将来会被其他人甚至我们自己读取。

Have you even write code, one day, and the day after you just don’t know who wrote that code? Yes, I know how you felt, that is a very dangerous feeling.

有一天甚至以后的一天，您甚至不知道是谁编写的代码，您是否编写过代码？是的，我知道您的感觉，这是一种非常危险的感觉。

Before we start talking more about clean code, it extremely important to thanks the author Robert C. Martin or how everybody knows him Uncle Bob for the book called “Clean Code” that was first published in 2008, and it was ranked as one of the best selling books on Amazon. If you are a developer and intend to be one, this book is really a must-read.

在我们开始谈论干净代码之前，非常感谢作者罗伯特·C·马丁(Robert C. Martin)或大家如何认识他， 鲍勃叔叔(Uncle Bob)于2008年首次出版了这本名为《干净代码》的书。亚马逊上最畅销的书籍。如果您是一名开发人员并打算成为一名开发人员，那么这本书确实是一本必读的书 。

So all the things I'm going to point here are going to be things that make the most sense to me based on what Uncle Bob describe in his book, and others discussion about clean code.

因此，根据鲍勃叔叔在书中所描述的内容以及其他有关干净代码的讨论，我要指出的所有事情对我来说都是最有意义的。

功能 (Functions)

Break functions in very little chunks, around 4–6 lines.
中断功能很少，大约4至6行。
It should be extracted to more and more functions until it does only one thing. (Single Responsibility Principle).
它应该被提取到越来越多的功能，直到只做一件事。 ( 单一责任原则 )。
It should receive max three arguments, the ideal would be 0 arguments
它应该接收最多三个参数，理想情况是0个参数
It should NOT receive booleans
它不应该接收布尔值

// We should not do this.
public calculate(hasDiscount: boolean, isAdmin: boolean): number {}// Now imagine you reading the code function being called
calculate(true, false) // What does true means, what about false?

5. If a function returns void should have a side effect, it changes the state of the system.

5.如果函数返回void应该有副作用，它将改变系统的状态。

6. If a function does not return void it should NOT have a side effect.

6.如果一个函数没有返回void，那么它就不会有副作用。

7. Functions should have a shorter name when the scope is big, and have long names when the scope is short. This way when the function is tiny you can better name it to really explain what is the purpose of it, but when the scope is big you cannot describe all it does without having a crazy long name. Most of the time that long function can be extracted to small functions.

7.函数的范围较大时，函数名称应较短；当范围较小时，函数应使用长名称。这样，当函数很小时，您可以更好地命名它，以真正说明它的目的，但是当范围很大时，如果没有疯狂的长名，您将无法描述它的全部功能。大多数情况下，长功能可以提取为小功能。

// Short Function Example
calculateTheAreaOfCircle(): number {
  return Math.PI * this.radius * this.radius
}

8. Functions should not have more than one or two indentation levels.

8.函数的缩进级别不得超过一或两个。

注释 (Comments)

Comments should be made at the last resource, try everything else then comments if the code cannot explain itself.
注释应该在最后一个资源处进行，如果代码无法解释自身，请尝试其他所有操作，然后注释。
If you need to add a comment like a TODO try not to commit them, otherwise it will be a NOT TODO in the future.
如果您需要添加注释(例如TODO)，请尝试不要提交它们，否则将来将是NOT TODO。
When you write a great function name there is no need to add comments.
当您编写出色的函数名称时，无需添加注释。
If a comment does not make sense just delete it, whenever you find one.
如果没有任何意义，请在发现任何评论时将其删除。

切换语句 (Switch Statements)

Avoid them as much as you can.
尽量避免使用它们。
You can probably make use of polymorphism to avoid using switch statements.
您可能可以利用多态来避免使用switch语句。

// Beforeexport class Textbox {
  draw(): void {
    // Draw a textbox
  }
}export class Checkbox {
  draw(): void {
    // Draw a checkbox
  }
}export class RadioButton {
  draw(): void {
    // Draw a radiobutton
  }
}// Every new control we must come back and add a case.
drawUiControl(type: string) {
  switch (type) {
    case "TEXTBOX":
      new TextBox().draw();
     break;
    case "CHECKBOX":
      new Checkbox().draw();
    break;
    default:
      new RadioButton().draw();
    break;
}// After using Polymorphismexport abstract class UiControl {
  abstract draw(): void {
    // Draw a control
  }
}export class Textbox extends UiControl {
  draw(): void {
    // Draw a textbox
  }
}export class Checkbox extends UiControl {
  draw(): void {
    // Draw a checkbox
  }
}export class RadioButton extends UiControl {
  draw(): void {
    // Draw a radiobutton
  }
}// No more switch statementsdrawUiControl(control: UiControl) {
  control.draw();
}

变量命名 (Variables naming)

A variable name should tell us the significance of what that variable contains. e.g elapsedTimeInDays.
变量名称应告诉我们该变量包含的含义。例如elapsedTimeInDays。
Avoid not pronounceable names, e.g InfoRTC123, DataSkk44
避免使用不发音的名称，例如InfoRTC123，DataSkk44
Avoid using the prefixed variables. e.g m_value or f_test
避免使用带前缀的变量。例如m_value或f_test

干-不要重复自己 (DRY — Don’t Repeat Yourself)

Any duplicated code should be extracted to small functions, it’s going to reduce the number of lines of code, and also make our life easier when a change needs to be done.

任何重复的代码都应提取为小函数，这将减少代码行数，并在需要进行更改时使我们的工作更轻松。

首选异常而不是错误代码 (Prefer Exception and not Error Codes)

When we have to return error codes we need to map each error code and also check the returning error code. For most case throwing an exception is much better and simplify the work.

当我们必须返回错误代码时，我们需要映射每个错误代码并检查返回的错误代码。在大多数情况下，抛出异常要好得多，并且可以简化工作。