如果每一行都计算条件，如果你写这样的代码:

Dim a as Boolean = True
If a Then
    Console.WriteLine("1")
    a = False
    Console.WriteLine("2")
Else
    Console.WriteLine("3")
End If

那么输出将是:

1
3

My co-workers were/are producing supposedly bad code because they sucked/suck. It took me a while to learn that I should first check what really happened. Most of the times, bad code was caused by lack of management, customers who didn't want to check what they really wanted and started changing their minds like there's no tomorrow, or other circunstances out of anyone's control, like economic crysis. Customers demand "for yesterday" features because they are stupid: Not really. It's about communication. If someone tells them it everything can really be done in 1 week, guess what? they'll want it in 1 week. "Never change code that works". This is not a good thing IMO. You obviously don't have to change what's really working. However, if you never change a piece of code because it's supposedly working and it's too complex to change, you may end up finding out that code isn't really doing what it's supposed to do. Eg: I've seen a sales commission calculation software doing wrong calculations for two years because nobody wanted to maintain the software. Nobody at sales knew about it. The formula was so complex they didn't really know how to check the numbers.

私有成员变量是实例私有的，而不是类私有的。

代码审查是浪费时间。

从一家完全可选的公司搬到一家强制性的公司(甚至是被审计的)，我逐渐明白了它们的用处。对代码有另一双眼睛，即使是最琐碎的部分，也可以:

A)当你搞砸了一些琐碎的事情时，避免你的尴尬(例如，在我之前的工作中，一个琐碎的代码审查可以防止我们向客户发送数百封垃圾邮件)

B)可以教给你你一开始不知道的东西(我在我目前的工作中学习了新的库——不可避免的是在一家大公司，有人已经偶然发现了你的问题，并做了更好的解决工作——这只是知道在哪里寻找的问题)

C)至少要确保除了你自己之外还有其他人知道事情是如何运作的。

最后，我对我在这里提交的代码比我以前的工作更满意，尽管那时我认为我什么都知道:)

这很尴尬，但很长一段时间我都没有真正理解引用类型和值类型之间的区别。我以为你必须使用ref关键字来改变一个对象在不同的方法。

这是我应该知道的c#最基本的概念之一。

您无法诊断生产中的“间歇性错误”。重新启动服务器是解决这个问题的唯一方法。

也许在我早期的ASP编码中更真实。但是有很多很好的分析工具可以发现内存泄漏和其他奇怪的问题。Perfmon还提供了许多良好的诊断数据。另外，您应该在应用程序中编写诊断日志。