我最近正在使用一个DateTime对象，并写了这样的东西:
DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?
AddDays()的智能感知文档说它在日期后添加了一天，但它并没有这样做——它实际上返回了一个添加了一天的日期，所以你必须这样写:
DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date
这个问题以前已经困扰过我很多次了，所以我认为将最糟糕的c#陷阱分类会很有用。
当前回答
Oracle参数必须按顺序添加
这是ODP . net实现Oracle参数化查询的一个主要问题。
在向查询中添加参数时，默认行为是忽略参数名，并按添加值的顺序使用值。
解决方案是将OracleCommand对象的BindByName属性设置为true -默认为false…这是定性的(如果不是定量的)，就像有一个属性叫做DropDatabaseOnQueryExecution，默认值为true。
他们称之为特征;我称之为公共领域的坑。
请看这里了解更多细节。
其他回答
合同在流。阅读是我见过很多人被绊倒的东西:
// Read 8 bytes and turn them into a ulong
byte[] data = new byte[8];
stream.Read(data, 0, 8); // <-- WRONG!
ulong data = BitConverter.ToUInt64(data);
这是错误的原因是流。Read最多读取指定的字节数，但完全可以只读取1个字节，即使在流结束前还有7个字节可用。
它看起来与Stream如此相似，这并没有什么帮助。如果没有异常返回，则保证已写入所有字节。上面的代码几乎一直都能工作，这也没有什么帮助。当然，没有现成的、方便的方法来正确地读取N个字节也无济于事。
所以，为了堵住这个漏洞，提高人们的意识，这里有一个正确的方法:
/// <summary>
/// Attempts to fill the buffer with the specified number of bytes from the
/// stream. If there are fewer bytes left in the stream than requested then
/// all available bytes will be read into the buffer.
/// </summary>
/// <param name="stream">Stream to read from.</param>
/// <param name="buffer">Buffer to write the bytes to.</param>
/// <param name="offset">Offset at which to write the first byte read from
/// the stream.</param>
/// <param name="length">Number of bytes to read from the stream.</param>
/// <returns>Number of bytes read from the stream into buffer. This may be
/// less than requested, but only if the stream ended before the
/// required number of bytes were read.</returns>
public static int FillBuffer(this Stream stream,
byte[] buffer, int offset, int length)
{
int totalRead = 0;
while (length > 0)
{
var read = stream.Read(buffer, offset, length);
if (read == 0)
return totalRead;
offset += read;
length -= read;
totalRead += read;
}
return totalRead;
}
/// <summary>
/// Attempts to read the specified number of bytes from the stream. If
/// there are fewer bytes left before the end of the stream, a shorter
/// (possibly empty) array is returned.
/// </summary>
/// <param name="stream">Stream to read from.</param>
/// <param name="length">Number of bytes to read from the stream.</param>
public static byte[] Read(this Stream stream, int length)
{
byte[] buf = new byte[length];
int read = stream.FillBuffer(buf, 0, length);
if (read < length)
Array.Resize(ref buf, read);
return buf;
}
内存泄漏，因为您没有取消关联事件。
这甚至让我认识的一些高级开发人员被发现了。
想象一个WPF表单，里面有很多东西，你在其中的某个地方订阅了一个事件。如果您不取消订阅，那么关闭和取消引用后，整个表单将保留在内存中。
我相信我看到的问题是在WPF表单中创建一个DispatchTimer并订阅Tick事件，如果你不对计时器做-=，你的表单泄漏内存!
在本例中，您的拆卸代码应该具有
timer.Tick -= TimerTickEventHandler;
这一点特别棘手，因为您在WPF表单中创建了DispatchTimer实例，所以您会认为它是一个由垃圾收集进程处理的内部引用……不幸的是，DispatchTimer在UI线程上使用了一个静态的订阅和服务请求的内部列表，所以引用是由静态类“拥有”的。
如果你正在为MOSS编写代码，你以这种方式获得一个站点引用:
SPSite oSiteCollection = SPContext.Current.Site;
之后在你的代码中你说:
oSiteCollection.Dispose();
从MSDN:
If you create an SPSite object, you can use the Dispose method to close the object. However, if you have a reference to a shared resource, such as when the object is provided by the GetContextSite method or Site property (for example, SPContext.Current.Site), do not use the Dispose method to close the object, but instead allow Windows SharePoint Services or your portal application to manage the object. For more information about object disposal, see Best Practices: Using Disposable Windows SharePoint Services Objects.
每个MOSS程序员都会遇到这种情况。
LINQ to SQL和一对多关系
这是一个可爱的，咬了我几次，微软把它留给他们自己的开发人员放在她的博客。我不能说得比她更好，来看看。
我经常提醒自己DateTime是一个值类型，而不是引用类型。对我来说太奇怪了，特别是考虑到它的各种构造函数。
