8 Most common mistakes C# developers make

[CodeExplorer]

8 Most common mistakes C# developers make:
Link:
http://blog.goyello.com/2013/01/07/8-most-common-mistakes-c-developers-make/
 

[atom0s]

I think some of these are a bit bias and aim towards an opinion of readability vs. optimization.

For example with #1, using a string builder is slow and has a lot of overhead compared to just concat'ing onto a normal string. Using their example, both have a string list initialization and loop that take up the same amount of instructions. However then there is the calls to handling the string concat. 

In the "incorrect" method, System::String::Concat is called by the framework automatically using the += operator. This call makes a few sub-calls but overall is very light-weight and simple:
 - Calls IsNullOrEmpty on both parameters.
 - Obtains the length of both strings.
 - Allocates a new string of the proper size.
 - Fills the new string with the given data.

In the "correct" method, it calls the System::Text::StringBuilder::Append method which does a ton more work:
 - Builds out a chunk cache for the input string to append.
 - Determines the length multiple times to ensure copying is not going to overflow / overstep bounds.
 - Uses unsafe pointers to make a call to wstrcpy. (which calls memcpy -> memmove -> etc.)
 - Then depending on the string length, it can land up making a ton more calls / checks to eventually land up calling wstrcpy.

 

Point #2 is a matter of people not learning Linq properly and is somewhat of a valid point.

Point #3 is entirely based on the nature of the code and how the program is coded. Do you want null checks or do you want exceptions thrown? It's more or less application dependent and is not correct/incorrect.

Point #4 is a matter of opinion entirely. Not using a feature to automate something is not wrong. And is probably better to avoid so you learn what you are doing vs. having a tool generate things for you.

Point #5 is a valid point.

Point #6 is also a matter of how the code is being used. For example, if you nest usings, you have a condition where an object will not properly dispose (which will generate a compiler warning if you enable a higher warning level in the project properties). And as long as the user is disposing of the objects after use, it is not improper and again just a matter of opinion on readability. 

Point #7 the tests used to compare are a bit stale and lacking. Could use more data to get a real analysis of which can/will perform better, and it is also going to be situational based on the data being used.

Point #8 again is dependent on the application and how it is coded. In some cases single writes are needed to have safety checks and fail-safes. If one write fails, you would not want others to continue. As an example, if you are managing a database of user data where there are various tables for the users themselves, profile data, purchase history etc. you would not want to insert a new user where you would have to create a table entry in a varying number of tables and have the main insert fail to create the user but you still inserted all other data into other tables that now link to nothing. It is very situational on how things need to be written.

[mrexodia]

#1 The argument about the allocations is probably incorrect. If you don't reserve space in your StringBuilder it will also have to allocate memory. But in the long run it does matter (with millions of strings).

#2 Don't know where he got the ridiculous idea that returning the default if there is no value found is correct behavior. An exception is in my opinion desirable if you assume it will always return something. If you made a mistake in your Where you might never spot it because something is returned anyway.

#3 No idea about this one. I try to avoid casting if at all possible.

#6 Agree with this one.

#7 In my opinion you should always use foreach if possible. It makes your code so much more readable usually the performance difference doesn't matter much.

[simple]

If a language has a feature - it's there for a reason - and u can never say "never use this way". Each feature has a purpose for certain situations.

Besides, if this dude is such a bad@ss coder then why isn't he busy getting rich coding? Instead he's busy blogging? pfft... old saying - those who can't do - teach.

[Undebel]

http://blog.goyello.com/2013/01/30/6-more-things-c-developers-should-not-do/