Posts tagged DotNet

MonoTouch - iPhone Application Development for C# Developers: http://cli.gs/SU3PQH  - Awesome! via @rschu from Twitter

In a project I inherited I noticed that the previous Developer made heavy use of Constants and tended to do some rather laborious if/then conditional checks related to these Constants.

Here is the pattern of code used:

1. if (MethodToCheckIfNeeded(Class.Constant))
2. return (MethodToDoAction(Class.Constant);

* This source code was highlighted with Source Code Highlighter.

NOTE: You would replace “Class” with the defining class/type and “Constant” to the specific Constant value you are inspecting

The idea is that the IF condition runs a “check” based on the value of the Constant to determine if action is needed. If action is indeed necessary then the code runs the associated “action” method sending in the same Constant value as the parameter.

This is not only laborious but it means that for every new Constant of the “type” being checked you have to go add corresponding if/then checks everywhere to handle this new data.

The really bad part is that this same conditional check is done several times based on the same Constant values. The previous Developer just kept doing that over and over again. You would have thought he would have seen a “pattern” there.

This Developer also tended to prefix Constant Variables with a “type” such as PARAM, FLD or TBL. With this in mind, we can easily loop through the “fields” of the class to either make a list or initiate an action on a given Constant.

Here is a solution that can easily be re-used:

1. // Define the Constant Values to be used
2. public const string PARAM_ONE = ”This”;
3. public const string PARAM_TWO = ”is”;
4. public const string PARAM_THREE = ”a”;
5. public const string PARAM_FOUR = ”better”;
6. public const string PARAM_FIVE = ”solution”;
9. …
12. FieldInfo[] fieldInfo = this.GetType().GetFields();
14. string constantValues = string.Empty;
16. foreach (FieldInfo fi in fieldInfo)
17. {
18. // We are only looking for Constants
19. if (fi.IsLiteral)
20. {
21. if (fi.Name.Substring(0, 6) == ”PARAM_”)
22. constantValues += fi.GetValue(fi) + ” “;
23. }
24. }
26. if (constantValues != string.Empty)
27. MessageBox.Show(constantValues);

* This source code was highlighted with Source Code Highlighter.

Notice in the sample above that I am checking only for Constants that have a prefix of “PARAM_”.

Also notice that I am limiting my check down to “literals” which means they are values that are defined at runtime and not changed (i.e. Constants).

There are other checks you can do there as well.

Another thing to note is that the GetFields() method also provides for further filtering using BindingFlags such as Public, Static, etc. In this case my Constants are Public and that is the default for GetFields().

Just to illustrate the technique, I am concatenating the values of the “PARAM” Constants into a single String and Displaying the “message” via a MessageBox.

In the case of the problem I am trying to solve, in the loop I could call the “IsNeeded” method using the Constant’s Value and in the “then” part of the condition I could call the “Action” method with that same value.

You could further create a List of these values that could be re-used in other methods so that you don’t have to re-run this code again to retrieve the values but either way you still have to do a loop to get the job done.

Clean, simple and I don’t have to keep adding new if/then code every time I add new Constants of a given “type”.

I like it

I’m sure there are other solutions so if anyone would care to share please do.

I am sure a lot of you that program in .NET using Visual Studio have become familiar with the concept of “regions” in your code. A “region” is a way to separate a block of code so that it can be collapsed and expanded as necessary. This can be good when you want to “hide” code that isn’t updated often as to not confuse, or annoy any developers that may be working their way through your code.

I’m sure many of you are already familiar with “regions” but here is the obligatory example anyway:

1. #region Code I want to Group Together
2. // Some truly amazing code here
3. #endregion

* This source code was highlighted with Source Code Highlighter.

Sounds good right? Well, there is a seedy underbelly to this “freedom” in coding. It is nice to be able to “partition” your code out to make it easy to “collapse” code away that you are not interested in to make it easier to navigate your code but when you think about it, if you have so much code in one code file that warrants adding “regions” to “hide” certain code as to get it out of the way doesn’t that set off a bell in you that maybe your code file is way too large? Could it be that “regions” are now providing you with an excuse to fall into the old “spaghetti code” mentality?

For me, it is quite annoying when I get into a code file only to find that there it consists of several “regions”. Sure it looks neat and tidy but when you open such a file what is your first instinct? You may know exactly what “region” to open and thus you dive directly into that one and continue with your work. However, you may not be too familiar with this code file so you may find yourself hitting the old +”Ctrl+M,L” shortcut to expand everything. But as soon as you do that you find that this innocent looking code file is now thousands and thousands of lines of code including multiple nested “regions” to muddy it up all the more.

So what can you do to make such tasks easier? What can you do to separate related code out to make it easy to find and easy to work with? Two words for your “Partial Classes”. With .NET 2.0 and above you have the ability to separate the “guts” of a code file into multiple code files simply by adding the word “partial” to the class definition.

Here is an example:

1. public partial class Customer : IPerson

* This source code was highlighted with Source Code Highlighter.

It is important to note that “Partial Class” file can have any File Name but most people use the format: MainFileName.PartialClassName.cs just to make sure the files are grouped together and make sense to other developers.

I know, I know, many of you are saying “big deal, this has been around a long time now”. Yes, this capability has been around since 2005 but most people out there only ever use “Partial Classes” when dealing with ASPX and ASCX Files and never consider using this great idea with their regular Class Files.

Usually when you think about an Object you may find yourself breaking out multiple Class Files that all relate to a specific task surrounding your object. This makes perfect sense and so finding several related Class Files that break out functionality is “normal”, however, there are times where a single Class File grows quite large and you don’t wish to separate its “guts” into different sub-objects but you also want it to be easier to maintain and easier to share in a Team Environment. This is where “Partial Classes” come into play.

If you separate related code in a Class using “regions”, that will make it easy to see what code is related to each other (in a sense) but it still goes against Team Coding practices. If Developer A wants to edit Functionality X of this Object, he has to check out the same file that Developer B already is editing. Modern “merge” features are better now than they used to be but this can be a pain. However, if instead you separate such related functionality into “Partial Classes”, Developer A can check out just the “Partial Class” he/she needs and thus not disturb the work of Developer B. Oh sure there will be instances where multiple developers will need multiple “Partial Class” files checked out but having these all separated out will ultimately prove to make development and maintenance easier.

Don’t get me wrong, I am not suggesting including all functionality into one big Object via “Partial Classes”. If you have an Object, lets call it “Customer” and this Object has “Accounts”, you would still want to create an “Account” or “CustomerAccount” Object. What I am suggesting is instead of using multiple nested “regions” to partition your code, why not use separate “partial” class files to not only make it easier to understand but easier to maintain and easier to share development work in a Team Environment.

To give an example of how “regions” can be bad, just yesterday I found myself editing a monolithic code file that was not only filled with multiple nested “regions” but it also had an extreme number of unused Compiler Directive #if/else conditions. In this case I simply deleted all the unused Compiler Directive conditions which meant deleting 2,500+ lines of code. This still left an excessive number of nested “regions”. Maybe someday when I am feeling brave enough and have the time I will pull those out and create “Partial Classes” for each distinct area of code.

Removing the “dead” code made this Class File easier to navigate, just think how much easier it would be to maintain with all the “regions” pulled out into their own “Partial Class” files.