C#: Using the Get/Set Effectively In Properties

Posted on by

One of the great things about C#, which I grew to love after switching from Java a few years back, are the properties. Properties allow you to use a Get/Set method right in the property which means you can use them like a variable (though .NET encourages you to call them LikeThis with a capital letter instead of a lower case). But why are they so powerful and effective? Well, lets take a look at an example. Take for instance one of the things I came across just today. Every time I compile my application for the Windows Emulator, it installs the application over the last one. This wipes all the files and directories I created on the previous run. This makes sense; it’s a new build so you have to run it as an application that’s just installed. This obviously means I have to make sure all my directories exist on start. One approach, is I can check if my directories exist before doing anything to them; this is cluttered and looks sloppy. Alternatively, this is where I can use the Get/Set of a property to my advantage!

I use a static variables in a GLOBAL class to hold persistent references. Doing this is somewhat deputed but I have found it is the most straight forward way to hold references you want to persist through the life time of an application. (Keeping it to ONLY data that needs to be persistent mind you! I’ll discuss the common mistake made by programmers with static variables in a different post)

Ok, enough talk. Lets go to the example. In Windows Phone 8, I can obtain the default application directory handle by doing the following (took me forever to find this by the way):


GLOBAL.JOURNEY_FILES_LOCATION = Windows.ApplicationModel.Package.Current + "/Journeys/";

For those who came here looking for “how to get root directory”, the above code is what you need to obtain your application directory in Windows Phone 8.

Back to the example; the issue here is that the directory doesn’t exist yet! If my user wants to load all the journeys (regardless if they exist) my application will explode with and IO exception. But wait! I don’t want to clutter up my code by checking if the directory exists EVERY TIME I do anything with the files. So how do I make sure that directory exists no matter what? With minimal clutter? Take a look at what the actual JOURNEY_FILES_LOCATION looks like:


 private static string _journeyLocation;
 public static string JOURNEY_FILES_LOCATION
 {
       get
       {
            if (!Directory.Exists(_journeyLocation))
            {
                Directory.CreateDirectory(_journeyLocation);
            }
            return _journeyLocation;
      }
      set
      {
            _journeyLocation = value;
      }
 }

So what have I done here? Well instead of having to call some function that checks if the directory exists and create one if it does not, I have the property take care of managing that itself. It’s encapsulated; I don’t have to bother with it ever again. I prefer to do things like this on the “get” of a property; most people prefer it to be in the set. Both are equal, with some down and up sides, but it will make sure that the directory exists. So what happens here? When I request to get the current directory, the get method goes in and checks if the directory exists and creates one if it does not. I don’t even need to bother with checking exclusively anymore! As a result, if the user wants to see all their current Journeys and the directory does not exist, it will ensure that the directory is created. Take this as an example:


public static JourneyObjectState RemoveJourney(string name)
{
     if (File.Exists(GLOBAL.JOURNEY_FILES_LOCATION + name))
     {
         File.Delete(GLOBAL.JOURNEY_FILES_LOCATION + name);
         return JourneyObjectState.Removed;
     }
     return JourneyObjectState.NotFound;
}

Why not just create all your directories on the start of the application?

You could and a lot of programmers will code that way. However its not the cleanest way to approach the issue. It’s also very prone to crashes, because if you forget to create one of the directories at the start or somewhere along the lines you delete the directory, your code has the potential to crash. This is what I call “air-tight” programming. I means that it ensures that no matter the the circumstances, your code will not crash the application. You’re safer checking if the directory exists every time rather than creating it and hoping it will not disappear.

Isn’t checking for the directory every time expensive?

Yes and no. We aren’t making a videogame here which has to access the file 30-60 times a second (and why would you code a game to do that?). Obtaining files is very fast via memory chips so I have don’t have much of a concern here. For instance the same application loads photos at one point and it is fast fast fast even on an emulator. This would become a burden if you run this on huge volumes of files but otherwise, this is not a performance bottle neck. Not in today’s age anyways.

Closing Notes

 Be careful when doing this for database records

I can see people having the temptation to hook up a database call to this. Files are fine but if you will slow down your application trying to call a remote database remotely like this. I would look for other ways to handle database interaction as this is expensive. For instance if you want to obtain a user through the “get”, this is not a good approach unless you make sure that you are not recalling the database after the user has been obtained.

Aaron Swartz; A small tribute

Posted on by

Unfortunately today I learned today Aaron Swartz is no longer with us. I will keep this blog post very short, but I thought I make a small tribute to him. He became a strong influence on web technologies at an early age, helping sculpt RSS 1.0 as well as played a key role in Reddit.com. Not a lot of people know him and probably will never, but this young guy fought for our information freedoms by putting a spotlight on JSTOR’s “premium” approach to academic material. If you don’t know him, please look him up. Unfortunately he is no longer with us.

Wikipedia

Reddit’s Tribute Page

Using The Main(string[] args) Better

Posted on by

I have recently started a college class on Java. It haven’t worked with it in a while and thought maybe its a good choice as the last elective I have left to do. One thing I noticed is that a lot of the assignments and examples don’t mind if you cram your code into the


Main(string[] args) { [...] }

which is fine for those just beginning programming. For a lot of people just making code work is already a god send. However, I cannot help but point out that this is a fairly bad practice for a few reasons:

  • Any class scope variables have to be static
  • All functions have to be static
  • You have to initialize all your variables inside of the main function. Not a good practice.

This is not a very good thing because this is a pitfall for memory management. A program NEEDS to have a static entry point, but this does not mean that you need to wrap your code around it. If everything is static (which is something students LOVE to abuse), then the only time your memory gets cleared is when your function variables go out of scope and/or when the program exits. This is a bad coding practice which makes it very difficult to write optimized applications.

So what do I do?

You don’t have to do much. Simply create a non-static class and call it “Main” or any name you would like to give it. Then simply create a new instance of the variable inside the main and call a start function. Very simple! Let me show you an example:


     public class Main 
     {
          //Now your class variables don't have to be static
          int myInt;

          public Main()
          {
              myInt = 0;
              //Your variables initialization here
          }

          public void start()
          {
          //Put your code here!
          }
     }

and so your static main now looks like this!


public static void main(String[] args) {
      Main main = new Main();
      main.start();
 }

Should I Teach This?

I started Java a about 6 years ago and for a very long time I did not understand how to structure code in an easy way. This concept might be a little bit confusing for students, but it will clean up their code. Students starting Java without coding experience still don’t understand what static variables are (and why you should avoid them), so this will help them avoid the pitfalls of “Well everything is static ill just make mine static too!”. It removes an extra element for something that is already somewhat confusing for many!

Closing Notes

        This helps exit your application better

Its not quite faster or “better” in the sense of exiting, but it nests your code in such a way where you know when your application is exiting. The only time your code will go beyond the “main.start()” is when it is exiting or switching states. This is extremely useful if you want to do some processing right before exiting.

Document and comment everything!

Posted on by

It is more often than not that I come across a lot of code that has absolutely no form of documentation. Thankfully most of the time I have access to the source code and I can figure out what is going on on my own. This however, is a waste of my time and resources; time which could be spent utilizing the code rather than trying to figure out how to use it.

Programmers are lazy; we have a lot of work and little time to do it in. More often than not, documentation is not a priority and will not make the cut before the software is due. As a result servicing your own software or someone else’s code becomes a burden rather than pleasure.

Imagine for a moment that you have spent the last three months working of a piece of software that will service 100 people in a company. The software is up to par with the requirements put forth by the customer and as it turns out, they are very happy with the results. Three more months go by and the customer comes to you again because something needs to be changed or even worse, upgraded. This is a common scenario a programmer has to go through if they have to work with clients. As a result of this cycle, there are two outcomes possible:

  • You have to go and build on top of the code you have already written to add the changes or add new features
  • Someone else has to do the job for you; someone who does not completely understand how your code works and yet must go in and make changes.

In either scenario, you are working with code that has to be reused. If you are the one in charge of making the changes, there is a very good chance you do not exactly remember how to utilize the libraries and code structures you have written. If someone else has to work with your code, they have no idea how your code can be utilized to create new functionality; even worse they have no idea how the code works internally, provided something goes wrong.

From my experience, many programmers don’t want to take the time to run through their code to add comments or write documentation. I can relate to that; I want to get stuff done and stopping to comment anything is well… time consuming. But no matter how much we flinch at the idea of commenting code and writing the appropriate documentation, it is truly a necessary bother.

It is safe to say that we can, most of the time determine what a function or a class is responsible for based on the signature of the function. To obtain an employee for instance, a function can look something like this:

        public Employee getEmployee(string ID) //Strings for ID is common, provided many databases hold them with 0's at the front

Looking at this we can safely say that this function provides an employee object based on the ID of the employee. Despite the simplicity of the example I can already outline a potential problem which can be solved by consulting the documentation. Going along with the fashion of providing simple examples, lets imagine that for this function the documentation is as follows:

getEmployee is an obsolete function that is used to obtain employees which carry the NNNNN ID number format. All employees currently have a new and old ID number. Because many of our applications need to be updated to a new ID number system, this function has not been removed until all our systems are upgraded. For the new system, please use the getEmployeeSomeNewSystem(string ID) instead

This can happen when a company obtains a new software package, for instance PeopleSoft which manages your back end infrastructure such as employee records. Because your old system is running out of ID numbers, it maybe that you are implementing a new ID number system while slowly porting over old applications to use it.

It is obvious that in the above example, you would probably know about this detail fairly well. However, as software becomes more and more complex it becomes difficult to keep track of these kinds of things.

Simple examples aside, it is most important to point out that everyone programs differently. Despite code standards, each programmers will still structure code differently, call things differently and approach coding problems differently. For instance it is common in video games that memory allocation becomes a serious consideration; after all, you are running your code at 25 to 60 times a second (depending on frame rate). A common way to try to curb the amount of memory an game uses to to use an object pooling mechanism. Once an object approaches the end of its life cycle, for instance a Vector3, instead of disposing of it you push it onto an object stack. When a new Vector3 is needed, if there are objects on that stack you simply pop one off and reuse it. This saves you on having to create a new copy (implications of doing this is for a different post). Though there are libraries that do this already, I for instance always like to write my own class for doing this. It minimizes overhead that large libraries have and reduces the complexity of the class to a few functions. Pooling, however, is not always a known approach to some programmers. Some of them might have to figure out what

//Pool has been instantiated somewhere else
SomeObject myObject = pool.resurect<SomeObject>();

does and why am I not just saying

SomeObject myObject = new SomeObject();

In this case I would provide a documentation and examples for the Pool class that takes care of managing object allocation. A programmer may or may not have seen this before, but regardless of that, s/he has to figure out if it is worth using this approach. Often we package off our libraries in DLLs and as a result, it’s quite frustrating to sift through some other solution to figure out what the hell this does. A documentation however, makes this very clear and straight forward and easily accessible.

Ok cool, but how to I approach this “documentation” stuff?

Everyone has their own approach to documentation; there is no golden rule to it. To me the definition of “good documentation” is documentation that makes it clear why this class or function exists and how to use it properly. But there are different types of documentation we have to consider. For instance, I do consider comments to be extremely important but they are not “documentation”. However, consider the following example:


/// <summary>
 /// Use these as the basis for your transformations. It is temping to allocate a new vector each time but it is very costly
 /// especially if you run your game on a mobile device
 /// </summary>
static class Vectors
{
[..STUFF..]
}

In languages such as C# along with other .NET based languages, you can create what I like to call “internal documentation”. This is not the same as comments because when I call upon the Vectors class it provides me with the description. It holds transformation vectors such as [0 1] so that I don’t have to create a new one for computation. The class name “Vectors” can mean a few things. One might think it is for processing vector transformations, when it is actually just holds vectors for common use. However, because I have provided the <summary> information at the top of the class, when I call upon the Vectors class, intellisense will display the summary. This is most probably available in languages such as Java (along with an IDE that supports this), though I have not touched it in a while.

The other kind of documentation is written out documentation with examples. It is not part of the code and is normally found on some kind of resource. For instance a common place to store documentation are wiki’s that are restricted to only the development team. However, it does not have to stay internal. Almost every class in any of the Microsoft frameworks has examples, sometimes in multiple programming languages. This is probably the best resource a programmer can hand to another. If you are carrying a library from one project to another and have no documentation, you are going to have to go into the solution of a project that implements this and figure out how they implemented it there. This is a huge waste of time. In an off solution example, a programmer can generalize the implementation of a class so that you can use it for something else. If you go look at how someone else used it for something else, you’re gonna be stuck with the question

Well that’s great, but how do I use that class or function in general?

So, how do I approach this “commenting” stuff?

Rule of thumb I use; leave short but precise comments everywhere you can, but don’t tip the boat over with comments. Make sure they are constructive.

As a programmer, I don’t want to know why for instance, you created a list of employees unless there was some kind of serious decision behind it. For instance:

     //Create a list of employees
     List<Employee> employees = new List<Employee>();

Cool,  I am not learning how to code. After all “reading code” means I can see that this is a list of employees. However, if you do something like this:


       //This list is used for all employees, those pulled from the old system and the new system.
       List<Employee> employees = new List<Employee>();

This is A LOT more useful because now I know why you created a new list reference and initialized it with a blank list. This tells me that you have created a new list, to then you will it load with employees rather than re-point the reference to a returned list.

As I have mentioned before, comment as much as you can. Programmers can always read code well enough to soft through your written code fairly quickly but comments allow us to figure out why you created something a certain way. When there is a bug, I can quickly follow through with your comments and figure out where you went wrong.

To wrap things up

I think its about time I start wrapping this blog post up. However, I hope I have made a pretty good point; take the time to document. It will pay off in the end. If you work in a company that makes software, there is a pretty good chance you will be passing on your code to someone else. While you’re still around, you might get away with “Steve, how do I use this function properly?”. But has your code base grows and more and more people start using it, you can no longer answer everyone’s questions. You are now responsible for the efficiency of those around you and the quicker they can reuse your code, the better. One day you will not be there anymore and well, you might not care but some programmers do. After all, it is YOUR work that they are using in their software. If you ever have the chance to appreciate someone else leaving documentation for you to look at when they have long stopped working there, you will appreciate it.

 

Early Programmers: Initializing an empty object to be replaced

Posted on by

This is my first programming post and I thought I would start with something that I see all the time with programmers who are just seasoning. This is a common mistake I used to make as well and I believe it stems from the miss understanding of how variables and references relate to one another. Thankfully .NET based languages (including those which compile down to CLI) manage object deletion automatically. Otherwise you would have a pretty serious memory leak.

Lets look at a common example. We are using C# here but Java should look almost one to one. For instance if we have a simple class:

class SomeObject
{
     string someString = "";
     int someInt = 0;
}

and so I implement it as follows

public void main() //Lets assume this is our entry point
{
      SomeObject obj = new SomeObject();

      //someBLL is an arbitrary static class that gets your data from the database or some other source and creates a new object to hold that data

      obj = SomeBLL.fetchObjectData();
}

What has happened here is a new object reference has been created, pointing to an object, only to be repointed to another object. Considering the new object:

     SomeObject obj = new SomeObject();

is quickly overwritten by some new object that someBLL.fetchObjectData(); returns. As mentioned before, C# has a garbage collector to deal with objects that are being disposed, but in reality this is a memory leak, garbage collector or not. For those who are just starting programming in C# (and Java), there are a few things that needs to be outlined:

  • “obj”, as I have named it above, is a reference to an object in the memory. It is not actually the object itself, but rather points to some location in memory at which the object is located
  • If you use the same reference again, for instance in obj = someBLL.fetchObjectData(); as mentioned above, the variable “obj” now points to a new location in memory for a completely different object.
  • When you re point your reference, you leave the old object still in memory taking up space.

So what is the solution to this? It’s very simple. Simply don’t create a new object before repointing your reference somewhere else. To correct the code above, we can do the following:

 public void main() //Lets assume this is our entry point
 {
      SomeObject obj = SomeBLL.fetchObjectData();
 }

However it is common that doing something like this is not quite so simple. For instance, what if I need to decide from where my data is coming from? I am getting the same object type back from either, but they load the object with different data. Consider the following code:

//Using an int here might not be most preferred (use an enum instead), but it will suffice
pubic SomeObject getMyData(int dataType)
{
      SomeObject obj;
      switch (datatype)
      {
           case 0:
           {
                obj = SomeBLL.getDataA();
           }
           case 1:
           {
                obj = SomeBLL.getDataB();
           }
      }
      return obj;
}

With the code above, it is very tempting to initialize the “obj” reference with a default value. Before it hits the case statement, it equals “null” (null == 0 in C/C++). However, if you do initialize it with a blank object you are more than likely to run into a deceivingly existing data, even when you have passed in 3 into your function. If you use the function wrong, you’re better with your code returning a null object. Otherwise you will end up with an empty object eventually somewhere down the road and its much harder to track down why you have empty objects.

Regardless, this is the approach you want to maintain. Provided vast memory sizes and a garbage collector I have encountered this mistake even with somewhat seasoned programmers. For some it might be a tough habit to break, but we must never forget we cannot pollute the heap with empty objects; otherwise its bad programming.