斯巴达程序设计

Question

我真的很喜欢杰夫职位在斯巴达程序设计上。我同意这样的代码是joy读的。不幸的是，我不太确定这一定是一个joy的工作。

多年来，我读到并坚持“一字一句”的做法。当许多编程书籍用示例代码反驳这一建议时，我进行了良好的斗争，并坚持了自己的立场，例如：

while (bytes = read(...))
{
   ...
}

while (GetMessage(...))
{
   ...
}

最近，出于更实际的原因，我提倡每行一个表达式--调试和生产支持。从产品中获取一个日志文件，该文件在“第65行”声明一个NullPointer异常，该文件内容如下：

ObjectA a = getTheUser(session.getState().getAccount().getAccountNumber());

是令人沮丧的完全可以避免的。除了用可以选择空值的“最有可能的”对象的代码来抓住专家.这是一个真正的实际痛苦。

在执行代码时，每行有一个表达式也会有很大帮助。在实践中，我假设大多数现代编译器可以优化我刚刚创建的所有多余的临时对象.

我试着保持整洁--但把代码中的显式对象弄得乱七八糟，有时肯定会觉得很辛苦。它通常不会使代码更容易浏览--但在产品中跟踪或逐步遍历我或其他人的代码时，它确实很有用。

你提倡哪种风格，从实际意义上讲，你能把它合理化吗？

Answer 1

在中，实用主义程序员 Hunt和Thomas谈到了一项他们称之为Demeter的研究，它的重点是将函数耦合到其他模块上。通过允许一个函数在它的耦合中永远不会达到第3级，您可以显着地减少错误的数量，并增加代码的可维护性。

所以：

getTheUser(session.getState().getAccount().getAccountNumber())；a= ObjectA

接近重罪，因为我们是老鼠洞里的4个物体。这意味着要在其中一个对象中改变一些东西，我必须知道，您在这个方法中调用了整个堆栈。好痛啊。

更好的是：

Account.getUser()；

注意，这与现在在模拟软件中非常流行的表现形式的编程是背道而驰的。这里的折衷之处在于，无论如何，您都有一个紧密耦合的接口，而表达式语法只会使它更易于使用。

Answer 2

我认为理想的解决办法是在两个极端之间找到一个平衡。没有办法写出一条适用于所有情况的规则，它伴随着经验。在自己的行上声明每个中间变量将使读取代码变得更加困难，这也会增加维护的难度。同样，如果内联中间值，则调试要困难得多。

“甜点”在中间的某个地方。

Answer 3

每行一个表达式。

没有理由混淆您的代码。输入这几个额外条款所需的额外时间，可以节省调试时间。