探讨代码实现中的若干问题

Robert C. Martin在《清洁代码》一书的第17章中，介绍了‘代码气味’这一概念，指的是那些虽然未违反任何明确的标准（无论是正式还是非正式的），但却透露出开发者缺乏经验或纪律性的代码特征。这一概念对我启发很大，尤其在我频繁与不同团队合作时，经常遇到这类‘代码气味’，它们不仅增加了代码解读的难度，还严重影响了代码的可维护性。

例如，关于方法参数的数量，Martin建议理想状态是没有参数，但最多不超过三个。这个‘三’是一个经验值，我个人也倾向于遵守这一规则，但在某些特定条件下可能会有所不同。对于已有的大型代码库，直接限制参数数量可能不太现实，不过我有几点建议可以尝试解决这个问题：

1. 如果多个参数来源于同一个对象实例，可以考虑将整个对象作为参数传入，然后在方法内部按需访问其属性。
2. 考虑将该方法直接实现于对象本身，这样就可以避免在方法内部引用外部对象。
3. 对于无法通过简单重构减少参数的情况，特别是当重构风险过高时（如时间紧迫等），可以创建一个临时对象来封装所有必要的属性，然后将这个对象作为单一参数传递给方法，或者将方法实现在这个临时对象上。

另一个常见的‘代码气味’是‘输出参数’的问题，即方法的参数不仅是输入，还会被方法的逻辑修改。这种做法在面向对象编程出现前较为常见，但现在更推荐的做法是利用‘this’关键字作为输出参数。同样，最好的做法是让受影响的对象自身实现该方法。

使用布尔标志参数来指示方法可能执行的两种不同功能也是一个常见问题。更好的解决方案是将逻辑拆分为两个独立的方法，每个方法负责一种情况，这不仅使得方法的命名更具描述性，也使代码更加清晰易懂。如果两种逻辑路径在分叉前有很多共通之处，可以创建第三个方法来处理这部分公共逻辑，同时在其他两个方法中保持各自的特殊逻辑。

此外，作者虽然没有提及，但我认为在方法实现中使用局部变量作为返回值，而不是直接返回对象本身，也是一种良好的实践。比如，在满足特定条件时设置局部变量，并在方法结束时返回该变量，可以使方法的退出点更加明确，提高代码的可读性和可维护性。

最后，值得一提的是‘死函数’的问题，即系统中从未被调用过的函数。版本控制系统存在的意义就在于此——合理利用它，可以有效管理代码变更历史，避免无用代码的累积。