Best Practices for Dotnet Framework

1. MAKE A PLAN BEFORE YOU START WRITING YOUR CODE

OOP is a great way to compartmentalize software code, but you can get lost in the details if you don’t have a good plan. It’s a good idea to use a tool such as Visio to plan out each class and its properties and methods, for example, before you start coding. Planning ahead ensures the organization of your code is a success before you even write the first line of code.

When you’re planning ahead, identify each component of your application and plan methods and properties that would make up a specific class. If you have a customer class, identify what information you need to store for a customer. You might need the customer’s address, name, phone number, and gender. These would be properties of the customer class. Planning helps you identify the components needed for your software, so you won’t forget them and have to go back and refactor your code.

2. DON’T FORGET THE DATABASE

Every dynamic web application needs a database. Normally, .NET developers work with Microsoft SQL Server because it plugs into .NET code so easily. You can, however, use another solution such as MySQL or Oracle and several of the NoSQL solutions on the web.

Just like planning your classes, you need to plan your database layout. Because a poor database design can cripple the application, the database layout is almost more important than planning your code . You can use Visio or another third-party solution to plan out your database design. When you plan your design, don’t forget basic database rules such as normalization, redundancy, and backup plans.

3. KEEP VARIABLE NAMING SCHEMES CONSISTENT

If you’re writing code for a client, they might have documentation that defines the way you name your variables. If you code for your own projects, you should keep the naming schemes consistent.

Some basic standard rules across development teams include:

• Using camelCase for method variables.
• Prefixing private variables with the _ character such as _myVariable.
• Always using verbs for methods such as “GetCustomerInformation” or “SendEmail.”
• Using standard case for class property variables such as “FirstName” or “LastName.”

These are some standard rules across the development community, but if you’re working on a project for a client, always ask for their coding standards documentation.

4. REPLACE LONG “IF” STATEMENTS WITH A FUNCTION OR METHOD

You can use if statements, but when you start nesting them or using several “elseif” statements, it’s time to turn the if block into a function. Here’s an example:

if (x > y)
{
// do something
}
elseif (x < y)
{
// do something else
}
elseif (x == y)
{
// do another something else
}

You can keep going with if statements with several elseif statements (or even start nesting them), but this can make the code harder to read, and the logic harder to understand. It also increases the chance of a logic error in your code. To avoid this, break out these statements into a function or method within the class. It organizes your code and makes it easier for a developer other than you to understand.

5. SEPARATE YOUR LAYERS

Good coding requires layers. At the very least, you should have a presentation and a data layer, but most software design calls for a presentation layer, a business logic layer, and a data layer. The presentation layer is what the customer sees, the business logic is the layer specific to the nuances of the business and its organizational rules, and the data layer is for database methods.

The reason for layering is that you can completely overhaul one layer without affecting another. For instance, the data layer is made up of all database calls and connections. If you decide to switch database providers, you can change the data layer without affecting the presentation and business logic layers. This type of design is enterprise level, so it can be difficult for new coders to grasp until they see it in practice.

There are several third-party libraries in NuGet to help you get started with application layering. Do a search for “dependency injection” and you’ll find several frameworks to get you started. If you work with MVC, then your layers are somewhat automatically separated (with the Controller owning the business logic and the View containing the presentation layer). You still must use dependency injection for data layers.

6. WRITE ERRORS TO AN ERROR LOG

When you have a large application that runs on a server, you need a logging solution. This solution allows you to identify critical errors in the application sometimes before users do. Normally, users will report errors and it’s up to you to find the underlying cause. It can also be extremely tedious and time-consuming to reproduce a user error.

Luckily, .NET has an internal logging system that lets you write errors to the Windows Event Viewer. You and the system administrator can search for errors thrown by the application on the server, so you can see the exact error without trying to reproduce it in your development environment.

You can create your own separate application log in .NET, too, so all of your application’s errors are logged to a specific category in Event Viewer. This separates your custom software errors from other applications.

CONCLUSION

.NET is the de facto framework for Windows development, but it can be difficult for a new developer to learn the ins and outs. Just remember to plan your code so that you don’t wind up refactoring soon after you’re finished. Make your code scalable by creating a plan first, and then code using common standards. These standards make it easy for another developer to read your code and add to it in the future.