Coding Stories

Parameter names

public void class Person 
{
  …
  public bool IsSimilar(Person person2) { … }
}

What do you think about the name of parameter name ‘person2’. Names of parameters, fields like xxx1, xxx2, xxx3 are not the best choice. In this case maybe a better name would be ‘otherPerson’.
Magic numbers

public void ValidatePhone(string phoneNumber)
{
  … phoneNumber.Contains(“40”);  
}

The “40” don’t’ say nothing to a reader. What this value represent, why is used and so on. If this value is used in only one place you should at least extract a constant in the body of method. In the case the same value is used in different places of the application, you should put this constraints in a common place.

Property names and enums

public class InvitesFilter
{
  public bool SendByLetter { get; set; }
  public bool SendBySms { get; set; }
  public bool SendByMail { get; set; }
  …
}

First of all, do we really need the ‘SendBy’ prefix? We already know that it is in invitation filter. You cannot send an invitation by receiving it.
Also, if we look closely, this should not be a class. This is clear an enum. If you need to support more than one value set, than you should use the ‘Flag’ attribute.

[Flag]
public void InvitesFilter
{
  Letter = 1,
  Sms = 2,
  Mail = 4
}

Don’t forget to set numeric values to enum items that are power of 2.
Common component (assembly)
It is great to have a common component. But try to not mix the common items from UI with the rest of the classes that are common. For example we don’t want to have in this component all the classes plus some XAML. Even if the XAML is something that is used in 2,3 components, you should create a different component for this (xxx.UI.Common).

Property name
xxxCallbackArgs.IsUserCancel – this property is set to true in the moment when the given action was canceled by the user. The name of the property doesn’t transmit the same thing. If I don’t know the implementation, I would say that this property would tell me if the user was canceled. A better name would be HasCancelledByUser or IsCancelledByUser.

Singleton and static properties
There are a lot of places where I usually see something like this:

public class Foo
{
  private Foo _instance;

  public static Foo Instance
  {
    if ( _instance == null )
    {
      _instance = new Foo();
    }
  }
}

If we are in a multi-thread application, there can be a situation when two threads could be in the same time in the IF. A lock should be used after the IF check and another check need to be made – because during the period when we wait the lock another thread can create a new instance.

public class Foo
{
  private Foo _instance;
  private object _padLock = new Object();
  
  public static Foo Instance
  {
    if ( _instance == null )
    {
      lock( _padLock )
      {
        if ( _instance == null )
        {
          _instance = new Foo();
        }
    }
  }
}
}

Single Responsibility Principle
The User class has a property field. This property need to be encrypted, so the class ends up with two private methods used to encrypt and decrypt the password. Do you thing that we should have the implementation of this class defined in the User class?
I would say NO. We should have a different class that can encrypt and decrypt. Not only will the User class manage only the user information, but the encryption algorithm will be easier to test.