你最具争议的编程观点是什么?

这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。

这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。

那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。

请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。

当前回答

单元测试不会帮助你写出好的代码

进行单元测试的唯一原因是确保已经工作的代码不会崩溃。首先编写测试，或者为测试编写代码都是荒谬的。如果在编写代码之前编写测试，您甚至不知道边界情况是什么。您的代码可能通过了测试，但在不可预见的情况下仍然会失败。

此外，优秀的开发人员会保持较低的内聚性，这将使新代码的添加不太可能对现有内容造成问题。

事实上，我将进一步推广，

软件工程中的大多数“最佳实践”都是为了防止糟糕的程序员造成太大的破坏。

他们的作用是指导糟糕的开发人员，防止他们犯愚蠢的错误。当然，由于大多数开发人员都很糟糕，这是一件好事，但优秀的开发人员应该得到通过。

2009-01-02 15:08:40

其他回答

当为数据访问层创建单元测试时，数据应该直接从DB中检索，而不是从模拟对象中检索。

考虑以下几点:

void IList<Customer> GetCustomers()
{
  List<Customer> res = new List<Customer>();

  DbCommand cmd = // initialize command
  IDataReader r = cmd.ExecuteQuery();

  while(r.read())
  {
     Customer c = ReadFiledsIntoCustomer(r);
     res.Add(c);
  }

  return res;
}

在GetCustomers的单元测试中，对cmd.ExecuteQuery()的调用应该实际访问DB还是应该模拟它的行为?

我认为，如果以下情况成立，您不应该模拟对DB的实际调用:

存在一个测试服务器和模式。模式是稳定的(意味着您不期望对其进行重大更改) DAL没有聪明的逻辑:查询是简单地构造的(config/stored procs) 去虹膜化的逻辑很简单。

从我的经验来看，这种方法的最大好处是你可以尽早与DB进行交互，体验“感觉”，而不仅仅是“外观”。它为您省去了许多事后的麻烦，并且是熟悉模式的最佳方法。

许多人可能会争辩说，一旦执行流跨越了进程边界，它就会成为一个单元测试。我同意它有它的缺点，特别是当数据库不可用，然后你不能运行UT。

然而，我相信在许多情况下这应该是一件有效的事情。

2009-09-28 18:50:19

使用较短的变量名是可以的

但不是嵌套循环中的索引。

2009-07-09 00:03:25

从长远来看，开源软件的成本更高

对于常规的业务公司来说，开源看起来是免费的，但隐藏着成本。