.Net开发人员必须避免的5个常见的编程错误 £神魔★判官ぃ 2021-11-19 13:54 211阅读 0赞 来源:http://www.amazedsaint.com/2010/02/top-5-common-programming-mistakes-net.html Some time back, I asked a question in Stackoverflow.com, about common programming mistakes .NET developers must avoid. The response was awesome, to say the least. I’m just listing down the top 5 developer crimes I picked, from the answers I received (regardless the votes). ### 1. Breaking the stack unnecessarily when you re-throw an exception ### This a pretty ‘old thing’ - but surprisingly, still a very common mistake. As [TheSoftwareJedi][] mentioned, you don’t really need to break the stack while throwing exceptions. I’ve done this myself when I was a beginner - and I’ve seen this more often than anything else when I do code reviews these days. To clarify the point - What is the difference between *try \{ ..\} catch (Exception ex) \{ throw ex; \}* and *try \{..\} catch(Exception ex) \{ throw; \}* ? [![image][]][image 1] And when you lose the stack trace, you can’t debug your app – and even worse, you can’t log your error details properly to your error log. The MSDN guidelines on exception handling clearly states > Do not rethrow by throwing the same exception object. This causes the stack trace for the original exception to be lost--use a lone "throw;" statement (without an object following it) to "rethrow" a catch exception. ### 2. Not using *using* to dispose objects ### When ever you initialize an IDisposable object, it is a good practice to initiate it in a using statement to ensure the object is getting disposed properly, like this. [![image][image 2]][image_image 2] Most developers won’t do that. [Greg Dean][] pointed the same. [![image][image 3]][image_image 3] Here is a little bit of re-cap from MSDN > As a rule, when you use an IDisposable object, you should declare and instantiate it in a using statement. The using statement calls the [Dispose][] method on the object in the correct way, and it also causes the object itself to go out of scope as soon as [Dispose][] is called. Within the usingblock, the object is read-only and cannot be modified or reassigned. > > The using statement ensures that [Dispose][] is called even if an exception occurs while you are calling methods on the object. You can achieve the same result by putting the object inside a try block and then calling [Dispose][] in a finally block; in fact, this is how the using statement is translated by the compiler. Also, do you know that a using statement is expanded by the compiler to a try\{..\} finally\{..\} block at compile time? Read more tips about [using statement][] in MSDN. ### 3. Not unhooking event handlers appropriately after wiring them. ### I think [Scott Langham][] brought up a great point about not unhooking event handlers. People don’t really ‘remember’ to unhook events. [![image][image 4]][image_image 4] In C\#, when you register an event handler, you are creating a strong reference from the event source to the listener. So, the listener won’t get garbage collected even if you don’t have any pointers to the listener - unless you unhook the event by yourself, and this might even result in a memory leak. So, if you are thinking about how to deal with situations where your Source is having a longer life span than the listener – there are multiple ways to deal with it, and Daniel Grunwald covers them nicely in [this excellent Codeproject Post.][] ### 4. Forgetting that Strings are immutable ### In .NET, we know that strings are immutable – which means, once a string is created, its value can’t be changed. All string operations you perform, actually returns a new string containing the modification. [John Sonmez][] have a nice point with an example. [![image][image 5]][image_image 5] ### 5. Not Overriding GetHashCode when overriding Equals method in C\# ### Why this is important? If Hashcode of two items does not match, they’ll be never considered equal, and the Equals method will never be called to execute your custom comparison logic – let us say, in scenarios where your objects are used as a key in a dictionary or so. Hence, in first place, you should override GetHashCode and return the same value for two equal objects based on comparison logic. I’ve seen this a couple of times during code review. So, though [Mark Gravell][] has several interesting points in his answer, my pick is about not overriding GetHashCode when you override Equals method in C\#. [![image][image 6]][image_image 6] You may read my other [Back To Basics][] posts here, you may find them interesting. Note: As mentioned, these are my favorite picks of common problems, with some custom commentary. I suggest you to go through [the entire thread here in Stack Overflow][] if you are interested. Happy coding!! 转载于:https://www.cnblogs.com/net205/archive/2011/09/15/2176834.html [TheSoftwareJedi]: http://stackoverflow.com/users/18941/thesoftwarejedi [image]: http://lh5.ggpht.com/__Mw4iY-4nuY/S28cZwaOcMI/AAAAAAAAAmA/wQYZuVrYeo4/image_thumb%5B3%5D.png?imgmax=800 [image 1]: http://lh5.ggpht.com/__Mw4iY-4nuY/S28cYvY_CcI/AAAAAAAAAl8/6eIkBnMIKWI/s1600-h/image%5B5%5D.png [image 2]: http://lh6.ggpht.com/__Mw4iY-4nuY/S28ccveoQjI/AAAAAAAAAmI/PD7UrT6Ldq0/image_thumb%5B12%5D.png?imgmax=800 [image_image 2]: http://lh5.ggpht.com/__Mw4iY-4nuY/S28cbRLwMKI/AAAAAAAAAmE/-I76qmCq9UM/s1600-h/image%5B20%5D.png [Greg Dean]: http://stackoverflow.com/users/4430/greg-dean [image 3]: http://lh6.ggpht.com/__Mw4iY-4nuY/S28cfs4ImLI/AAAAAAAAAmQ/H6aufMBhRzg/image_thumb%5B6%5D.png?imgmax=800 [image_image 3]: http://lh5.ggpht.com/__Mw4iY-4nuY/S28cdgVLCyI/AAAAAAAAAmM/v6QtjRCUrCI/s1600-h/image%5B10%5D.png [Dispose]: http://msdn.microsoft.com/en-us/library/system.idisposable.dispose.aspx [using statement]: http://msdn.microsoft.com/en-us/library/yh598w02.aspx [Scott Langham]: http://stackoverflow.com/users/11898/scott-langham [image 4]: http://lh3.ggpht.com/__Mw4iY-4nuY/S28ciFoXu6I/AAAAAAAAAmY/rs8RrloxOCQ/image_thumb%5B9%5D.png?imgmax=800 [image_image 4]: http://lh5.ggpht.com/__Mw4iY-4nuY/S28cg5nuO4I/AAAAAAAAAmU/HX3tuThnw2A/s1600-h/image%5B15%5D.png [this excellent Codeproject Post.]: http://www.codeproject.com/KB/cs/WeakEvents.aspx [John Sonmez]: http://stackoverflow.com/users/45365/john-sonmez [image 5]: http://lh6.ggpht.com/__Mw4iY-4nuY/S28clSQRIDI/AAAAAAAAAmg/plWTtciuk4M/image_thumb%5B15%5D.png?imgmax=800 [image_image 5]: http://lh6.ggpht.com/__Mw4iY-4nuY/S28cjb25zbI/AAAAAAAAAmc/c1mdjoCHxt0/s1600-h/image%5B25%5D.png [Mark Gravell]: http://stackoverflow.com/users/23354/marc-gravell [image 6]: http://lh6.ggpht.com/__Mw4iY-4nuY/S28coEp6IeI/AAAAAAAAAmo/IrLlYiln5Ak/image_thumb%5B18%5D.png?imgmax=800 [image_image 6]: http://lh4.ggpht.com/__Mw4iY-4nuY/S28cmZFDrXI/AAAAAAAAAmk/tS2Zi5OCaC8/s1600-h/image%5B30%5D.png [Back To Basics]: http://amazedsaint.blogspot.com/search/label/Back%20To%20Basics [the entire thread here in Stack Overflow]: http://stackoverflow.com/questions/380819/common-programming-mistakes-for-net-developers-to-avoid
相关 每个 TypeScript 开发者都应该避免的 5 个错误 如何编写干净、高级的 TypeScript 代码并避免初级开发人员在 TypeScript 中犯错误?因此,在这篇特别的文章中,我将介绍每个 TypeScript 开发人员都会 傷城~/ 2024年03月16日 13:34/ 0 赞/ 47 阅读
相关 每个开发人员都必须了解的 5 个 Java 测试框架和工具 前言 在发布软件之前进行测试对于软件开发生命周期至关重要。在最终版本发布之前发现各种缺陷并修复它们可以为组织节省大量成本。尽管端到端测试的整个过程可能有点乏味,但测试框架 朱雀/ 2024年02月17日 11:55/ 0 赞/ 11 阅读
相关 每个开发人员都必须拥有的 5 个改变游戏规则的网站 每个开发人员都必须拥有的五个网站 这些是必不可少的工具,它们将使您的工作更轻松、更快、质量更高的 CSS 1.魔术图案 使用 MagicPattern 创建专业视觉效果 刺骨的言语ヽ痛彻心扉/ 2023年09月27日 18:12/ 0 赞/ 140 阅读
相关 90%的Java开发人员都会犯的5个错误 前言 作为一名java开发程序员,不知道大家有没有遇到过一些匪夷所思的bug。这些错误通常需要您几个小时才能解决。当你找到它们的时候,你可能会默默地骂自己是个傻瓜。是的, 灰太狼/ 2023年09月23日 20:31/ 0 赞/ 12 阅读
相关 Java开发人员必须掌握的166个Linux命令 前言 > linux命令是对Linux系统进行管理的命令。对于Linux系统来说,无论是中央处理器、内存、磁盘驱动器、键盘、鼠标,还是用户等都是文件,Linux系统管理的 谁践踏了优雅/ 2023年01月02日 15:26/ 0 赞/ 317 阅读
相关 5个需要避免的DevOps错误 目录 定义DevOps 错误1:跨人,跨流程或跨技术思考 错误2:只面向开发或运维 错误3:错过部署策略 错误4:只关注节省成本 错误5:没有开始 DevOps的 我就是我/ 2022年10月14日 10:47/ 0 赞/ 125 阅读
相关 前端开发人员必须避免的十个坏习惯 前端开发人员必须避免的十个坏习惯 一、没有足够的休息时间 二、拒绝寻求帮助 三、弱化的求知欲 四、不规范的代码 五、无法平衡生活与工作 Myth丶恋晨/ 2022年09月12日 09:49/ 0 赞/ 219 阅读
相关 .Net开发人员必须避免的5个常见的编程错误 来源:http://www.amazedsaint.com/2010/02/top-5-common-programming-mistakes-net.html Some t £神魔★判官ぃ/ 2021年11月19日 13:54/ 0 赞/ 212 阅读
相关 mysql升级5.7后常见的几个错误,必须手动修复!!! 错误一:ERROR 1146 (42S02): Table 'performance\_schema.session\_variables' doesn't exist ゝ一纸荒年。/ 2021年08月27日 23:53/ 0 赞/ 577 阅读
还没有评论,来说两句吧...