Top 10 C# Best Practices (plus bonuses)

Learn what I believe are the top 10 best practices for C# developers. When you are programming in Visual Studio, I think these will help you do so better, more efficiently, and with less bugs. Once you see all 10 (plus the bonuses at the end), let me know what you think in the comments. Did I miss one? Do you disagree with one?

Thanks to Ralfs K and Julio M, here is a list of the best practices along with their video times:
0:00 - Intro
0:50 - Name things well
7:51 - One class per file
10:18 - Use properties not variables
12:57 - Methods should do one thing
23:27 - Keep it simple
28:21 - Be consistent
32:22 - Use curly braces for if statements
37:45 - Concatenate strings using $""
45:37 - Avoid global variables
48:39 - Use public modifier only when necessary
50:54 - Never trust the user (bonus)
52:24 - Plan before you build
55:31 - Concluding remarks

[pwings]

0:51 Name things well
7:51 One class per file
10:18 Use properties not variables
12:58 Methods should do one thing
23:27 Keep it simple
28:21 Be consistent
32:25 Use curly braces for if statements
37:45 Concatenate strings using $""
45:38 Avoid global variables
48:40 Use public modifier only when necessary

50:53 Never trust the user
52:28 Plan before you build

[jonathansaindon]

Another best practice: Optimize only if performance suffers. It's so easy to get carried away in useless optimizations.

[lautarolavecchia]

I like how you divide the whole video with timestamps it makes the learning process easier and to the point, thank you

[smartdatalearning]

Whenever I see name Tim Corey I know that I can expect high quality material delivered in a well thought explanation style.
On a side note I also wanted to mention that fonts look crisp and well focused when he is showing his computer screens. As I am also recording lectures I know that this is sometimes difficult to achieve and takes a lot of time and experimentation with different recording tools, parameters and video cards. So I appreciate that this author is spending time and taking efforts to make his videos enjoyable for viewers in all aspects.

[eTzTheGamer]

Holy crap, this video is almost 6 years old, and you're still actively replying to comments!
Thank you for all your super informational videos, and your interactivity helping people :)

[kermy]

I've seen alot of videos and tutorials about C# - But this is without doubt the best and most useful one yet. Now i will start watching all your C# Lessons :D

[vinipickrodt]

Great tips Tim!
I would like to add just two..
1. When doing high performance code to use local variables instead of properties inside the loop.
2. When dealing with serialization using the properly Stream handler. Like StreamReader, XmlReader etc.

[bkramber]

I applyed the forth practice (metod shoud do only one thing) to my latest programm. The programm was simple and I thought that I can't do it in this way. But then I start, I found:
1. This refactoring is not so simple, as I thought
2. My programm reads and debugs much, much better
3. I used same pieces of code more than one time before refactoring
Thank you! It was really useful!

[reidwilliams]

Just to share a little anecdotal fuel to two of your best practices.

1. in the late 1980's or early 90's I took a programming course using Borland C. This was back when DOS was still king and the big debate was whether Borland or Microsoft would be king of the C development world. Anyway, upon turning in my very first program the professor ran it and when it ask for the first user input he just started hitting any and every key on the keyboard. The program crashed and locked up the computer. He re-ran my program and used the proper user input and the program worked perfectly. I only got an 85 rather than a 100 for a perfect program because I failed to expect the unexpected (I trusted the user). I have never and will never do so again!

2. Back in 2012 I began a program for a Steel Fabricator which calculated a lot of dimensions and points for laying out and cutting several different steel shapes. I was really intrigued and excited to get started and so that is just what I did. Because I was very familiar with this and knew how to do these things very well, I jumped right in and started writing code without much if any planning. Almost 1500 lines of code later I realized that I would have to start over from scratch because I failed to anticipate quiet a large number of possibilities that could and did occur. Fortunately I was able to use some of the code I had already written. Never Again!

As I have heard so many times in the past "If you fail to plan, you are planning to Fail". I believe this is true even of small hobby projects because I have had so many of those projects turn into something much larger. Also, as you said and I learned the hard way "Never Ever Trust The User". If there is any way your program can be broken, some user will find that way and break it!

Thanks for the video.

[evaikuun]

I love this! It helps translate Robert Martin's book, Clean Code, from Java into C#. Thank you for this.
It is incredible to find how many senior developers agree on (and abide by) the same basic concepts throughout their own code!

[codingwithgyver]

One of the best mentors especially when implementing clean codes.

I have one another tips here same as in your tip#1(Name things well)

Never use a variable/method naming that has "double negation", I found it useful from another channel who is ex-Google developer
ex1: var isEvenNumber=true;
ex2: var isNotEvenNumber=false;

both of them have same definition and purpose, to identify if the number is even.

In ex1, you dont need to evaluate the actual purpose of it, its direct to the point, when it says false, then its an ODD numbers or when true, its EVEN,
while in ex2, your minsdet will be like this. Although you read it, you must evaluate the actual purpose, when it says TRUE on first stage of evaluation, followed by negating the TRUE value on second stage will lead that final value is FALSE or a ODD number.

[nwdreamer]

Although my "work for others" IT career is pretty much done, I still write for my own businesses. Especially when programming was new (I started at the age of 7 waaaay back in 1971), everyone tried to show off their skills which resulted in a lot of obfuscated code (there was even a contest for this!) that was virtually unmaintainable. One of the main things that set me apart from my co-workers, is that I used to write everything as simple as I could (which is why I was happy to see you mention it). Ironically, while others wrote complex code in an attempt to show management that they needed to keep their jobs, they only ended up having to maintain the confusing monsters they had created until someone else eventually rewrote them from scratch. On the other hand, because my programs were easy for even a newbie to understand, I was able to pass off the old work and always be involved in whatever was new and exciting.

[jonwoodhead]

The other good practice I would encourage is to review your project once you have finished. So often you will realise that you made a wrong decision that made things harder than they needed to be. It's often only at the end you get the perspective to spot that. Learn from your mistakes. In a commercial environment this step often gets lost under the pressure to do the next thing, but try to find the time.

[donvto]

Some of my personal best practices

1) Use ternary operators for small if else statements
2) GET RID OF COMMENTED CODE THAT IS NO LONGER BEING USED AT ALL

You can also use a Parallel.ForEach in C# if order doesnt matter

[AdebayoAdegbemboAsa]

Awesome! I tried out the StringBuilder option on 100, 000 iterations and it completed same time as I started in seconds. On the other hand, the concatenation approach took 33 seconds to complete. This lesson coincides with a book I am currently reading on data structures and algorithms. I'm learning how much more there are to seemingly harmless practices when it comes to using data etc. Thanks Tim.

[yanwo]

Bonus #1: 35 years ago (can't be!) at Ampex, I coined the phrase, "Paranoid Programming." Your description fits it exactly. Loved the video. In fact I haven't seen one of yours that I haven't liked very much. Thanks!

[VISHNUKUMAR-bhuj]

This is a great video sir 👍

My Best practice is: Writing down my whole plan on a notepad.
I often split the requirement into 3 part
1) The areas I am ready to code
2) The topics I need to research
3) Once my research is done I write some sudo code (Mostly the key logic)


Once my planning is done(Usually I spent more time on this planning ) I am ready to open my visual studio and write my code

Once the coding is complete I will spend some time doing some optimization either by myself or with a friend

[johannes]

My best practice is: if you can't find the error, go out for a walk or sleep a bit. I solved a lot of problems in my dreams.
But, when you got the solution mid night, write it down you hate yourself if you don't know it the next morning. 🙈

[raskand]

Tim Corey = The gentle voice of reason! Great video! Many thanks!

[salali]

I admire your honest content, and your care for your viewers. Thank you Sir.