Code Refactoring

"A software application is not complete when there is nothing more to add, but rather, when there is nothing left to take away." (apologies to Voltaire)...

Re-writing and re-organizing your code, known as refactoring, should be the heart and soul of your development process. Your goal is to make the code at each level, have a single purpose, use the most common and simplest toolset, be as straightforward and easy to follow as is possible. You should be able to explain any level of your code to another junior programmer in under 5 minutes.

Your code should exhibit high cohesion. In other words, at any given level, your code should do one thing and one thing only, do it simply, efficiently and effectively. Communications and use of services to accomplish tasks should be easy to follow, obvious and simple.

Variables, classes/objects and methods should be named well. Feel free to agonize over names, it IS important and you will need to live with them for a long time. Good, solid names that are in sync with the business process they support can make a huge difference in the readability of your code and when discussing feature sets and processes with non-IT folks.

Lastly, but still very important, apply the concept of refactoring to your design meetings as well as your coding. Just because someone has a "solution" or can come up with a way to "solve" a problem does NOT make it the correct one.

Re-design your ideas and assumptions as well. Do not be afraid to throw an 8' dry-erase board full of plans out the window and try something new. Walk through your ideas, pick them apart and shoot as many holes in them as you can. Once you adopt them, they become much more difficult to change.


Good Luck and Enjoy your Coding!

Read more...

Pain in the m_*!@#$

Everytime I do work for a client that has internal coding standards I find myself having to change between using the letter "m" or an underscore "_" or, God forbid, both of them "m_", when I need to name some variable that has a public property associated with it.

Here is what I consider to be a better fourth option. Enclose all of your backing variables into a structure. Then create a single instance of that structure and store it in a private variable called "Local".

It's easy to do, easy to read/write and provides a single method that works for everyone.


Public Class Employee
  
    Private Structure backingStore
        Public firstName As String
        Public lastName As String
    End Structure

    Private Local As New backingStore

    Public Property FirstName() As String
        Get
            Return Local.firstName
        End Get
        Set(ByVal value As String)
            Local.firstName = value
        End Set
    End Property

    End Class


Read more...