Saturday, June 16, 2007

Some Best Practices to follow when coding .NET languages - Part 1

I know we're all used to programming in our own individual styles especially for small personal projects. But as you join the corporate workforce, where individuality equals inefficiency (sometimes), we have to abide or follow some of the coding practices a company already imposes on it's programmers. The main reasons companies do this is so that their code is maintainable and reduces the culture (coding) shock a new employee has to deal with.

One of the most common and equally frustrating practices of programmers now a days is not adapting a coherent and descriptive naming convention for their methods, variables, classes, modules, etc. Ever encountered method names like writeFile, editInteger? Although they may sound proper, what file does writeFile refer to when there are a million files used by your system? It's going to take a long time debugging and searching for that specific file, and you haven't done anything meaningful yet. An example of a better method name could be "writeToContactsFile" or "writeToStudentContactsFile". Now you have a specific and (to a degree) descriptive method name, and you don't have to look as hard for the files you need.

For less strict languages like VB.NET, you can opt to disable the Options Explicit, which allows programmers to disregard default access modifiers or type and just type in the variable or reference names. This may sound like a great way to reduce coding time, but you'll be kicked straight back in the butt by the error list as your projects get larger. Strict languages like C# require you to specify the data type and access modifiers, failing to do so results in a compiler error. Example code that is acceptable by VB.NET:

Function UpdateContactList
End Function

The VB.NET compiler assumes this as Public if the access modifier is omitted. This also being a function, the return datatype Object is assumed when there is no data type specified. This would work fine in small projects, but as the project gets more complicated, you'll start to notice all of the variables outside of any iteration or recursion procedures are visible to other methods within the same class or namespace and that you wasted some bytes of memory by referring to UpdateContactsList as a function but does not return anything (why not make it Sub instead?). So much for OOP, eh?

This concludes part 1 of best practices, hope you guys learned something and hopefully adapt them to your projects. I'll be posting some more in the near future, so stay tuned! =)

Other parts in the Series:
  1. Part 1
  2. Part 2
  3. Part 3



Permalink

No comments: