Const vs Readonly Static / Named and Optional Arguments (.NET)

The machine does not isolate man from the great problems of nature but plunges him more deeply into them.

Antoine de Saint-Exupery 

What is common in constants and named parameters?

1. Const vs Readonly Static 

What is better to use DebitorNumberConst or DebitorNumberStatic?

public class SomeClass{

   public const string DebitorNumberConst = "0000123";
   
   public readonly static string DebitorNumberStatic = "0000123";
}

The difference is that usage

// use constant
Console.Writeline(SomeClass.DebitorNumberConst);
// use static
Console.Writeline(SomeClass.DebitorNumberStatic);

will be compiled to

// use constant
Console.Writeline("0000123");
// use static
Console.Writeline(SomeClass.DebitorNumberStatic);

Constant is just burned into DLL, while static variable is a reference to string. And so what? This is very bad sign if public constant is referenced from another library. In all referenced libraries constant will be burned too. And to update program in case of changing the constant now we need recompile all libraries that has reference to the constant. And users should download all this libraries for the case of an update.

Rule of thumb: Mostly use Static Readonly fields,  and Constants for private or internal fields.

2. Named and Optional Arguments 

In .NET 4 there appeared so called named and default arguments

public void Method(string first = "Default Value", int second = "-1"){...}

And now there are several variants to call the method:

Method(); // first = "Default Value", second = "-1"
Method(second: 5); // first = "Default Value", second = "5"
...

The problem is the same: calling named argument Method(second: 5) is burned inside DLL. If someone  will rename second -> newArg and do not recompile referenced DLLs there will be exception.

Old libraries historically has methods with lots of parameters that are not usually called (WinAPI, COM), for example, previous converter in MS Office:

range.ConvertToTable(ref separator, ref missing, ref missing,
    ref missing, ref missing, ref missing, ref missing,
    ref missing, ref missing, ref missing, ref missing,
    ref missing, ref missing, ref missing, ref missing,
    ref missing);

And now with new version with optional parameters we can write

range.ConvertToTable(Separator: ",");

And this is the real reason why named and optional parameters were introduced in .NET!

Rule of thumb: Do not use named and optional parameters if there is no need in support for old libraries with endless parameters; or if you sure that recompiling all libraries for small change will not hurt you clients/products.

On the other hand named parameters can be very useful for reading:

MakeMyDay(true, true, 5);

What does it really mean? :)
With name arguments it can be clarified:

MakeMyDay(isFunny: true, isCoding: true, partyHours: 5);