Using a ternary operator (or short hand IF) in a LINQ statement

Today I have discovered that I need to use an if statement if statement inside my LINQ statement. It went something like this

Select an item from a list that holds codes for Blah objects. These objects hold two display texts for an associated code; a long text and a short text. If the long text is equal to a double quote mark, then display the short text

To clarify a little bit, I have list of objects for a drop down. The short text is displayed in the drop down from which, on select, I obtain a value which is a short hand code, ie. “SMNG” stands for “Something”. This way I can store the short hand code with the data record and store the associated information in a different table. When I need to figure out what the short or long text for “SMNG” is, I can just get it from the different table. If I need to change the wording to the short text for instance from “Something” to “Other”, I do not need to modify anything but the database table.

Ok, back to the code. A LINQ statement as far as I know does not allow you to hold the full if statement syntax. However, thankfully in C# they have included something called the Ternary Operator, or the “?:” operator combination (written as “operator” just like a “Do […] While is an “operator”) inherited from the C/C++ ways. In my case, just the statement would look something like:

longText = longText == "\"" ? c.shortText : c.longText;

Great! Now that we know the control statement that we want to return, we can do something like this:

(from c in codeList
where c.code == _status
select c.longText== "\"" ? c.shortText : c.longText).Single();

This LINQ returns a single item that I am looking for using my code. I could remove the “where” clause and just update them all but I decided to do it on a single basis.

Why this and not a “normal” if statement?

It has to do with how the LINQ statement sees it and the way the compiler sees it. This is not a real “If” if you will, but rather one that spits out a variable. A “normal” if statement does not return anything, its just a conditional. (Note: I am NOT saying that a ternary statement is a function, but rather a syntactical trick). In other words, to LINQ this just looks like a variable, nothing more, just as though I was passing in a normal variable. If I put a “normal” if statement in there, it has a few issues:

  • If statements have no return statements, it means that the compiler cannot guarantee something will be passed back in a select or a return
  • For raw LINQ, it is not syntactically convenient to implement something like a full if statements

Reguardless, if you find a way to do normal if statements in LINQ, please let me know!

I am currently a programmer on this team. We are using Unity3D so look out for posts about how to do things in Unity3D!

Fresh Cut Fusion

We’re a team of DePaul Seniors working on our Capstone Project.

Fresh Cut Fusion maintains a studio culture of “fun work”. While we are working together in a structured business format, we are all gamers. We play for the challenge, for the fun, and eventually, for the reward. Cooperation with team members is the key to every playthrough, and no one person is responsible for success or failure. We drive ourselves to further our skills and abilities and to level up our knowledge. We will accept that mistakes will be made; but we will learn from our mistakes, and become stronger with our own Fresh Cut Fusion of ideas. As we are gamers, so are we developers.

Our members are:

James Becker – Programmer

Thomas S. Field – Producer and Designer, and part-time artist

Serguei Fedorov – Programmer

Max O’Neill – Programmer

Ren Wilkey – 3D Artist

David Vicente –…

View original post 63 more words

C#: Using the Get/Set Effectively In Properties

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

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

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.