你的代码能闻到！如何修复

在本文中，我们将重点介绍10种最常见的代码气味，以及如何对它们进行除臭。如果你是一个新的程序员，避免这些，你的代码会明显更好！...

代码气味是一块代码或通用编码模式，看起来它可能表明代码库的整体结构和设计中存在更深层次的问题。

把代码气味看作是任何暗示某段代码应该被重构的迹象。这并不是因为代码有缺陷或者没有功能——通常情况下，有臭味的代码运行得很好——而是臭味的代码通常很难维护和扩展，这可能会导致技术问题（尤其是在大型项目上）。

在本文中，我们将重点介绍10种最常见的代码气味，寻找什么，以及如何去除它们的气味。如果你是一个新的程序员，避免这些，你的代码会明显更好！

1紧耦合

问题

紧密耦合是指两个对象如此依赖于彼此的数据和/或函数，修改一个对象需要修改另一个对象。当两个对象耦合得太紧密时，对代码进行更改可能是一个噩梦，而且每次更改都会引入bug。

例如：

class Worker {
  Bike bike = new Bike();
  public void commute() {
    bike.drive();
  }
}

在这种情况下，工人和自行车是紧密耦合的。如果有一天你想开车而不是骑自行车上下班呢？你必须进入工人阶级，用与汽车相关的代码替换所有与自行车相关的代码。很乱，容易出错。

解决方案

您可以通过添加抽象层来放松耦合。在这种情况下，工人阶级不只是想驾驶自行车，还想驾驶汽车，也许是卡车，甚至可能是摩托车。这些都是车辆，不是吗？因此，创建一个Vehicle接口，允许您根据需要**和替换不同的车辆类型：

class Worker {
  Vehicle vehicle;
  public void changeVehicle(Vehicle v) {
    vehicle = v;
  }
  public void commute() {
    vehicle.drive();
  }
}
interface Vehicle {
  void drive();
}
class Bike implements Vehicle {
  public void drive() {
  }
}
class Car implements Vehicle {
  public void drive() {
  }
}

2上帝的目标

问题

一个上帝的对象是包含太多变量和函数的大规模类/模块。它“知道得太多”、“做得太多”，这有两个原因造成问题。首先，其他类/模块过度依赖于此类/模块来获取数据（紧密耦合）。其次，随着所有东西都被塞进同一个地方，程序的整体结构变得浑浊。

解决方案

以上帝为对象，根据它们所存在的问题来分离其数据和函数，然后将这些分组转换为对象。如果你有一个上帝的物体，它可能会更好的组成许多较小的物体。

例如，假设您有一个庞大的用户类：

class User {
  public String username;
  public String password;
  public String address;
  public String zipcode;
  public int age;
  ...
  public String getUsername() {
    return username;
  }
  public void setUsername(String u) {
    username = u;
  }
}

您可以将其转换为以下内容的组合：

class User {
  Credentials credentials;
  Profile profile;
  ...
}
class Credentials {
  public String username;
  public String password;
  ...
  public String getUsername() {
    return username;
  }
  public void setUsername(String u) {
    username = u;
  }
}

下次您需要修改登录过程时，您不必遍历大量的用户类，因为Credentials类更易于管理！

三。长函数

问题

一个长函数就是它听起来的样子：一个长得太长的函数。虽然对于一个函数来说，代码行数“太长”并没有一个具体的数字，但当你看到它时，你就会知道它是什么。这几乎是上帝对象问题的一个更严格的范围版本——一个长函数有太多的责任。

解决方案

长函数应该被分解成许多子函数，每个子函数都被设计用来处理单个任务或问题。理想情况下，原始的长函数将变成子函数调用列表，从而使代码更清晰、更易于阅读。

4参数过多

问题

一个函数（或类构造函数）需要太多参数，这有两个原因。首先，它使代码可读性降低，并且使测试变得更困难。但是第二，更重要的是，它可能表明，该函数的目的过于模糊，并且试图处理太多的责任。

解决方案

虽然“太多”对于参数列表来说是主观的，但是我们建议对任何超过3个参数的函数都要小心。当然，有时一个函数有5个甚至6个参数是有意义的，但前提是有充分的理由。

大多数时候，没有一个，代码最好将该函数分解为两个或多个不同的函数。与“长函数”代码气味不同，这一点不能仅仅通过用子函数替换代码来解决——函数本身需要被划分为包含单独职责的单独函数。

5名称错误的标识符

问题

一个或两个字母的变量名。无法描述的函数名。过度修饰的类名。用它们的类型标记变量名（例如，b\u是一个布尔变量）。最糟糕的是，在一个代码库中混合使用不同的命名方案。所有这些都会导致代码难以阅读、难以理解和维护。

解决方案

为变量、函数和类选择好的名称是一项很难学会的技能。如果您要加入一个现有的项目，请对其进行梳理，看看现有标识符是如何命名的。如果有一个风格指南，记住它并坚持它。对于新项目，考虑形成自己的风格指南并坚持下去。

一般来说，变量名应该简短，但具有描述性。函数名通常应该至少有一个动词，并且应该立即从它的名称就可以看出函数做了什么，但是要避免塞进太多的单词。类名也是如此。

6幻数

问题

你浏览了一些别人写的代码，发现了一些硬编码的数字。也许它们是if语句的一部分，或者是一些似乎没有意义的神秘计算的一部分。你需要修改函数，但是你不能理解数字的含义。划伤头部。

解决方案

在编写代码时，应该不惜一切代价避免这些所谓的“幻数”。硬编码的数字在编写时是有意义的，但是它们很快就会失去所有的意义——特别是当其他人试图维护您的代码时。

一种解决方案是留下解释数字的注释，但更好的选择是将魔术数转换为常量变量（用于计算）或枚举（用于条件语句和开关语句）。通过给神奇数字一个名字，代码一看就变得无限可读，而不太容易发生错误的变化。

7深巢

问题

有两种主要的方法来结束深度嵌套的代码：循环和条件语句。深度嵌套的代码并不总是不好的，但可能会有问题，因为它很难解析（尤其是在变量命名不好的情况下），甚至更难修改。

解决方案

如果您发现自己编写了一个双循环、三重循环，甚至是四倍循环，那么代码可能试图到达超出自身的太远，无法找到数据。相反，提供一种方法，通过函数调用任何对象或模块包含数据来请求数据。

另一方面，深度嵌套的条件语句通常是您试图在单个函数或类中处理过多逻辑的标志。实际上，深嵌套和长函数往往是并行不悖的。如果您的代码有大量的switch语句或嵌套的If-then-else语句，那么您可能需要实现一个状态机或策略模式。

在缺乏经验的游戏程序员中，深度嵌套特别普遍！

8未处理的异常

问题

例外是强大的，但很容易被滥用。懒散的程序员如果不正确使用抛出catch语句，那么调试会变得更困难，如果不是不可能的话。例如，忽略或隐藏捕获的异常。

解决方案

与其忽略或隐藏捕获到的异常，不如至少打印出异常的堆栈跟踪，这样调试器就可以使用了。让你的程序默默地失败，肯定会让你将来头疼！另外，更喜欢捕获特定异常而不是一般异常。在我们的文章中了解更多关于如何正确处理异常的信息。

9重复代码

问题

在程序的多个不相关区域中执行相同的精确逻辑。后来，您意识到需要修改该逻辑，但不记得实现它的所有地方。你最终只改变了8个地方中的5个，导致了错误和不一致的行为。

解决方案

重复代码是转换为函数的主要候选代码。例如，假设您正在开发一个聊天应用程序，并编写以下代码：

String queryUsername = getSomeUsername();
boolean isUserOnline = false;
for (String username : onlineUsers) {
  if (username.equals(queryUsername)) {
    isUserOnline = true;
  }
}
if (isUserOnline) {
  ...
}

在代码的其他地方，您意识到您需要执行相同的“此用户是否联机？”检查。您可以将循环拉出，而不是复制粘贴循环，而是将其拉出函数：

public boolean isUserOnline(String queryUsername) {
  for (String username : onlineUsers) {
    if (username.equals(queryUsername)) {
      return true;
    }
  }
  return false;
}

现在，在代码的任何地方，都可以使用isUserOnline（）检查。如果您需要修改这个逻辑，您可以调整这个方法，它将应用于任何调用它的地方。