Contents tagged with Code

  • What is ForkCan.com – Do you have what it takes to Share your code?

    I have worked on a project for a while now, I call it ForkCan and can be found on the following URL www.forkcan.com. ForkCan is all about sharing code in a social way. I have notice that several developers on twitter paste pointers to sites like paste-it.net to share some code with others, and to get feedback on the code. I moved this a little bit further and created a similar site BUT! I also want to make sure developers can learn from each other, discuss the code with each other and much more. There are so many great code examples shared and distributed on the web, but to find them we need to search for it and it’s spread around different blog posts, forums etc. I wanted to create one place where developers can add the code, make a repository of codes where everyone can find great code to be used in a project. I also created ForkCan to save my own “good to have” code snippets, so I can find it easy and and copy and paste it into my projects. You may wonder why I call it ForkCan? It’s because it can be used as a can of forks ;) Fork in Software development is about taking an existing code and make development on it. So with ForkCan you can share your code, someone else can make it even better by making a Fork of it. The idea of ForkCan is to help each other to be better developers. The site also is a great tool for the Copy & Pasters.. ;)

    Read more...

  • Design by Contract with Microsoft .Net Code Contract

    I have done some talks on different events and summits about Defensive Programming and Design by Contract, last time was at Cornerstone’s Developer Summit 2010. Next time will be at SweNug (Sweden .Net User Group). I decided to write a blog post about of some stuffs I was talking about.

    Users are a terrible thing! Protect your self from them

    ”Human users have a gift for doing the worst possible thing at the worst possible time.” – Michael T. Nygard, Release It!

    The kind of users Michael T. Nygard are talking about is the users of a system. We also have users that uses our code, the users I’m going to focus on is the users of our code. Me and you and another developers.

    “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler

    Good programmers also writes code that humans know how to use, good programmers also make sure software behave in a predictable manner despise inputs or user actions.

    Design by Contract

    Design by Contract (DbC) is a way for us to make a contract between us (the code writer) and the users of our code. It’s about “If you give me this, I promise to give you this”. It’s not about business validations, that is something completely different that should be part of the domain model. DbC is to make sure the users of our code uses it in a correct way, and that we can rely on the contract and write code in a way where we know that the users will follow the contract. It will make it much easier for us to write code with a contract specified. Something like the following code is something we may see often:

    public void DoSomething(Object value)
    {
       value.DoIKnowThatICanDoThis();
    }

    Where “value” can be uses directly or passed to other methods and later be used. What some of us can easily forget here is that the “value” can be “null”. We will probably not passing a null value, but someone else that uses our code maybe will do it. I think most of you (including me) have passed “null” into a method because you don’t know if the argument need to be specified to a valid value etc. I bet most of you also have got the “Null reference exception”. Sometimes this “Null reference exception” can be hard and take time to fix, because we need to search among our code to see where the “null” value was passed in etc. Wouldn’t it be much better if we can as early as possible specify that the value can’t not be null, so the users of our code also know it when the users starts to use our code, and before run time execution of the code? This is where DbC comes into the picture. We can use DbC to specify what we need, and by doing so we can rely on the contract when we write our code. So the code above can actually use the DoIKnowThatICanDoThis() method on the value object without being worried that the “value” can be null. The contract between the users of the code and us writing the code, says that the “value” can’t be null.

    Pre- and Postconditions

    When working with DbC we are specifying pre- and postconditions.  Precondition is a condition that should be met before a query or command is executed. An example of a precondition is: “The Value argument of the method can’t be null”, and we make sure the “value” isn’t null before the method is called. Postcondition is a condition that should be met when a command or query is completed, a postcondition will make sure the result is correct. An example of a postconditon is “The method will return a list with at least 1 item”.

    Commands an Quires


    When using DbC, we need to know what a Command and a Query is, because some principles that can be good to follow are based on commands and queries. A Command is something that will not return anything, like the SQL’s CREATE, UPDATE and DELETE.

    image

    There are two kinds of Commands when using DbC, the Creation commands (for example a Constructor), and Others. Others can for example be a Command to add a value to a list, remove or update a value etc.

    //Creation commands
    
    public Stack(int size)
    
    //Other commands
    
    public void Push(object value);
    
    public void Remove();

    A Query, is something that will return something, for example an Attribute, Property or a Function, like the SQL’s SELECT.

    image

    There are two kinds of Queries, the Basic Queries  (Quires that aren’t based on another queries), and the Derived Queries, queries that is based on another queries. Here is an example of queries of a Stack:

    //Basic Queries
            
    public int Count;
    
    public object this[int index] { get; }
    
    //Derived Queries
    
    //Is related to Count Query
    public bool IsEmpty()
    {
          return Count == 0;
    }

    To understand about some principles that are good to follow when using DbC, we need to know about the Commands and different Queries.

    The 6 Principles

    When working with DbC, it’s advisable to follow some principles to make it easier to define and use contracts. The following DbC principles are:

    1. Separate commands and queries.
    2. Separate basic queries from derived queries.
    3. For each derived query, write a postcondition that specifies what result will be returned, in terms of one or more basic queries.
    4. For each command, write a postcondition that specifies the value of every basic query.
    5. For every query and command, decide on a suitable precondition.
    6. Write invariants to define unchanging properties of objects.


    Before I will write about each of them I want you to now that I’m going to use .Net 4.0 Code Contract. I will in the rest of the post uses a simple Stack (Yes I know, .Net already have a Stack class) to give you the basic understanding about using DbC. A Stack is a data structure where the last item in, will be the first item out. Here is a basic implementation of a Stack where not contract is specified yet:

    public class Stack
    {
        private object[] _array;
    
        //Basic Queries
        
        public uint Count;
    
        public object this[uint index]
        {
          get { return _array[index]; }
          set { _array[index] = value; }
        }
    
        //Derived Queries
    
        //Is related to Count Query
        public bool IsEmpty()
        {
          return Count == 0;
        }
    
        //Is related to Count and this[] Query
        public object Top()
        {
          return this[Count];
        }
    
        //Creation commands
    
        public Stack(uint size)
        {
           Count = 0;
           _array = new object[size];
        }
    
        //Other commands
    
        public void Push(object value)
        {
          this[++Count] = value;
        }
    
        public void Remove()
        {
          this[Count] = null;
          Count--;
        }
    }

    Note: The Stack is implemented in a way to demonstrate the use of Code Contract in a simple way, the implementation may not look like how you would implement it, so don’t think this is the perfect Stack implementation, only used for demonstration.

    Before I will go deeper into the principles I will simply mention how we can use the .Net Code Contract.

    I mention before about pre- and postcondition, is about “Require” something and to “Ensure” something. When using Code Contract, we will use a static class called “Contract” and is located in he “System.Diagnostics.Contracts” namespace. The contract must be specified at the top or our member statement block. To specify a precondition with Code Contract we uses the Contract.Requires method, and to specify a postcondition, we uses the Contract.Ensure method. Here is an example where both a pre- and postcondition are used:

    public object Top()
    {
         Contract.Requires(Count > 0, "Stack is empty");
         Contract.Ensures(Contract.Result<object>() == this[Count]);
    
         return this[Count];
    }

    The contract above requires that the Count is greater than 0, if not we can’t get the item at the Top of a Stack. We also Ensures that the results (By using the Contract.Result method, we can specify a postcondition that will check if the value returned from a method is correct) of the Top query is equal to this[Count].

    1. Separate Commands and Queries

    When working with DbC, it’s important to separate Command and Quires. A method should either be a command that performs an Action, or returning information to the caller, not both. By asking a question the answer shouldn’t be changed. The following is an example of a Command and a Query of a Stack:

    public void Push(object value)
    
    public object Top()

     

     

     

    The Push is a command and will not return anything, just add a value to the Stack, the Top is a query to get the item at the top of the stack.

    2. Separate basic queries from derived queries


    There are two different kinds of queries,  the basic queries that doesn’t rely on another queries, and derived queries that uses a basic query. The “Separate basic queries from derived queries” principle is about about that derived queries can be specified in terms of basic queries. So this principles is more about recognizing that a query is a derived query or a basic query. It will then make is much easier to follow the other principles. The following code shows a basic query and a derived query:

    //Basic Queries
            
    public uint Count;
    
    //Derived Queries
    
    //Is related to Count Query
    public bool IsEmpty()
    {
          return Count == 0;
    }

    We can see that IsEmpty will use the Count query, and that makes the IsEmpty a Derived query.

    3. For each derived query, write a postcondition that specifies what result will be returned, in terms of one or more basic queries.

    When the derived query is recognize we can follow the 3ed principle. For each derived query, we can create a postcondition that specifies what result our derived query will return in terms of one or more basic queries. Remember that DbC is about contracts between the users of the code and us writing the code. So we can’t use demand that the users will pass in a valid value, we must also ensure that we will give the users what the users wants, when the user is following our contract. The IsEmpty query of the Stack will use a Count query and that will make the IsEmpty a Derived query, so we should now write a postcondition that specified what results will be returned, in terms of using a basic query and in this case the Count query,

    //Basic Queries
            
    public uint Count;
    
    //Derived Queries
    
    public bool IsEmpty()
    {
        Contract.Ensures(Contract.Result<bool>() == (Count == 0));
    
        return Count == 0;
    }

    The Contract.Ensures is used to create a postcondition. The above code will make sure that the results of the IsEmpty (by using the Contract.Result to get the result of the IsEmpty method) is correct, that will say that the IsEmpty will be either true or false based on Count is equal to 0 or not. The postcondition are using a basic query, so the IsEmpty is now following the 3ed principle. We also have another Derived Query, the Top query, it will also need a postcondition and it uses all basic queries. The Result of the Top method must be the same value as the this[] query returns.

    //Basic Queries
    
    public uint Count;
    
    public object this[uint index]
    {
         get  { return _array[index]; }
         set  { _array[index] = value; }
    }
    
    //Derived Queries
    
    //Is related to Count and this[] Query
    public object Top()
    {
         Contract.Ensures(Contract.Result<object>() == this[Count]);
    
          return this[Count];
    }

    4. For each command, write a postcondition that specifies the value of every basic query.

    For each command we will create a postconditon that specifies the value of basic queries. If we look at the Stack implementation we will have three Commands, one Creation command, the Constructor, and two others commands, Push and Remove. Those commands need a postcondition and they should include basic query to follow the 4th principle.

    //Creation commands
    
    public Stack(uint size)
    {
    Contract.Ensures(Count == 0); Count = 0; _array = new object[size]; } //Other commands public void Push(object value) { Contract.Ensures(Count == Contract.OldValue<uint>(Count) + 1); Contract.Ensures(this[Count] == value); this[++Count] = value; } public void Remove() { Contract.Ensures(Count == Contract.OldValue<uint>(Count) - 1); this[Count] = null; Count--; }

    As you can see the Create command will Ensures that Count will be 0 when the Stack is created, when a Stack is created there shouldn’t be any items in the stack. The Push command will take a value and put it into the Stack, when an item is pushed into the Stack, the Count need to be increased to know the number of items added to the Stack, and we must also make sure the item is really added to the Stack. The postconditon of the Push method will make sure the that old value of the Count (by using the Contract.OldValue we can get the value a Query has before the method is called)  plus 1 will be equal to the Count query, this is the way we can ensure that the Push will increase the Count with one. We also make sure the this[] query will now contain the item we pushed into the Stack. The Remove method must make sure the Count is decreased by one when the top item is removed from the Stack. The Commands is now following the 4th principle, where each command now have a postcondition that used the value of basic queries.

    Note: The principle says every basic Query, the Remove only used one Query the Count, it’s because this command can’t use the this[] query because an item is removed, so the only way to make sure an item is removed is to just use the Count query, so the Remove will still follow the principle.

    5. For every query and command, decide on a suitable precondition.

    We have now focused only on postcondition, now time for some preconditons. The 5th principle is about deciding a suitable preconditon for every query and command. If we starts to look at one of our basic queries (will not go through all Queries and commands here, just some of them) the this[] query, we can’t pass an index that is lower then 1 (.Net arrays and list are zero based, but not the stack in this blog post ;)) and the index can’t be lesser than the number of items in the stack. So here we will need a preconditon.

    public object this[uint index]
    {
         get
         {
             Contract.Requires(index >= 1);
             Contract.Requires(index <= Count);
    
              return _array[index];
          }
    }

    Think about the Contract as an documentation about how to use the code in a correct way, so if the contract could be specified elsewhere (not part of the method body), we could simply write “return _array[index]” and there is no need to check if index is greater or lesser than Count, because that is specified in a “contract”. The implementation of Code Contract, requires that the contract is specified in the code. As a developer I would rather have this contract elsewhere (Like Spec#) or implemented in a way Eiffel uses it as part of the language.

    Now when we have looked at one Query, we can also look at one command, the Remove command (You can see the whole implementation of the Stack at the end of this blog post, where precondition is added to more queries and commands then what I’m going to show in this section). We can only Remove an item if the Count is greater than 0. So we can write a precondition that will require that Count must be greater than 0.

    public void Remove()
    {
       Contract.Requires(Count > 0);
       Contract.Ensures(Count == Contract.OldValue<uint>(Count) - 1);
    
       this[Count] = null;
       Count--;
    }

    6. Write invariants to define unchanging properties of objects.

    The last principle is about making sure the object are feeling great! This is done by using invariants. When using Code Contract we can specify invariants by adding a method with the attribute ContractInvariantMethod, the method must be private or public and can only contains calls to Contract.Invariant. To make sure the Stack feels great, the Stack must have 0 or more items, the Count can’t never be a negative value to make sure each command and queries can be used of the Stack. Here is our invariant for the Stack object:


    [ContractInvariantMethod] private void ObjectInvariant() { Contract.Invariant(Count >= 0); }

    Note: The ObjectInvariant method will be called every time after a Query or Commands is called.

    Here is the full example using Code Contract:

    public class Stack
    {
       private object[] _array;
    
       //Basic Queries
    
       public uint Count;
    
       public object this[uint index]
       {
         get
         {
            Contract.Requires(index >= 1);
            Contract.Requires(index <= Count);

    return _array[index]; } set { Contract.Requires(index >= 1); Contract.Requires(index <= Count); _array[index] = value; } } //Derived Queries //Is related to Count Query public bool IsEmpty() { Contract.Ensures(Contract.Result<bool>() == (Count == 0)); return Count == 0; } //Is related to Count and this[] Query public object Top() { Contract.Requires(Count > 0, "Stack is empty"); Contract.Ensures(Contract.Result<object>() == this[Count]); return this[Count]; } //Creation commands
    public Stack(uint size) { Contract.Requires(size > 0); Contract.Ensures(Count == 0); Count = 0; _array = new object[size]; } //Other commands public void Push(object value) { Contract.Requires(value != null); Contract.Ensures(Count == Contract.OldValue<uint>(Count) + 1); Contract.Ensures(this[Count] == value); this[++Count] = value; } public void Remove() { Contract.Requires(Count > 0); Contract.Ensures(Count == Contract.OldValue<uint>(Count) - 1); this[Count] = null; Count--; } [ContractInvariantMethod] private void ObjectInvariant() { Contract.Invariant(Count >= 0); } }


    Summary


    By using Design By Contract we can make sure the users are using our code in a correct way, and we must also make sure the users will get the expected results when they uses our code. This can be done by specifying contracts. To make it easy to use Design By Contract, some principles may be good to follow like the separation of commands an queries. With .Net 4.0 we can use the Code Contract feature to specify contracts.

    Read more...

  • Is it important to write good code?

    The last three weeks I have visit several companies and talked about writing good code. It's amazing to see how different developer thinks about writing good code. Here are some comments when I asked if it's important to write good code:

    - I don't care as long as it works it's fine.

    - I don't have the time to write good code.

    - The customer don't see the code, so as long as the application works, I'm satisfied.

    - Most customers want to pay as little as possible for as much as possible, and to deliver it in time, I make sure the code only works.

    - I know that we can use refactoring to make the code more readable, but we don't have the time to do it.

    When I asked about reading other peoples code and also maintain it, most people answer:

    - It's not easy all the time

    - It's horrible and hard to understand what the code does.


    That are some of the results when developers only write code to make stuff works and write code for them self and don't care to write code for other humans to understand.

    Here is an example which I use during my presentation, it's a method which will calculate the price for renting a movie, the price differs between different type of customers and also different types of movies.

    public class MovieRenter
    {
        public double CalculatePrice(string customerType, string movieType)
        {
            if (customerType == "VIC" && movieType == "Transfer")
                return 20;
            else if (customerType == "Regular" && movieType == "Transfer")
                return 30;
            else if (customerType == "VIC" && movieType == "Normal")
                return 10;
            else if (customerType == "Regular" && movieType == "Normal")
                return 20;
            else
                return 50;
        }
    }
     
    MovieRenter movieRenter = new MovieRenter();
    double price = movieRenter.CalculatePrice("VIC", "Transfer");


    I asked the attendance if the method looks ok, I got surprised when the answer was "Yes". Some one told me, well I should have used enumeration and switch statement instead of strings and if statements. I did some refactoring and use an enumeration and switch statement instead with the help of the attendance, the result was the following code:

    public class MovieRenter
    {
           public double CalculatePrice(CustomerType customerType, MovieType movieType)
           {
               switch (customerType)
               {
                   case CustomerType.VIC:
                       switch (movieType)
                       {
                           case MovieType.Transfer:
                               return 20;
                           case MovieType.Normal:
                               return 10;
                           default:
                               return 20;
                       }
                       break;
                   case CustomerType.Regular:
                       switch (movieType)
                       {
                           case MovieType.Transfer:
                               return 30;
                           case MovieType.Normal:
                               return 20;
                           default:
                               return 30;
                       }
                       break;
                   default:
                       return 30;
               }
    }
    
    public enum MovieType
    {
        Transfer,
        Normal
    }
    
    public enum CustomerType
    {
        VIC,
        Regular
    }
    MovieRenter movieRenter = new MovieRenter();
    double price = movieRenter.CalculatePrice(CustomerType.VIC, MovieType.Transfer);

    When I asked if we can do it even better, someone wanted to split the switch statement inside of the case CustomerType.VIC into a separate method, the same with the switch statement in the case CustomerType.Regular. I did that changes to the code and everyone was happy. The problem with conditional statement in code, is that they can be hard to maintain, if I need to add a new kind of movie and customer, I need to add more conditions to my code. Sooner or later it will be difficult to maintain. So one thing we can do, is to replace a conditional statement with polymorphism.

    If we look at the code, we can see that we have a customer and a movie to which a customer wants to rent. So we create two entities, one Customer entity and one Movie entity. We can then add a Rebate property to the Customer class and a Price property to the Move class. A movie have the price, and Customer have a rebate. Now when we have a Customer and a Movie, we need to make sure we also have the different type of Customers and Movie represented as classes, we don't want to add a CustomerType or MovieType property to the Customer and Movie class, if we do so, we will en up with a new conditional statement. So we create a new class called CustomerVIC which will inherit from Customer, and we create a MovieTransfer class which inherits from the Movie class. We let the Customer class represents a regular customer and the Movie class as normal movie. Because a VIC Customer should have it's own Rebate and a Transfer Movie should have it's own price, we make sure the base classes properties are virtual so we can override them in our sub classes.

    public class Customer
    {
        public virtual double Rebate
        {
           get { return 0; }
        }
    }
    
    public class CustomerVIC : Customer
    {
        public override double Rebate
        {
           get { return 10;  }
        }
    }
    
    public class Movie
    {
        public virtual double Price
        {
           get { return 20; }
        }
    }
    
    public class MovieTransfer : Movie
    {
       public virtual double Price
       {
          get { return 30; }
       }
    }

    If we compare a normal customer with a VIC, we can see that a VIC will have 10 in rebate. So we make sure the CustomerVIC class Rebate property returns the price a VIC Customer should have in Rebate over a regular customer. The price of a Transfer movie is 30 and the price of a normal movie is 20.

    Now when we have created our Customers and Movies, we can change the MovieRenter's CalculatePrice method, which in this case should take a Customer as an argument and a Movie.

    public class MovieRenter
    {
       public double CalculatePrice(Customer customer, Movie movie)
       {
          return movie.Price - customer.Rebate;
       }
    }

    CustomerVIC vicCustomer = new CustomerVIC();
    MovieTransfer transferMovie = new MovieTransfer();
              
    MovieRenter movieRenter = new MovieRenter();
    double price = movieRenter.CalculatePrice(vicCustomer, transferMovie);


    So by using polymorphism and more Object Oriented Programming over a normal functional programming, we can remove conditional statements. If I need a new type of Customer or Movie, I just create a new class and inherits from its base class and override the Rebate and Price property. Anyone have another suggestion of making the first code example better, and do you think it's important to make it better even if it works?

    What do you think is most important when it comes to writing code?

    What is the most common thing you think a developers are doing wrong when they write code?

    Read more...

  • Region is an excuse for hiding large files

    Often when I take a look at sample code there are a lot of regions. I need to open them all the time, it really start to make me crazy. Why does people even use Region in their code, what's the point of hiding code? I think it's only an excuse to hide code because of a too large file. What do you think?

    Read more...

  • Lazy Developers?

    When I was out with my new dog (I Chihuahua, wonderful dog), I was thinking about Defensive Programming and Design by Contract. I like to do some refactoring and help other people to write cleaner code etc,  not that I’m an expert in the area but I think most of developers can see stuff that blinds other developers during development. I remember a scenario that made me kind of mad, I often notice that some developers doesn’t even care to validate arguments on public API or other methods, they assume the caller pass in the right values. When I started to develop apps, I didn’t validate arguments (In know I was a noob ;)). But since I started to do validation, it reduces the number of bugs in my code, and the difference was big. But that isn’t the only reason I like to do validation. Another  reason is because the caller of the method should know if they have passed a wrong value, there are of course some other reasons also, but the main reason is make sure the caller or the method pass in the correct value, and if they do, they will get what they want.

    I notice that several developers today don’t care about validation, I ask them why and they all gave me the same argument “Why should I, it will only make me add more code and it’s boring to write code that checks values”. Can this be summarized that some developers are lazy?

    Maybe I’m stupid because I get mad when I hear that kind of argument, but I’m special ;)

    Read more...