imagesEvery developer has their own style of writing code. I'm sure I'm not the only person that has inherited code from someone else only to make grimacing faces when you open it up in Visual Studio. I will admit that sometimes I want to slap people for what they have handed over to me but I'm sure someone has wanted to slap me a time or two as well. If you are like most developers you will have the immediate urge to "fix" this code to bring it up to your "standards". I'm no different. Not that I claim to be the swami of coding standards. I'm always learning and getting better but I think I am not bad compared to stuff I've seen. Here are a few of my philosophies. I have to say that a book that I read called Clean Code by Robert C. Martin has really made an impact on my thought process. I think in general we get so caught up in the work of writing code that we step back and think about how we are writing code. When it comes to coding with CRM 2011 I have some basic thoughts on what things should look like.

Let the code tell the story

Unfortunately when I inherit someone else's code I see one huge method that requires me to hit the page down button a few times to see it all. This is one of my big gripes and plan on running for president of stop doing that crap to other people... organization. Even if you have comments in your code which is rare, if you are doing 50 different things all in one method then its harder to read when the poor smuck that gets stuck with your work after you are gone. Don't do that to them (or me)! Here is my main guideline for code:

  1. Every method has a job and only one job. If you have to hit page down to see the whole method you either need a bigger monitor or you are doing too much.
  2. Use verbose names that actually mean something and tell the story. Variable x doesn't mean jack to me or anyone else. Name your methods with the thing it's actually doing even if it tends to get long. I should be able to go into a main method and "read" what the application is doing. Let the variables and the method names become part of your documentation. If you do this then comments become less of a necessity, but I still don't mind if you leave me some.
  3. Don't do all your work in your plugin Execute method or JavaScript event methods. I don't like to do my work in the event methods because that is where I want to start telling my code story. Event methods should call other methods to do the work. If you do it this way then when the next person that comes along needs to do something else they just have to add a new method call above or below yours. Does that make sense?
  4. Don't hard code attribute names in your plugins or custom applications. If you are going to use late binding then at least declare your attributes names as constants. I absolutely can't stand looking at a custom app or plugin with 50 million hard coded attribute names all over the place.

Keep It Simple Stupid (KISS)

Every problem has more than one solution. If you don't think so then you either don't understand the problem well enough or you don't have a full grasp of the possible solutions. Perhaps the problem isn't even defined correctly in the first place. The point is don't make things more complicated than it needs to be. I inherited an application where the previous developer had written a custom ASP.NET application that was hosted in an iFrame of a form. In the host web page the developer retrieved an XML web resource from the server that contain a list of servers and then this was used to compile a URL to redirect the current page to the custom web application. Not only that but the developer invoked an ActiveX control to parse the XML file to get the settings. This seemed a little overly complex for just pointing the user at the right URL for the custom application besides the fact that the custom web app shouldn't be dependent on what CRM server we are on.

Question Your Conclusions (at least once)

Like I said there are multiple solutions to a problem. You may come up with some good ones, but there are always more. Maybe the best way to go is with an ASP.NET application. It's probably better to go with a Silverlight solution but sure I'll take go with it. The more complex your solution the less likely it is the most appropriate solution. Ask yourself and someone else who you know won't sugar coat their opinions. If you're in a team situation then this problem won't be too much of a problem.

This is just some of the things that go through my mind on projects. I'm in the process of coming with a more formalized development philosophy and strategy when it comes to multiple developer CRM projects so stay tuned and I'll float something out there shortly. Hope that this little byte of thought was at the least something to get you through your morning cup of coffee/hot pocket.