The 10 Most Common Mistakes in C# Programming

# Buggy C# Code: The 10 Most Common Mistakes in C# Programming C# is a powerful and flexible language with many mechanisms and paradigms that can greatly improve productivity. Having a limited understanding or appreciation of its capabilities, though, can leave one in the proverbial state of “knowing enough to be dangerous”. This article describes 10 of the most common programming mistakes made, or pitfalls to be avoided, by C# programmers. … ## Common C# Programming Mistake #1: Using a reference like a value or vice versa Programmers of C++, and many other languages, are accustomed to being in control of whether the values they assign to variables are simply values or are references to existing objects. In C Sharp programming, however, that decision is made by the programmer who wrote the object, not by the programmer who instantiates the object and assigns it to a variable. This is a common “gotcha” for those trying to learn C# programming. … ## Common C# Programming Mistake #4: Using iterative (instead of declarative) statements to manipulate collections In C# 3.0, the addition of Language-Integrated Query (LINQ) to the language changed forever the way collections are queried and manipulated. Since then, if you’re using iterative statements to manipulate collections, you didn’t use LINQ when you probably should have. Some C# programmers don’t even know of LINQ’s existence, but fortunately that number is becoming increasingly small. Many still think, though, that because of the similarity between LINQ keywords and SQL statements, its only use is in code that queries databases. … While this is a pretty simple example of how to avoid this common C# programming problem, there are cases where a single LINQ statement can easily replace dozens of statements in an iterative loop (or nested loops) in your code. And less code general means less opportunities for bugs to be introduced. Keep in mind, however, there may be a trade-off in terms of performance. ... ## Common C# Programming Mistake #5: Failing to consider the underlying objects in a LINQ statement LINQ is great for abstracting the task of manipulating collections, whether they are in-memory objects, database tables, or XML documents. In a perfect world, you wouldn’t need to know what the underlying objects are. But the error here is assuming we live in a perfect world. In fact, identical LINQ statements can return different results when executed on the exact same data, if that data happens to be in a different format. … While there certainly are advantages to using extension methods, they can cause problems and a cry for C# programming help for those developers who aren’t aware of them or don’t properly understand them. This is especially true when looking at code samples online, or at any other pre-written code. When such code produces compiler errors (because it invokes methods that clearly aren’t defined on the classes they’re invoked on), the tendency is to think the code applies to a different version of the library, or to a different library altogether. A lot of time can be spent searching for a new version, or phantom “missing library”, that doesn’t exist. … Another common C# problem is to write your own collection object. That isn’t to say it’s never appropriate, but with as comprehensive a selection as the one .NET offers, you can probably save a lot of time by using or extending one that already exists, rather than reinventing the wheel. In particular, the C5 Generic Collection Library for C# and CLI offers a wide array of additional collections “out of the box”, such as persistent tree data structures, heap based priority queues, hash indexed array lists, linked lists, and much more. … ## Common C# Programming Mistake #10: Allowing compiler warnings to accumulate While this problem is definitely not C# specific, it is particularly egregious in C# programming since it abandons the benefits of the strict type checking offered by the C# compiler. Warnings are generated for a reason. While all C# compiler errors signify a defect in your code, many warnings do as well. What differentiates the two is that, in the case of a warning, the compiler has no problem emitting the instructions your code represents. Even so, it finds your code a little bit fishy, and there is a reasonable likelihood that your code doesn’t accurately reflect your intent. … Furthermore, coders take advantage of a Visual Studio feature which makes it easy for them to hide the warnings in the “Error List” window so they can focus only on the errors. It doesn’t take long until there are dozens of warnings, all of them blissfully ignored (or even worse, hidden). But if you ignore this type of warning, sooner or later, something like this may very well find its way into your code: