Best Coding Practices – Naming Conventions
There are a lot of people who say that you must follow a traditional pattern or a notation like Hungarian notation, but I feel it is rather better to establish a naming convention within your project and stick to it, of course, it should be documented somewhere as well. This way any new developers to the team will be able to read the code quickly as there is an imposed standard. In my current project we use the following naming conventions:
namespace MyNameSpace
{
public class MyClass
{
// Constructor
public MyClass()
{}
// Private members
private int _myPrivateMember = 1;
// Public & Protected Members
public int myPublicMember = 1;
protected int myProtectedMember = 1;
// Methods
public int MyMethod(int a, int b)
{
return a + b;
}
// Properties
public int MyProperty
{
get { return _myPrivateMember; }
set { _myPrivateMember = value; }
}
}
}
Internal variables within methods names are not really governed by our naming convention but the generally accepted idea is that someone who doesn’t know what it is used for, should be able to see what it is used for by the name.
While it is perfectly acceptable to use Hungarian notation, I prefer project specific conventions for naming. This allows team members to draw up their own convention, which in turn makes it more readable to the team, especially if team members need to learn a generic convention that they don’t know.
There is a downside to developing your own convention for the project. The convention could make no sense to outsiders reading the code, or it could be very lax. Developers should always get one or more developers who aren’t part of the project and definitely did not partake in the drawing up of the convention to review the conventions at some point to make sure that they are not internalising the convention, and that it is readable.
Best Coding Practices – Exception Handling
I bet every developer says that they subscribe to Best Coding Practices but not many do, and those that do, normally only apply parts of it.
I do try to apply it all but, like most developers, I don’t always find it to be possible. I can handle not using naming conventions etc, but the one thing that really does get under my skin is proper exception handling.
It is not always practical to use try {} catch blocks as they can interfere, and cause more problems. Such as putting one in an event that is fired by a grid to do custom text for the displayed records. This is just painful to have to keep clicking on a message about an error several times.
When it is possible, especially when handling data (DataSets, DataTables, DataRows), exception handling should be employed. There is nothing worse than for a user to get an unhandled exception, which then forces the application to close or, as the users will put it, crash.
but the one thing that is worse than actually not using exception handling is doing nothing when an exception is thrown:
public void Error()
{
try
{
DataRow errorRow = null;
errorRow["ColumnA"] = "My error string";
}
Catch(Exception e)
{}
}
This is infuriating for me since the application will function as expected even though the above code will always cause an error. Every developer has had a bug that makes them pull their hair out cause the application looks like it is working fine but they know something is off, and eventually they will find something like the above code and first scream for joy, and then start searching the subversion log trying to find out which idiot wrote such bad code.
If you don’t want to popup a message then send it to your application’s log, any developer worth with his salt will have a logging system in place, if you don’t have a logging system in your application, then just send it to the OS’ standard event logs.
Most applications have message boxes that fit in with the aesthetics of the application, in a project I am currently working on, we have completely built our own custom message boxes from the ground up and are not using the Standard .Net MessageBox.Show() at all. If you don’t have something like I do, then for crying out load use the .Net MessageBox:
public void Error()
{
try
{
DataRow errorRow = null;
errorRow["ColumnA"] = "My error string";
}
Catch(exception e)
{
MessageBox.Show(String.Format("{0} {1} {2}", e.Message, System.Enviroment.NewLine, e.StackTrace), "Application Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
}
}
It may be crude, but at least the user knows that an error occurred and they can report it, and actually give you the developer something to work with when you get a bug report of “application threw an error on xyz screen” with no steps to reproduce.
The bottom line is this: If you don’t have some form of exception handling in place, you are just making your own life more difficult later on when it all seems to work except for the part when a user does one small action and it just “Crashes”.
about me
I am a C#, Silverlight, K2 workflow and Sharepoint Consultant, living and working in Johannesburg, South Africa. I have a passion for teaching people anything I can in order to spread the knowledge and skills I have. You can follow me on twitter at @MrThirsty. You can view my full profile at about.me
Certifications
