Home > Article > Backend Development > 13 things you must know as a C# developer
13 things every C# developer must know
Program bugs and flaws often appear during the development process. Making good use of the tools can help you discover or avoid problems before you release your program.
Standardized code writing can make the code easier to maintain, especially when the code is developed and maintained by multiple developers or teams. This advantage is even more prominent. Common tools for forcing code standardization include: FxCop, StyleCop and ReSharper.
Developer's Note: Think carefully about errors before covering them up, and analyze the results. Don't expect to rely on these tools to find errors in your code, as the results may be far different from yours.
Code review and partner programming are common exercises in which developers intentionally review code written by others. Others are keen to find bugs on the part of code developers, such as coding errors or execution errors.
Reviewing code is a valuable exercise that is difficult to quantify and unsatisfactory in its accuracy due to its reliance on manual effort.
Static analysis does not require you to run the code. You do not need to write test cases to find out some irregularities in the code or the existence of defects. This is a very effective way of finding problems, but you need to have a tool that doesn't have too many false positives. Commonly used static analysis tools for C# include Coverity, CAT, NET, and Visual Studio Code Analysis.
Dynamic analysis tools can help you find these errors when you run your code: security vulnerabilities, performance and concurrency issues. This approach performs analysis in an execution-time context, and as such, its effectiveness is limited by code complexity. Visual Studio provides a large number of dynamic analysis tools including Concurrency Visualizer, IntelliTrace, and Profiling Tools.
Manager/Team Lead Quote: Development practices are the best way to practice avoiding common pitfalls. Also pay attention to whether the testing tool meets your needs. Try to keep your team's level of code diagnostics under control.
There are many ways to test: unit testing, system integration testing, performance testing, penetration testing, etc. During the development phase, most test cases are written by developers or testers so that the program can meet requirements.
Tests only work if they run the correct code. When conducting functional testing, it can also be used to challenge developers' development and maintenance speed.
Spend more time on tool selection, use the right tools to solve the problems you care about, and don't add extra work for developers. Let analysis tools and tests run automatically and smoothly to find problems, but make sure the idea of the code remains clearly in the developer's mind.
Locate the location of the diagnosed problem as quickly as possible (whether it is errors obtained through static analysis or testing, such as compilation warnings, standard violations, problem detection, etc.). If a new problem is ignored because you "don't care" and it becomes difficult to find later, it will add a lot of workload to the code review workers, and you have to pray that they will not be annoyed by it.
Please accept these useful suggestions to improve the quality, security, and maintainability of your code, while also improving developers' R&D capabilities, coordination capabilities, and the predictability of released code.
| Target | tool | Influence |
| Consistency, maintainability | Standardized code writing, static analysis, code review | Consistent spacing, naming standards, and good readable formats will make it easier for developers to write and maintain code. |
| Accuracy | Code review, static analysis, dynamic analysis, testing | The code not only needs to be grammatically correct, but also needs to meet the software requirements with the developer's thinking in mind. |
| Feature | test | Testing can verify that most requirements are met: correctness, scalability, robustness, and security. |
| safety | Standardized code writing, code review, static analysis, dynamic analysis, testing | Security is a complex issue, and any small vulnerability is a potential threat. |
| Developer R&D capabilities | Standardized code writing, static analysis, testing | Developers can correct errors very quickly with the help of tools. |
| Release predictability | Standardized code writing, code review, static analysis, dynamic analysis, testing | Streamlining late-stage activities and minimizing error location loops can allow problems to be discovered earlier. |
One of the main advantages of C# is its flexible type system, and safe types can help us find errors earlier. By enforcing strict type rules, the compiler can help you maintain good coding habits. In this regard, the C# language and the .NET framework provide us with a large number of types to meet most needs. Although many developers have a good understanding of general types and are aware of user needs, some misunderstandings and misuses still exist.
For more information about the .NTE framework class library, please refer to the MSDN library.
Specific interfaces involve common C# features. For example, IDiposable allows the use of common resource management language, such as the keyword "using". A good understanding of interfaces can help you write fluent C# code and make it easier to maintain.
Avoid using the ICloneable interface - developers never know whether a copied object is a deep copy or a shallow copy. Since there is still no standard way to judge whether the operation of copying objects is correct, there is no way to meaningfully use the interface as a contract.
Try to avoid writing to structures and treat them as immutable objects to prevent confusion. Memory sharing in scenarios like multi-threading will become safer. The approach we take with structures is to initialize the structure when it is created. If its data needs to be changed, it is recommended to generate a new entity.
Correctly understand which standard types/methods are immutable and can return new values (such as strings, dates), and use these to replace those mutable objects (such as List.Enumerator).
The value of the string may be empty, so some convenient functions can be used when appropriate. NullReferenceException errors may occur when value judgment (s.Length==0), while String.IsNullOrEmpty(s) and String.IsNullOrWhitespace(s) can work well with null.
Enumeration types and constants can make code easier to read, and by replacing magic numbers with identifiers, the meaning of the value can be expressed.
If you need to generate a large number of enum types, tagged enum types are a simpler option:
[Flag]
public enum Tag {
None =0x0,
Tip =0x1,
Example=0x2
}
The following method allows you to use multiple tags in a snippet:
snippet.Tag = Tag.Tip | Tag.Example
This method is conducive to data encapsulation, so you don't have to worry about leaking internal collection information when using the Tag property getter.
There are two types of equality:
1. Reference equality, that is, both references point to the same object.
2. Numerical equality, that is, two different reference objects can be considered equal.
In addition, C# also provides many equality testing methods. The most common methods are as follows:
== and != operations
Equivalent method of virtual inheritance by object
Static Object.Equal method
IEquatable
Static Object.ReferenceEquals method
Sometimes it's hard to figure out the purpose of using reference or value equality. To learn more about these and make your work better, please see:
MSDNhttp://msdn.microsoft.com/en-us/library/dd183752.aspx
If you want to overwrite something, don't forget the tools provided for us on MSDN such as IEquatable
Pay attention to the impact of untyped containers on overloading, and consider using the "myArrayList[0] == myString" method. Array elements are "objects" of compile-time types, so reference equality works. Although C# will alert you to these potential errors, unexpected reference equality will not be alerted in some cases during the compilation process.
Classes play a big role in properly managing data. For performance reasons, classes always cache partial results or make some assumptions about the consistency of internal data. Making data permissions public forces you to cache or make assumptions to a certain extent, and these operations manifest themselves through potential impacts on performance, security, and concurrency. For example, exposing mutable members such as generic collections and arrays allows users to skip you and modify the structure directly.
In addition to controlling objects through access modifiers, properties allow you to control very precisely how users interact with your objects. In particular, attributes can also let you know the specific conditions of reading and writing.
Properties can help you build a stable API when overriding data into getters and setters through storage logic, or provide a data binding resource.
Never throw exceptions in property getters, and avoid modifying object state. This is a requirement for methods, not getters for properties.
更多有关属性的信息，请参阅MSDN：
http://msdn.microsoft.com/en-us/library/ms229006(v=vs.120).aspx
同时也要注意getter的一些副作用。开发者也习惯于将成员体的存取视为一种常见的操作，因此他们在代码审查的时候也常常忽视那些副作用。
你可以为一个新创建的对象根据它创建的表达形式赋予属性。例如为Foo与Bar属性创建一个新的具有给定值的C类对象：
new C {Foo=blah, Bar=blam}
你也可以生成一个具有特定属性名称的匿名类型的实体：
var myAwesomeObject = new {Name=”Foo”, Size=10};
初始化过程在构造函数体之前运行，因此需要保证在输入至构造函数之前，将这一域给初始化。由于构造函数还没有运行，所以目标域的初始化可能不管怎样都不涉及“this”。
为了使一些特殊方法更加容易控制，最好在你使用的方法当中使用最少的特定类型。比如在一种方法中使用 List
public void Foo(Listbars) { foreach(var b in bars) { // do something with the bar... } }
对于其他IEnumerable
泛型是一种在定义独立类型结构体与设计算法上一种十分有力的工具，它可以强制类型变得安全。
用像List
在使用泛型时，我们可以用关键词“default”来为类型获取缺省值（这些缺省值不可以硬编码写进implementation）。特别要指出的是，数字类型的缺省值是o，引用类型与空类型的缺省值为null。
T t = default(T);
类型转换有两种模式。其一显式转换必须由开发者调用，另一隐式转换是基于环境下应用于编译器的。
常量o可由隐式转换至枚举型数据。当你尝试调用含有数字的方法时，可以将这些数据转换成枚举类型。
| 类型转换 | 描述 |
| Tree tree = (Tree)obj; | 这种方法可以在对象是树类型时使用；如果对象不是树，可能会出现InvalidCast异常。 |
| Tree tree = obj as Tree; | 这种方法你可以在预测对象是否为树时使用。如果对象不是树，那么会给树赋值null。你可以用“as”的转换，然后找到null值的返回处，再进行处理。由于它需要有条件处理的返回值，因此记住只在需要的时候才去用这种转换。这种额外的代码可能会造成一些bug，还可能会降低代码的可读性。 |
转换通常意味着以下两件事之一：
1.RuntimeType的表现可比编译器所表现出来的特殊的多，Cast转换命令编译器将这种表达视为一种更特殊的类型。如果你的设想不正确的话，那么编译器会向你输出一个异常。例如：将对象转换成串。
2.有一种完全不同的类型的值，与Expression的值有关。Cast命令编译器生成代码去与该值相关联，或者是在没有值的情况下报出一个异常。例如：将double类型转换成int类型。
以上两种类型的Cast都有着风险。第一种Cast向我们提出了一个问题：“为什么开发者能很清楚地知道问题，而编译器为什么不能？”如果你处于这个情况当中，你可以去尝试改变程序让编译器能够顺利地推理出正确的类型。如果你认为一个对象的runtime type是比compile time type还要特殊的类型，你就可以用“as”或者“is”操作。
第二种cast也提出了一个问题：“为什么不在第一步就对目标数据类型进行操作？”如果你需要int类型的结果，那么用int会比double更有意义一些。
获取额外的信息请参阅：
http://blogs.msdn.com/b/ericlippert/archive/tags/cast+operator/
在某些情况下显式转换是一种正确的选择，它可以提高代码可阅读性与debug能力，还可以在采用合适的操作的情况下提高测试能力。
异常不应该常出现在程序流程中。它们代表着开发者所不愿看到的运行环境，而这些很可能无法修复。如果你期望得到一个可控制的环境，那么主动去检查环境会比等待问题的出现要好得多。
利用TryParse()方法可以很方便地将格式化的串转换成数字。不论是否解析成功，它都会返回一个布尔型结果，这要比单纯返回异常要好很多。
写代码时注意catch与finally块的使用。由于这些不希望得到的异常，控制可能进入这些块中。那些你期望的已执行的代码可能会由于异常而跳过。如：
Frobber originalFrobber = null;
try {
originalFrobber = this.GetCurrentFrobber();
this.UseTemporaryFrobber();
this.frobSomeBlobs();
}
finally {
this.ResetFrobber(originalFrobber);
}
如果GetCurrentFrobber()报出了一个异常，那么当finally blocks被执行时originalFrobber的值仍然为空。如果GetCurrentFrobber不能被扔掉，那么为什么其内部是一个try block？
要注意有针对性地处理你的目标异常，并且只去处理目标代码当中的异常部分。尽量不要去处理所有异常，或者是根类异常，除非你的目的是记录并重新处理这些异常。某些异常会使应用处于一种接近崩溃的状态，但这也比无法修复要好得多。有些试图修复代码的操作可能会误使情况变得更糟糕。
关于致命的异常都有一些细微的差异，特别是注重finally blocks的执行，可以影响到异常的安全与调试。更多信息请参阅：
http://incrediblejourneysintotheknown.blogspot.com/2009/02/fatal-exceptions-and-why-vbnet-has.html
使用一款顶级的异常处理器去安全地处理异常情况，并且会将debug的一些问题信息暴露出来。使用catch块会比较安全地定位那些特殊的情况，从而安全地解决这些问题，再将一些问题留给顶级的异常处理器去解决。
如果你发现了一个异常，请做些什么去解决它，而不要去将这个问题搁置。搁置只会使问题更加复杂，更难以解决。
将异常包含至一个自定义异常中，对面向公共API的代码特别有用。异常是可视界面方法的一部分，它也被参数与返回值所控制。但这种扩散了很多异常的方法对于代码的鲁棒性与可维护性的解决来说十分麻烦。
如果你希望在更高层次上解决caught异常，那么就维持原异常状态，并且栈就是一个很好的debug方法。但需要注意维持好debug与安全考虑的平衡。
好的选择包括简单地将异常继续抛出：
Throw；
或者将异常视为内部异常重新抛出：
抛出一个新CustomException；
不要显式重新抛出类似于这样的caught异常：
Throw e；
这样的话会将异常的处理恢复至初始状态，并且阻碍debug。
有些异常发生于你代码的运行环境之外。与其使用caught块，你可能更需要向目标当中添加如ThreadException或UnhandledException之类的处理器。例如，Windows窗体异常并不是出现于窗体处理线程环境当中的。
千万不要让异常影响到你数据模型的完整性。你需要保证你的对象处于比较稳定的状态当中——这样一来任何由类的执行的操作都不会出现违例。否则，通过“恢复”这一手段会使你的代码变得更加让人不解，也容易造成进一步的损坏。
考虑几种修改私有域顺序的方法。如果在修改顺序的过程当中出现了异常，那么你的对象可能并不处于非法状态下。尝试在实际更新域之前去得到新的值，这样你就可以在异常安全管理下，正常地更新你的域。
对特定类型的值——包括布尔型，32bit或者更小的数据类型与引用型——进行可变量的分配，确保可以是原子型。没有什么保障是给一些大型数据（double，long，decimal）使用的。可以多考虑这个：在共享多线程的变量时，多使用lock statements。
事件与委托共同提供了一种关于类的方法，这种方法在有特殊的事情发生时向用户进行提醒。委托事件的值在事件发生时应被调用。事件就像是委托类型的域，当对象生成时，其自动初始化为null。
事件也像值为“组播”的域。这也就是说，一种委托可以依次调用其他委托。你可以将一个委托分配给一个事件，你也可以通过类似-=于+=这样的操作来控制事件。
如果一个事件被多个线程所共享，另一个线程就有可能在你检查是否为null之后，在调用其之前而清除所有的用户信息——并抛出一个NullReferenceException。
对于此类问题的标准解决方法是创建一个该事件的副本，用于测试与调用。你仍然需要注意的是，如果委托没有被正确调用的话，那么在其他线程里被移除的用户仍然可以继续操作。你也可以用某种方法将操作按顺序锁定，以避免一些问题。
public event EventHandler SomethingHappened;
private void OnSomethingHappened()
{
// The event is null until somebody hooks up to it
// Create our own copy of the event to protect against another thread removing our subscribers
EventHandler handler = SomethingHappened;
if (handler != null)
handler(this,new EventArgs());
}
更多关于事件与竞争的信息请参阅：
http://blogs.msdn.com/b/ericlippert/archive/2009/04/29/events-and-races.aspx
使用一种事件处理器为事件资源生成一个由处理器的资源对象到接收对象的引用，可以保护接收端的garbage collection。
适当的unhook处理器可以确保你不必因委托不再工作而去调用它浪费时间，也不会使内存存储无用委托与不可引用的对象。
属性提供了一种向程序集、类与其信息属性中注入元数据的方法。它们经常用来提供信息给代码的消费者——比如debugger、框架测试、应用——通过反射这一方式。你也可以向你的用户定义属性，或是使用预定义属性，详见下表：
| 属性 | 使用对象 | 目的 |
| DebuggerDisplay | Debugger | Debugger display 格式 |
| InternalsVisibleTo | Member access | 使用特定类来暴露内部成员去指定其他的类。基于此方法，测试方法可以用来保护成员，并且persistence层可以用一些特殊的隐蔽方法。 |
| DefaultValue | Properties | 为属性指定一个缺省值 |
一定要对DebuggerStepThrough多重视几分——否则它会在这个方法应用的地方让寻找bug变得十分困难，你也会因此而跳过某步或是推倒而重做它。
Debug是在开发过程中必不可少的部分。除了使运行环境不透明的部分变得可视化之外，debugger也可以侵入运行环境，并且如果不使用debugger的话会导致应用程序变现有所不同。
为了观察当前框架异常状态，你可以将“$exception”这一表达添加进Visual Studio Watch窗口。这种变量包含了当前异常状态，类似于你在catch block中所看见的，但其中不包含在debugger中看见的不是代码中的真正存在的异常。
如果你的属性有副作用，那么考虑你是否应使用特性或者是debugger设置去避免debugger自动地调用getter。例如，你的类可能有这样一个属性：
private int remainingAccesses = 10;
private string meteredData;
public string MeteredData
{
get
{
if (remainingAccesses-- > 0)
return meteredData;
return null;
}
}
你第一次在debugger中看见这个对象时，remainingAccesses会获得一个值为10的整型变量，并且MeteredData为null。然而如果你hover结束了remainingAccesses，你会发现它的值会变成9.这样一来debugger的属性值表现改变了你的对象的状态。
早做计划，不断监测，后做优化
在设计阶段，制定切实可行的目标。在开发阶段，专注于代码的正确性要比去做微调整有意义的多。对于你的目标，你要在开发过程中多进行监测。只需要在你没有达到预期的目标的时候，你才应该去花时间对程序做一个调整。
请记住用合适的工具来确保性能的经验性测量，并且使测试处于这样一种环境当中：可反复多次测试，并且测试过程尽量与现实当中用户的使用习惯一致。
当你对性能进行测试的时候，一定要注意你真正所关心的测试目标是什么。在进行某一项功能的测试时，你的测试有没有包含这项功能的调用或者是回路构造的开销？
我们都听说过很多比别人做得快很多的项目神话，不要盲目相信这些，试验与测试才是实在的东西。
由于CLR优化的原因，有时候看起来效率不高的代码可能会比看起来效率高的代码运行的更快。例如，CLR优化循环覆盖了一个完整的数组，以避免在不可见的per-element范围里的检查。开发者经常在循环一个数组之前先计算一下它的长度：
int[] a_val = int[4000]; int len = a_val.Length; for (int i = 0; i < len; i++) a_val[i] = i;
通过将长度存储进一个变量当中，CLR会不去识别这一部分，并且跳过优化。但是有时手动优化会反人类地导致更糟糕的性能表现。
如果你打算将大量的字符串进行连接，可以使用System.Text.StringBuilder来避免生成大量的临时字符串。
如果你打算生成并填满集合中已知的大量数据，由于再分配的存在，可以用保留空间来解决生成集合的性能与资源问题。你可以用AddRange方法来进一步对性能进行优化，如下在List
Persons.AddRange(listBox.Items);
垃圾收集器（garbage collector）可以自动地清理内存。即使这样，一切被抛弃的资源也需要适当的处理——特别是那些垃圾收集器不能管理的资源。
| 资源管理问题的常见来源 | |
| 内存碎片 | 如果没有足够大的连续的虚拟地址存储空间，可能会导致分配失败 |
| 进程限制 | 进程通常都可以读取内存的所有子集，以及系统可用的资源。 |
| 资源泄露 | 垃圾收集器只管理内存，其他资源需要由应用程序正确管理。 |
| 不稳定资源 | 那些依赖于垃圾收集器与终结器（finalizers）的资源在很久没用过的时候，不可被立即调用。实际上它们可能永远不可能被调用。 |
利用try/finally block来确保资源已被合理释放，或是让你的类使用IDisposable，以及更方便更安全的声明方式。
using (StreamReader reader=new StreamReader(file))
{
//your code here
除了用调用GC.Collect()干扰garbage collector之外，也可以考虑适当地释放或是抛弃资源。在进行性能测试时，如果你可以承担这种影响带来的后果，你再去使用garbage collector。
与当前一些流传的谣言不同的是，你的类不需要Finalizers，而这只是因为IDisposable的存在！你可以让IDisposable赋予你的类在任何已拥有的组合实例中调用Dispose的能力，但是finalizers只能在拥有未管理的资源类中使用。
Finalizers主要对交互式Win32位句柄API有很大作用，并且SafeHandle句柄是很容易利用的。
不要总是设想你的finalizers（总是在finalizer线程上运行的）会很好地与其他对象进行交互。那些其他的对象可能在该进程之前就被终止掉了。
处理并发性与多线程编程是件复杂的、困难的事情。在将并发性添加进你的程序之前，请确保你已经明确了解你的做的是什么——因为这里面有太多门道了！
多线程软件的情况很难进行预测，比如很容易产生如竞争条件与死锁的问题，而这些问题并不是仅仅影响单线程应用。基于这些风险，你应该将多线程视为最后一种手段。如果不得不使用多线程，尽量缩减多线程同时使用内存的需求。如果必须使线程同步，请尽可能地使用最高等级的同步机制。在最高等级的前提下，包括了这些机制：
Async-await/Task Parallel Library/Lazy
Lock/monitor/AutoResetEvent
Interlocked/Semaphore
可变域与显式barrier
以上的这些很难解释清楚C#/.NET的复杂之处。如果你想开发一个正常的并发应用，可以去参阅O’Reilly的《Concurrency in C# Cookboo》。
将一个域标记为“volatile”是一种高级特性，而这种设置也经常被专家所误解。C#的编译器会保证目标域可以被获取与释放语义，但是被lock的域就不适用于这种情况。如果你不知道获取什么，不知道释放什么语义，以及它们是怎样影响CPU层次的优化，那么久避免使用volatile域。取而代之的可以用更高层次的工具，比如Task Parallel Library或是CancellationToken。
标准库类型常提供使对象线程安全更容易的方法。例如Dictionary.TryGetValue()。使用此类方法一般可以使你的代码变得更加清爽，并且你也不必担心像TOCTOU（time-of-check-time-of-use竞争危害的一种）这样的数据竞争。
不要锁住“this”、字符串，或是其他普通public的对象
当使用在多线程环境下的一些类时，多注意lock的使用。锁住字符串常量，或是其他公共对象，会阻止你锁状态下的封装，还可能会导致死锁。你需要阻止其他代码锁定在同一使用的对象上，当然你最好的选择是使用private对象成员项。
滥用null是一种常见的导致程序错误的来源，这种非正常操作可能会使程序崩溃或是其他的异常。如果你试图获取一个null的引用，就好像它是某对象的有效引用值（例如通过获取一个属性或是方法），那么在运行时就会抛出一个NullReferenceException。
静态与动态分析工具可以在你发布代码之前为你检查出潜在的NullReferenceException。在C#当中，引用型为null通常是由于变量没有引用到某个对象而造成的。对于值可为空的类型与引用型来说，是可以使用null的。例如：Nullable
每个null引用异常都是一个bug。相比于找到NullReferenceException这个问题来说，不如尝试在你使用该对象之前去为null进行测试。这样一来可以使代码更易于最小化的try/catch block读取。
当从数据库表中读取数据时，注意缺失值可以表示为DBNull 对象，而不是作为空引用。不要期望它们表现得像潜在的空引用一样。
Float与double都可以表示十进制实数，但不能表示二进制实数，并且在存储十进制值的时候可以在必要时用二进制的近似值存储。从十进制的角度来看，这些二进制的近似值通常都有不同的精度与取舍，有时在算数操作当中会导致一些不期望的结果。由于浮点型运算通常在硬件当中执行，因此硬件条件的不可预测会使这些差异更加复杂。
在十进制精度很重要的时候，就要使用十进制了——比如经济方面的计算。
有一种常见的错误就是忘记了结构是值类型，意即其复制与通过值传递。例如你可能见过这样的代码：
struct P { public int x; public int y; }
void M()
{
P p = whatever;
…
p.x = something;
…
N(p);
忽然某一天，代码维护人员决定将代码重构成这样：
void M()
{
P p = whatever;
Helper(p);
N(p);
}
void Helper(P p)
{
…
p.x = something;
现在当N(p)在M()中被调用，p就有了一个错误的值。调用Helper(p)传递p的副本，并不是引用p，于是在Helper()中的突变便丢失掉了。如果被正常调用，那么Helper应该传递的是调整过的p的副本。
C#编译器可以保护在运算过程中的常量溢出，但不一定是计算值。使用“checked”与“unchecked”两个关键词来标记你想对变量进行什么操作。
与结构体不同的是，类是引用类型，并且可以适当地修改引用对象。然而并不是所有的对象方法都可以实际修改引用对象，有一些返回的是一个新的对象。当开发者调用后者时，他们需要记住将返回值分配给一个变量，这样才可以使用修改过的对象。在代码审查阶段，这些问题的类型通常会逃过审查而不被发现。像字符串之类的对象，它们是不可变的，因此永远不可能修改这些对象。即便如此，开发者还是很容易忘记这些问题。
例如，看如下 string.Replace()代码：
string label = “My name is Aloysius”; label.Replace(“Aloysius”, “secret”);
这两行代码运行之后会打印出“My name is Aloysius” ，这是因为Raeplace方法并没改变该字符串的值。
注意不要在遍历时去修改集合
ListmyItems = new List {20,25,9,14,50}; foreach(int item in myItems) { if (item < 10) { myItems.Remove(item); // iterator is now invalid! // you’ll get an exception on the next iteration
如果你运行了这个代码，那么它一在下一项的集合中进行循环，你就会得到一个异常。
正确的处理方法是使用第二个list去保存你想删除的这一项，然后在你想删除的时候再遍历这个list：
ListmyItems = new List {20,25,9,14,50}; List toRemove = new List (); foreach(int item in myItems) { if (item < 10) { toRemove.Add(item); } } foreach(int item in toRemove) {
如果你用的是C#3.0或更高版本，可以尝试List
myInts.RemoveAll(item => (item < 10));
在实现属性时，要注意属性的名称和在类当中用的成员项的名字有很大差别。很容易在不知情的情况下使用了相同的名称，并且在属性被获取的时候还会触发死循环。
// The following code will trigger infinite recursion
private string name;
public string Name
{
get
{
return Name; // should reference “name” instead.
在重命名间接属性时同样要小心。例如:在WPF中绑定的数据将属性名称指定为字符串。有时无意的改变属性名称，可能会不小心造成编译器无法解决的问题。
英文原文：13 Things Every C# Developer Should Know 翻译：码农网
The above is the detailed content of 13 things you must know as a C# developer. For more information, please follow other related articles on the PHP Chinese website!