Effective C # principle 2: Choose ReadOnly instead of const for your constants

For constants, C # has two different versions: the Run-time and compile-time quantities.

Because they behave differently, it can damage program performance or make mistakes when you use them incorrectly.

Two evils take its light, and when we have to choose one, we prefer a slow but correct one, not the one that runs faster but has the wrong. For this reason, you should choose to run a regular amount instead of compiling a regular amount of time (the hidden explanation here is that compiling is often more efficient, but there may be errors).

Compilation is often faster and more direct, but is far less maintainable than running at all times. The compile-time retention is maintained to meet those performance-required and as the program runs out of time, its values never change. This shows that the compilation times are not to be used by C #, but there are still reservations about performance issues.

You can use the keyword readonly to declare (declare) a running constant, and the compile-time constant is declared with the keyword Const.

//Compile time constant:
public cocnst int _Millennium = 2000;
//Runtime constant:
public static readonly int _ThisYear = 2007;//

(The original 2004)

The difference between the compile-time and the running times is shown in how to access them.

A compile-time amount is directly replaced by the value in the target code. The following code:

if (myDateTime.Year == _Millennium)

is compiled into the exact same IL code as the code written below:

if(myDateTime.Year == 2000)

The value of the Run-time constant is determined at run time. When you refer to a read-only constant (read-only) IL will refer you to a variable that runs on a regular scale instead of using that value directly.

When you use one of these constants arbitrarily, these distinctions are expressed in a number of limitations. Compile-time constants can only be base types (primitive types) (built-in integral and floating-poing types), enumerations, or strings. These are the types that you can only assign to run times at initialization time. These basic classes are data types that can be replaced directly by the compiler with real values when compiling the IL code. The following code block (construct) cannot be compiled. You cannot initialize a compilation constant with the new operator, even if the data type is a value type.

Does not complie, use ReadOnly instead:

Private Const DateTime _classcreation = new DateTime (2000,1,1,0,0,0);

(DateTime is a value-type data, but the code above, because of the new operator, cannot compile without the compiler being able to determine what actual value the concrete object should be replaced with.) )

Compilation times are limited to numbers and strings. Read-only variables, which are run times, are not modified when constructors (constructor) are executed. But read-only variables are all different because they are assigned at run time. You have greater scalability when you are using a running constant. One thing to be aware of is that the Run-time amount can be any type of data. And you have to initialize them in the constructor, or you can do it with any of the initialization functions. You can add a read-only variable for a datetime structure (--a Run-time constant), but you can't add a datetime structure (compile-time) constants.

You can specify each instance (constant) as read-only to hold different values for each instance of the class. Unlike compilation times, it can only be static.

To put it simply, a run-time quantity can be an instance member of a class, or a static member of a type, and a compile-time constant can only be a static member, and therefore similar: the code for a static const string m_name is not compiled. )

The most important difference between read-only data is that they determine the value at run time. When you use a read-only variable, IL generates a reference to a read-only variable for you, rather than generating a numeric value directly. Over time, this distinction has a profound potential impact on (System) maintenance.

The IL code generated by the compile-time constant is the same as the IL generated when the value is used directly, even when it comes to cross assemblies: the compile-time in one assembly retains the same value at another assembly (said: "This is not very clear, look at the following example may be clearer)."

Compile-time and Run-time-constant assignment methods have an impact on run-time compatibility.

Suppose you have defined both a const and a readonly variable in the assembly infrastructure:

public class UserfulValues {
public static readonly int StartValue = 5;
public const int EndValue = 10;
}