查看代码时，哪些事情会立即敲响警钟？[关闭]

几周前，我参加了一次软件工艺活动，当时发表的评论之一是“我相信我们在看到错误代码后都会认出错误代码”，每个人都明智地点头，无需进一步讨论。

这种事情总是让我感到担忧，因为有人认为每个人都认为自己是高于平均水平的司机。尽管我认为我可以识别错误的代码，但我还是想了解更多有关其他人认为代码气味的信息，因为很少有人在博客上或仅在少数书籍中对此进行详细讨论。尤其是，我想听到一种语言而不是另一种语言中的代码味道会很有趣。

我将从一个简单的开始：

源代码管理中注释掉代码比例很高的代码 -为什么在其中？是要删除吗？是半成品吗？也许不应该将其注释掉，而只有在有人测试某些东西时才进行注释？就个人而言，我发现这种事情确实很烦人，即使只是到处都是奇数行，但是当您看到大块的代码散布在其余的代码中时，那是完全不可接受的。通常，这也表明该代码的其余部分也可能具有可疑的质量。

/* Fuck this error */

通常会在一个废话try..catch块中找到，它会引起我的注意。差不多/* Not sure what this does, but removing it breaks the build */。

还有两件事：

• 多个嵌套的复杂if语句
• 尝试捕获块，用于定期确定逻辑流
• 与通用名称的功能process，data，change，rework，modify
• 100行中六到七种不同的支撑样式

我刚发现的一个：

/* Stupid database */
$conn = null;
while(!$conn) {
    $conn = mysql_connect("localhost", "root", "[pass removed]");
}
/* Finally! */
echo("Connected successfully.");

正确，因为必须蛮力地使用MySQL连接才是正确的处理方式。事实证明，数据库的连接数存在问题，因此它们一直处于超时状态。他们没有调试它，而是反复尝试直到它起作用为止。

对我来说，主要的危险标志是重复的代码块，因为这表明该人要么不了解编程基础知识，要么就因为太害怕而无法对现有代码库进行适当的更改。

我以前也把缺少注释视为危险信号，但是最近在处理很多非常好的代码而没有注释的情况下，我对此进行了缓解。

试图展示程序员的聪明才智的代码，尽管它没有增加任何实际价值：

x ^= y ^= x ^= y;

• 20,000（夸张）线功能。任何占用多个屏幕的功能都需要重构。

• 同样，类文件似乎永远存在。可能有一些概念可以抽象到类中，这些概念将清除原始类的目的和功能，以及可能在哪里使用它，除非它们都是内部方法。

• 非描述性，非平凡变量，或太多非琐碎的非描述性变量。这些使人们推论出实际发生的谜团。

{ Let it Leak, people have good enough computers to cope these days }

更糟糕的是，这是来自商业图书馆！

注释非常冗长，以至于如果有英文编译器，它将可以编译并完美运行，但不会描述代码没有的任何内容。

//Copy the value of y to temp.
temp = y;
//Copy the value of x to y.
y = x;
//Copy the value of temp to x.
x = temp;

此外，如果代码遵循一些基本准则，则可以删除对代码的注释：

//Set the age of the user to 13.
a = 13;

编译时产生警告的代码。

名称中带有数字而不是描述性名称的函数，例如：

void doSomething()
{
}

void doSomething2()
{
}

请让函数名称有意义！如果doSomething和doSomething2做类似的事情，请使用区分差异的函数名称。如果doSomething2是doSomething的功能突破，请为其功能命名。

魔术数字或魔术字符串。

   if (accountBalance>200) { sendInvoice(...); }

   salesPrice *= 0.9;   //apply discount    

   if (invoiceStatus=="Overdue") { reportToCreditAgency(); }

• 也许不是最坏的情况，但可以清楚地显示实现者级别：

  if(something == true) 

• 如果一种语言具有for循环或迭代器构造，则使用while循环还可以演示实现者对该语言的理解程度：

  count = 0; 
  while(count < items.size()){
     do stuff
     count ++; 
  }
  
  for(i = 0; i < items.size(); i++){
    do stuff 
  }
  //Sure this is not terrible but use the language the way it was meant to be used.

• 文档/注释中的拼写/语法不佳几乎和代码本身一样吃。这样做的原因是因为代码是供人类阅读和运行机器的。这就是为什么我们使用高级语言的原因，如果您的文档难以理解，则会使我在不看代码的情况下先发制人地对代码库形成负面意见。

我立即注意到的是深层嵌套的代码块（如果是，虽然是等）的频率。如果代码的深度经常超过两个或三个级别，则说明设计/逻辑问题。而且，如果它深入到8个巢穴，则最好有充分的理由使它不被分解。

给学生的课程评分时，有时可以说出“眨眼”的时刻。这些是即时线索：

• 格式不良或不一致
• 连续超过两个空行
• 非标准或不一致的命名约定
• 重复代码，重复次数越多，警告越强烈
• 一段简单的代码应该过于复杂（例如，以复杂的方式检查传递给main的参数）

我的第一印象很少是正确的，这些警告钟在大约95％的时间内是正确的。一个例外是，该语言的新学员使用的是另一种编程语言的样式。挖掘并用另一种语言重新阅读他们的风格，这为我消除了警钟，然后学生获得了充分的信誉。但是这种例外很少见。

在考虑更高级的代码时，这是我的其他警告：

• 许多 Java类的存在，它们只是用于保存数据的“结构”。无论这些字段是公共字段还是私有字段，以及使用获取方法/设置方法，都仍然不是经过深思熟虑的设计的一部分。
• 名称不佳的类，例如只是一个名称空间，并且代码中没有真正的凝聚力
• 引用代码中甚至没有使用的设计模式
• 空的异常处理程序，无需解释
• 当我在Eclipse中提取代码时，代码中有数百个黄色的“警告”，主要是由于未使用的导入或变量

在样式方面，我通常不喜欢看到：

• 仅回显代码的Javadoc注释

这些只是错误代码的线索。有时看似不好的代码实际上不是，因为您不了解程序员的意图。例如，可能有一个很好的理由，即某些事情看起来过于复杂-可能还有其他考虑因素在起作用。

个人喜好/宠爱：IDE生成的名称被使用。如果TextBox1是系统中的主要变量，那么代码审查就会给您带来另一件事。

完全未使用的变量，尤其是当变量的名称类似于所使用的变量名称时。

很多人提到：

//TODO: [something not implemented]

虽然我希望这些东西得到实施，但至少他们做了一个说明。我认为更糟糕的是：

//TODO: [something that is already implemented]

如果您从未想过将它们删除，那么Todo毫无价值，而且会造成混淆！

需要我向下滚动才能阅读所有内容的方法。

方法名称中的连词：

public void addEmployeeAndUpdatePayrate(...) 


public int getSalaryOrHourlyPay(int Employee) ....

说明：敲响警钟的原因是它表明该方法可能违反了单一责任原则。

将GPL的源代码链接到一个商业的，封闭源代码的程序中。

它不仅造成了直接的法律问题，而且根据我的经验，它通常表示粗心或无关紧要，这也反映在代码的其他地方。

语言不可知：

• TODO: not implemented
• int function(...) { return -1; } （与“未实施”相同）
• 由于非异常原因而引发异常。
• 滥用或不一致使用0，-1或null作为特殊的返回值。
• 断言没有令人信服的评论说为什么它永远不会失败。

特定语言（C ++）：

• 小写的C ++宏。
• 静态或全局C ++变量。
• 未初始化或未使用的变量。
• 任何array new显然不安全的RAII。
• 显然不是边界安全的数组或指针的任何使用。这包括printf。
• 数组未初始化部分的任何使用。

特定于Microsoft C ++：

• 与任何Microsoft SDK头文件已定义的宏冲突的任何标识符名称。
• 通常，对Win32 API的任何使用都会引起很大的警钟。始终打开MSDN，并在有疑问时查找参数/返回值定义。（已编辑）

特定于C ++ / OOP：

• 实现（具体类）继承，其中父类同时具有虚拟和非虚拟方法，而在应该/不应该虚拟之间没有明显的明显概念区别。

奇异的缩进样式。

有两种非常流行的样式，人们会将这场辩论推向高潮。但是有时候我看到有人使用一种非常罕见的，甚至是一种自家的缩进样式。这表明他们可能没有与自己以外的任何人进行编码。

使用大量文本块，而不是枚举或全局定义的变量。

不好：

if (itemType == "Student") { ... }

更好：

private enum itemTypeEnum {
  Student,
  Teacher
}
if (itemType == itemTypeEnum.Student.ToString()) { ... }

最好：

private itemTypeEnum itemType;
...
if (itemType == itemTypeEnum.Student) { ... }

弱类型的参数或方法的返回值。

public DataTable GetEmployees() {...}

public DateTime getHireDate(DataTable EmployeeInfo) {...}

public void FireEmployee(Object EmployeeObjectOrEmployeeID) {...}

• 多个三元运算符串在一起，因此它不再像一个if...else块，而是变成一个if...else if...[...]...else块
• 长变量名，不带下划线或驼峰。我从一些代码中提取了示例：$lesseeloginaccountservice
• 文件中的几百行代码，几乎没有注释，并且代码非常不明显
• 过于复杂的if陈述。代码示例：if (!($lessee_obj instanceof Lessee && $lessee_obj != NULL))我砍掉了if ($lessee_obj == null)

代码气味：不遵循最佳做法

这种事情总是让我感到担忧，因为有人认为每个人都认为自己是高于平均水平的司机。

这是您的新闻快讯：世界上50％的人口智力水平低于平均水平。好的，所以有些人的智力完全是平均的，但是我们不要挑剔。另外，愚蠢的副作用之一是您无法识别自己的愚蠢！如果结合使用这些语句，事情看起来就不会那么好。

查看代码时，哪些事情会立即敲响警钟？

已经提到了很多好东西，并且通常来说，不遵循最佳实践是一种代码味道。

最佳做法通常不是随机发明的，并且经常是有原因的。很多时候它可能是主观的，但以我的经验，它们大多数都是合理的。遵循最佳做法应该不是问题，如果您想知道为什么会这样，请研究它而不是无视和/或抱怨它-也许是有道理的，也许不是。

最佳做法的一个示例可能是在每个if块中使用curly，即使它仅包含一行：

if (something) {
    // whatever
}

您可能没有必要，但我最近读到它是错误的主要来源。始终使用括号也已经在讨论堆栈溢出，并检查if语句有括号也是规则的PMD，静态代码分析器为Java。

请记住：“因为这是最佳做法”，对于“您为什么要这样做？”这个问题永远是无法接受的答案。如果您无法阐明为什么某事是最佳实践，那么它不是最佳实践，那是一种迷信。

说“这是因为froz子系统的设计完全令人厌烦”。

这贯穿了整个段落。

他们解释说，需要进行以下重构。

但是没有做到。

现在，由于时间或能力方面的问题，他们当时可能已经被老板告知他们不能更改它，但这也许是因为人们太小了。

如果主管认为是j.random。程序员无法进行重构，那么主管应该这样做。

无论如何，我知道代码是由一支分散的团队编写的，具有可能的权力策略，并且他们没有重构沉闷的子系统设计。

真实的故事。它可能发生在您身上。

谁能想到一个示例，其中代码应通过绝对路径合法地引用文件？

捕获一般异常：

try {

 ...

} catch {
}

要么

try {

 ...

} catch (Exception ex) {
}

区域过度使用

通常，使用太多区域向我表明您的课程太大。这是一个警告标志，表示我应该进一步研究该代码段。

类命名约定表明对他们试图创建的抽象的理解不足。或根本不定义抽象。

在一个VB类中，我想到了一个极端的例子Data，在第一个文件中，该类的标题为30,000+行。这是一个局部类，分为至少六个其他文件。大多数方法都是使用名称为的存储过程包装程序FindXByYWithZ()。

即使没有那么生动的例子，我也确信我们所有人都只是将逻辑“倾销”到了一个构思欠佳的类中，给了它一个完全通用的标题，后来又后悔了。

重新实现语言基本功能的功能。例如，如果您曾经在JavaScript中看到过“ getStringLength（）”方法，而不是对字符串的“ .length”属性的调用，则说明您遇到了麻烦。

#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...

当然没有任何类型的文档，偶尔会有嵌套的#defines