Greetings! Long time no blogging!

The usual excuses apply: no time, too much work, to tired to think about anything but work…

This post will hopefully make my readers smile, as I am going to list my favorite bits of advice on programming I have taken from “The Elements of C# Style” by K.Baldwin, A.Gray and T. Misfeldt. This book makes for a short and wonderful read, and in my opinion should be re-read on regular basis by all practitioners. It covers naming, design, documentation, the programming language and packaging and release. The book is full or “do’s” and “don’ts”, and it is the “don’ts” that I  smile at because, admittedly, I have done all of them at some point in the past…

Here  are ten, in the “smiley” order:

1. Do It Right the First Time: the authors advice to apply this rule to any code one writes, not just what is designed for production. Probably the best advice I have ever come across, and the one I seldom practice. Quite often I would begin by simply trying a few things out, getting the code to work and then never coming back to clean it up and make it presentable.
2. Adhere to the Principle of Least Astonishment: this advice is one of my favorite! The authors write that simplicity and clarity must be preferred over complexity and unpredictability.
3. Keep Your Comments and Code Synchronized: this one is followed by a quote by Norm Schryer: “When the code and the comments disagree, both are probably wrong.”
4. Recognize the Cost of Reuse: reuse is often held up as the holy grail, however, truly re-usable code is difficult and time consuming. In addition, it increases code dependency and, sometimes, complexity.
5. Separate Distinct Programming Layers: as this creates a flexible and maintainable architecture. Personally, I should be remembering this one more often…
6. Reuse Objects to Avoid Reallocation: this piece of advice is from the efficiency chapter. The idea is to cache and reuse frequently created objects with limited lifespan. Use accessor methods (get) rather than constructors.
7. Avoid the Use of End-line Comments: according to the authors these interfere with the overall structure of the code. One-line comments should be placed on separate line. I agree, will remember this one in the future.
8. Do Not Use try…throw…catch to Manage Control Flow: one should use exceptions handling mechanism to handle exceptional conditions. Except for serious failures there should be a way to continue execution (and notifying the users or logging errors).
9. Organize Source Code into Regions: this one really aids in improving readability and I often forget it!
10. Consider Using Code-checking Software to Enforce Coding Standards: it is true that tools like FxCop are very useful and one can learn more about the language by simply following its suggestions! However, sometimes I turn FxCop off because I find that I don’t like to see most of my code highlighted in red!

So, how many times did you smile?

Hello,

In this post I would like to do something really simple and show you how to implement an IEnumerable on a custom collection. Some of you may ask why would I need to implement this interface on my custom collection? Usually the answer has to do with using the foreach loop, which, without the IEnumerable interface won’t be available to the collection users.

Ok, so, let’s say you have a simple Loan class with the following definition:

internal sealed class Loan
    {
        public Loan(decimal rate, DateTime maturity, decimal amount)
        {
            if (rate > 0 && maturity > DateTime.Now && amount > 0)
            {
                this.rate = rate;
                this.maturity = maturity;
                this.amount = amount;
            }
        }

        public decimal Rate { get { return rate; } }
        public DateTime Maturity { get { return maturity; } }
        public decimal Amount { get { return amount; } }

        private decimal rate;
        private DateTime maturity;
        private decimal amount;
    }

You created the above Loan class to be able to see the total amount you need to repay by some future date. There is really nothing wrong with simply having an array of Loans (e.g. one for your car, another for your house) and using the foreach on the array. In other words, something like this:

class EntryPoint
    {
        static void Main(string[] args)
        {
            decimal totalToRepay = 0;
            Loan [] loans =  
            { 
                new Loan((decimal)0.03, DateTime.Parse("19/04/2016"), (decimal)15000),
                new Loan((decimal)0.018, DateTime.Parse("19/04/2016"), (decimal)260000)
            };

            foreach (Loan l in loans)
                totalToRepay += ((l.Maturity - DateTime.Now).Days / 365) * l.Rate * l.Amount + l.Amount;

            Console.WriteLine("{0} {1,2:C}", "You will need to repay an amount of ", totalToRepay);
            Console.ReadLine();

        }
    }

The above works for simple single-threaded use. However, as soon as you introduce a possibility of one thread updating the loans array while another thread is iterating over it, you need to implement some kind of synchronization mechanism. The loans array inherits the ICollection implementation from the Collections class. This interface has a SyncRoot property which allows to lock the variable. At this point you begin to realise that a simple array of loans may need to evolve into a custom collection with added synchronization benefit. You go ahead and implement a collection of loans class:

internal sealed class LoanCollection: IEnumerable
    {
        public LoanCollection(Loan[] loanArray)
        {
            loanCol = new Loan[loanArray.Length];
            for (int i=0; i< loanArray.Length; i++)
            {
                loanCol[i] = loanArray[i];
            }
        }

       public IEnumerator GetEnumerator()
       {
           lock (loanCol.SyncRoot)
           {
               for (int i = 0; i < loanCol.Length; i++)
                   yield return loanCol[i];
           }
       }

       private readonly Loan[] loanCol;
    }

Note how simple it is to synchronize with the lock statement. C# compiler will be busy expanding this statement into a proper Monitor.Enter and Monitor.Exit block. Also note that for a non-generic IEnumerable we only need to implement the GetEnumerator method. So, are we done here? Not quite, as I always like to point out alternative and sometimes simpler methods for doing the same things. Instead of separating the enumeration and the synchronization, we could attempt to get both of these features in one go. To do this, we can inherit from a thread-safe System.Collections.Concurrent.ConcurrentBag and simplify the LoanCollection class a little bit. The ConcurrentBag is a generic collection, so we will restrict the type to Loan class only:

internal sealed class LoanCollectionSync<T> : System.Collections.Concurrent.ConcurrentBag<T> where T : Loan
    {
        public LoanCollectionSync(T[] loanArray)
        {
            foreach (T l in loanArray)
            {
                Add(l);
            }
        }
    }

How cool is that? Not only we get the IEnumerable from the ConcurrentBag, but the collection is now thread-safe as well! There is a special TryPeek method in the ConcurrentBag that can be used to iterate over the collections. The built-in enumerator is also thread-safe (i.e. represents a snapshot of a collection in the moment in time before any updates), so, we can still use the same iteration approach as before:

LoanCollectionSync<Loan> syncLoans = new LoanCollectionSync<Loan>(loans);

   foreach (Loan l in syncLoans)
      totalToRepay += ((l.Maturity - DateTime.Now).Days / 365) * l.Rate * l.Amount + l.Amount;
   
   Console.WriteLine("{0} {1}", "You will need to repay an amount of ", totalToRepay.ToString("C"));
   Console.ReadLine();

Thanks for reading and have a nice day!

Greetings to my blog readers!

Have you ever worked on an application that required accepting a password or other sensitive data from a user? If yes, then how did you handle the password retrieval and storage? Since most passwords, or other sensitive data like national insurance number, can contain alphanumeric values, it is sensible to treat them as strings. In C#, string or String is an immutable reference type with value-like semantics. This means that passing a string as a parameter to a method that locally modifies its value results in locally changed copy, with the original string unchanged. One approach to handling passwords can be to accept user’s input as a string, encrypt or hash it, and then store away the encrypted value. The unencrypted string would be collected by the Garbage Collector (GC). The problem with this approach is that until the GC gets around to reclaim the managed memory, the password exists in its unencrypted form in the process’s heap. This may present a security gap.

C# offers a very useful class for sensitive data processing. The class is SecureString. It allows one to allocate a block of unmanaged memory and encrypt its content at initialization. The class has no built-in methods for decrypting the string back, which makes it more secure. Let’s look at an example:

using System;
using System.Security;

namespace MySecureString
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Please enter your password:");

            // SecureString implements IDisposable
            using (SecureString password = new SecureString())
            { 
                ConsoleKeyInfo nextKey = Console.ReadKey(true);
                while (nextKey.Key != ConsoleKey.Enter)
                {
                    password.AppendChar(nextKey.KeyChar);
                    Console.Write("*");
                    nextKey = Console.ReadKey(true);
                }

                // makes the password immutable
                password.MakeReadOnly();
                // ...
            }
        }
    }
}

In the example code above we are creating an instance of SecureString and initializing it with the user’s input. Note that I wrapped the example in the using block to avoid unmanaged memory leak. A call to MakeReadOnly ensures that the encrypted password cannot be modified, which SecureString class achieves by maintaining an internal boolean flag.

Ok, so how does this actually work? The data encryption is a process of several stages. SecureString class makes a call to the native Win32 SystemFunction040() method passing it the pointer to the memory buffer with user’s input, its length and the CRYPTPROTECTMEMORY_SAME_PROCESS flag. This method encrypts the memory in place, meaning that the memory buffer is overridden with encrypted content. The flag sets the rules on which process is allowed to decrypt this memory content (e.g. the current process only). The encryption is done according to the Windows Data Protection API (DPAPI), which offers password-based data protection service. In short, the data protections is done using a MasterKey, derived with the help of user’s system logon password, and a session key. An additional ‘secret’ word can be supplied to strengthen security. Only the MasterKey is stored in the user’s profile, to allow for later decryption of the data. By default, MasterKey is stored in the user’s profile folder, which is %AppData%/Microsoft/Protect. Also, by default, the key expires every three months, after which it gets re-generated.

Since SecureString class does not expose any methods for decryption, a call to the Windows native SecureStringToBSTR method has to be made. Here is an example of how to decrypt the password:

IntPtr bstr = IntPtr.Zero;
// it is important to free the memory pointed to by IntPtr
// therefor we use try/finally block
try
{
    bstr = System.Runtime.InteropServices.Marshal.SecureStringToBSTR(password);
    Console.WriteLine("Original password is: " + System.Runtime.InteropServices.Marshal.PtrToStringUni(bstr));
}
finally
{
    System.Runtime.InteropServices.Marshal.ZeroFreeBSTR(bstr);
}

Hope this post has at least triggered your curiosity about DPAPI. Thank you for reading!

In C# a value of null can be assigned to reference types, or more specifically to nullable types. When a reference is set to null it means it is not pointing to any object. A value of null is perfectly legal for reference types.

C# is a strongly typed language and the concept of reference and value types is at the core of the language semantics. For example it is not possible to override the ?? operator because it would allow the developers to potentially break the boundary between reference and value types. In case you are asking what is this ‘??’ operator, it is called the null-coalescing operator, and it allows for a short-hand comparison and assignment like this:

 string firstString = default(string);

 string secondString = firstString ?? "apples";

In the above, secondString is assigned to “apples” because the ?? operator works like this: if firstString is null, assign to “apples”, otherwise, assign to firstString. Note that if instead of “apples” I had some null-valued variable or just null, the result of this assignment would be null.

If you have encountered the null-coalescing operator before, I bet you did not know it can be nested! For example, the below code is legal. Can you work out what the value of thirdString will be?

 string firstString = default(string);

 string secondString = firstString ?? "apples";

 string thirdString = firstString ??
                      secondString ??
                      "pears";

The value of thirdString will be set to “apples” because the nested null-coalescing works like nested if-else. So, the above can be read like this: if firstString is not null assign to its value, otherwise, if secondString is not null assign to its value, else assign to “pears”.

Value types cannot be used in null-coalescing. This is because it is not legal to assign a null to a value type. For example, something like this will never compile:

 int firstInt = null;

In C#, an int is the same as Int32 and is internally represented as a struct, which is a value type. There is another special struct called System.Nullable. It is special because it can represent any of the C# value types, plus, it can take on the null value. Can you already see where I am going with this? This means that it is possible to use the null-coalescing with value types if we make them nullable. To make a value type nullable one should use ? operator. For example:

 
 int? firstInt = null;
 int? secondInt = firstInt ?? 3;

firstInt is now a nullable type and can be used with the null-coalescing operator. Is there any boxing overhead once we make a value type nullable? No, there is not. The firstInt and secondInt integers are still value types, i.e. they are still structs. At no point they get boxed into objects. As a matter of fact, a compiler translates ?? operator into a set of load and Brtrtue instructions. A call to get_HasValue()
is made on firstInt, which returns false. Brtrue instruction see this and transfers the control to the load and assignment to 3.

In one of my older blogs I have written a short tutorial on delegates and events.
I wrote the blog after reviewing the concepts of delegates and events and wanted to create a hopefully simplified version of the material for my blog readers.

Recently I have come across another C# class that is a wrapper on a delegate that does not return any values. This class is called Action and one can read more about it on the MSDN site.

Action class simplifies creation of delegates that do not need to return a value. Several built-in features of C# use Action class. One of these is Parallel.ForEach() which can be used to loop through an enumerable collection in a parallel fashion. A call to ForEach would accepts two arguments: the IEnumerable collection and Action delegate (perhaps anonymous) to perform on each item in the collection. Here is a quick example code that prints out the content of intList in asynchronous manner:

List<int> intList = new List<int>() {1,2,3,4,5};
Parallel.ForEach(intList, (e, state, i) => Console.WriteLine(e.ToString()));

If you examine the IL code for the above, you will see that an instance of System.Action class encapsulates the anonymous method.

Thinking about the Action class got me thinking if I could rewrite my previous delegate tutorial with a simplified syntax. This is what I have come up with:

using System;
using System.Threading.Tasks;
using System.Collections;

namespace ActionsAndEvents
{
    public class ListWithEightEvent : ArrayList
    {
        // event on an action         
        public event Action EnteredEight;   

        // invoke event after an addition of an 8
        public override int Add(object value)                            
        {
            int i = base.Add(value);
            if (EnteredEight != null && value.ToString() == "8")
                EnteredEight();                                          
            return i;
        }
    }

    class Test
    {
        public static void Main()
        {
            ListWithEightEvent list = new ListWithEightEvent();
            // register the event with AddedEight method                          
            list.EnteredEight += AddedEight;

            string input;
            Console.WriteLine("Keep entering numbers. Enter 'x' to stop.");
            do
            {
                input = Console.ReadLine();
                list.Add(input);
            } while (input != "x");

        }

        // This will be called whenever the list receives an 8
        public static void AddedEight()
        {
            Console.WriteLine("You have entered an 8!");
        }
    }
}

To me, the above code is cleaner and simpler than the earlier delegate and EventHandler version.