8 Most common mistakes C# developers make

While working with (young) C# programmers I’ve noticed that some mistakes are being repeated by almost every one of them. These are mostly the mistakes, which once you point them, are quite easy to remember. However, if a developer is not aware of them, they can cause many problems with the efficiency and quality of the developed software. Therefore, I decided to gather the 8 most common mistakes made. ## 1. String concatenation instead of StringBuilder String concatenation works in such a way that every time when you add something to a string, a new address in the memory is being allocated. The previous string is copied to a new location with the newly added part. This is inefficient. On the other hand we have StringBuilder which keeps the same position in the memory without performing the copy operation. Thanks to the strings’ appending by means of StringBuilder the process is much more efficient, especially in case of hundreds of append operations. //INCORRECT List values = new List(){"This ","is ","Sparta ","!"}; string outputValue = string.Empty; foreach (var value in values) { outputValue += value; } //CORRECT StringBuilder outputValueBuilder = new StringBuilder(); foreach (var value in values) { outputValueBuilder.Append(value); } ## 2. LINQ – ‘Where’ with ‘First’ instead of FirstOrDefault A lot of programmers find a certain set of elements by means of ‘Where’ and then return the first occurrence. This is inappropriate, because the ‘First’ method can be also applied with the ‘Where’ condition. What’s more, it shouldn’t be taken for granted that the value will always be found. If “First” is used when no value is found, an exception will be thrown. Thus, it’s better to use FirstOrDefault instead. When using FirstOrDefault, if no value has been found, the default value for this type will be returned and no exception will be thrown. … //INCORRECT var woman = (Woman)person; //CORRECT var woman = person as Woman; ## 4. Not using mapping for rewriting properties There are a lot of ready and very powerful C# mappers (e.g. AutoMapper). If a few lines of code are simply connected with rewriting properties, it’s definitely a place for a mapper. Even if some properties aren’t directly copied but some additional logic is performed, using a mapper is still a good choice (mappers enable defining the rules of rewriting properties to a big extend). … ## 8. Retrieving or saving data to DB in more than 1 call This is a very common mistake, especially among junior developers and especially when using ORMs like Entity Framework or NHibernate. Every DB call consumes some amount of time and therefore it’s crucial to decrease the amount of DB calls as much as possible. There are many ways to do so: - Using fetching (Eager Loading) - Enclosing DB operations in transactions - In case of a really complex logic, just moving it to the DB by building a stored procedure **It goes without saying that there are hundreds of other types of mistakes made by C# programmers. If you know any interesting ones or you want to share your opinion about the subject, feel free to leave a comment below! ** … business models) is that 1) it’s a lot of writing, 2) it’s easy to ommit some property that you want to rewrite from one object to another. Generally it’s not necessarily a problem when you have only a few properties, but it might be when you have many of them. So let’s say you have an entity Person and a … I was going to go into detail about the problems with this article but previous posters have already pointed out all the problems I noticed. I just want to add that I feel like articles like this are dangerous. While points 5 and 6 are, in my opinion, absolutely best practices that should be followed in 99% of cases the rest of the items are dependent on what you are doing, how much data you are working with, and a host of other considerations. To tell a developer “always use for instead of foreach” will generate a bunch of developers who don’t understand why other than they read it on some blog. … This highlights the real core of the “sloppyness”. With the rush to market mindset there’s almost no considereration what a program (or method) really should do. Discussions bloated with oneliners and one sided remarks do not really contribute in highlighting the real problems. I’m talking about pre- and posconditions, and invariants. The real sloppyness can be found here.