Err is human.
However, many errors committed by developers can be avoided. If you can avoid these common mistakes mentioned in this article, you will be able to write better and more concise code.
This is not only beneficial in itself, but also good for other developers who need to see the code. So avoid common mistakes is not just for himself - also helped the team a lot.
In summary, this is a small core we compiled a list of common mistakes to avoid:
1. The non-descriptive variable name
Good variable names are very important, then how can not be overstated. In many cases, you're not the only one project developers, other developers also need to understand the code you write.
Choose a good name takes time, but you can save even more time.
2. The magic number, and the string
Next non-descriptive variable named above, skip to the next one, that is not assigned to a variable on, is also known as a magic number or magic string.
Wikipedia definition:
The magic number is the only value, meaning having unexplained and appears more than once, can and should be named constant replacement.
Consider the following code fragment:
for ($i = 1; $i <= 52; $i++) {
...
}
The embodiment in figures 52 is a magic number. What people do not understand why this number 52 and their representatives. Why 52? Why can not a 64? These are the total number of weeks in the year it is?
The method is more clear:
$cardDeckSize = 52;
for
($i = 1;$i <= $cardDeckSize; $i++)
{
...
}
Now everyone will understand that this is a deck of cards in circulation. The code to other developers provide context. In addition, change the value easier, because the value is stored only once in a variable, it will not be repeated.
Magic number is often used multiple times in different locations of the program, and therefore prone to error.
The same is true for the string, the same method can be employed:
if (userPasswordIsValid($user,"6yP4cZ".$password)) {
...
}
What 6yP4cZ that? It seems very random.
$salt = "6yP4cZ";if(userPasswordIsValid($user, $salt.$password)) {
...
}
Haha, now made sense!
3. Code format confusion
混淆代码的格式通常是那些没有丰富编程经验的人才会犯的。如果问有着多年经验的开发人员，问他们是否认识一个测试人员或数据科学家混淆过代码格式，他们可能都会点头。这是由于缺乏经验——除非使用像Python这样的编程语言，可以避免很多此类失误。
解决格式混乱最常见的方法是使用linter(应用代码校验)。现代集成开发系统(IDEs)也都有可能解决这个问题。有时需要安装一个插件，有时也可以直接完成。
4. 在一个函数中进行太多内容
根据单一职责模式，一个函数只应负责做一件事，只有一件事。笔者看到过太多函数集结了获取、处理并呈现数据三个功能。把这个函数分开处理才是好的编程，一个函数获取数据，一个函数处理数据，另一个函数显示数据。
一个函数只关注一个内容之所以重要，是因为这能让其运行更稳健。比如说，从API(应用程序接口)中获取数据。如果API有变动——例如，出现了一个新版本——那么如果处理代码同属一个函数，那么处理代码过程中断的风险就会更大，这很可能会导致数据显示也被中断。
5. 硬编码
硬编码是将数据直接嵌入到程序或其他可执行对象的源代码中的软件开发行为，而不是从外部获取数据或在运行时生成数据。
硬编码的值不允许更改;它们是固定值。硬编码被看作是一种反模式，或者至少是意味着一种坏代码。
硬编码最多的东西，不管是什么(有时甚至有效)原因，都是密码和文件位置。
人们看到的很多硬编码密码场景是用于外部服务或API的身份验证。这些证书往往被硬编码，但并不是很好的做法。
如果发现自己硬编码了很多东西，真的应该仔细审视自己写的代码，因为大多数时候这都不是解决问题的好方法。
6. 注释掉代码
人们看到过包含多个函数的代码块被注释掉。没人知道为什么它还在那里，而且没人知道这段代码是否还有意义。但是，没人会删除这段代码，而这是开发人员真正应该做的事情。之所以没人删除这段代码，是因为每个人都认为其他人可能会用到。
只需删除那段注释掉的代码即可。即使代码不在新的版本中，如果有人想使用，该代码仍然可以在版本控制中使用。
