Some Best Practices for C# Application Development

Few days ago, in one my earlier posts, I discussed about “Some Best Practices for Silverlight Application Development (XAML)” which got a huge hit by my readers. I got a lot of feedback on that too. Someone from the community also suggested that I write some best coding practices on C#. This struck in my mind and hence I decided to write some best practices about C# coding here from my past few years of experience.

For the past few years, I learned a lot and tried to share the best of my knowledge with others who are new in the software development field. I contribute this post to those fellow members. Hope I will get more feedback and/or suggestions here too.

I liked C# programming when I started with .NET technology. I never tried to write code in VB.NET as I decided my career on that. When I was new to this field, I made a lot of mistakes and from those mistakes, I learnt more things. There’s a proverb: “Mistakes make you learn more & more…”. My career was one of them. Also there’s a proverb: “There’s no end to learning in life. Each second, a person can learn”. So, if there are any more suggestions, please share those with me. It will help me and others to learn more in a proper way.

One second, there are various posts available on the internet regarding the same topic. If you do a Google, you will get a number of them. But these collections are based on my experiences, those I learnt and thought of sharing.

Let’s stop here and start discussing the Best Coding Practices of C# application development. Here are some of them:

• Use proper Naming Conventions
  • Always use Camel or Pascal naming format
  • Avoid all uppercase or lowercase names
  • Never use a name which begins with numeric character
  • Always prefer meaningful names for your class, property, method, etc.
  • Never build different names varied by capitalization
  • Don’t use the same name used in .NET Framework
  • Avoid adding prefixes or suffixes for your identifiers
  • Always use “I” as prefix for Interfaces
  • Always add “Exception” as suffix for your custom exception class
  • Never prefix or suffix the class name to its property name
  • Prefix “Is”, “Has” or “Can” for boolean properties
  • Don’t add prefix for your controls
• Decide between Value Types and Reference Types
• Always Use Properties instead of public variables
• Use Nullable data types whenever required
• Prefer Runtime Constants over Compile time Constants
• Prefer “is” and “as” operators while casting
• Prefer string.Format() or StringBuilder for string concatenation
• Use Conditional attributes when you need them
• Use ‘0’ (zero) as default value enum value types
• Chose between Equals() and Equal (==) operator
• Always prefer the foreach(…) loop
• Initialize member variables at the time of assignment
• Initialize static member variables with static constructors
• Use constructor chaining whenever possible
• Minimize boxing & unboxing of objects
• Properly utilize try/catch/finally blocks
• Catch only that Exception which you can handle
• Use IDisposable interface
• Utilize LazyInitializer in most of the cases
• Split your logic in several small and simple methods
• Try to use Patterns & Practices like MVP/MVC/MVVM
• Always prefer DataBinding to populate values in the UI

Explanation

You can read the explanation in this article.

History

• 20^th September, 2010 - Initial post
• 17^th October, 2010 - Explanation of points

Explanation of those points are published as an article. Read it here.

 

I would appreciate some more points if you have any to include in this article. CodeProject