目錄：
1，檔案操作
2，Debug、Trace類
3，條件編譯
4，MethodImpl 特性
5，CLSComplianAttribute
6，必要時自定義型別別名
最近在閱讀 .NET Core Runtime 的原始碼，參考大佬的程式碼，學習編寫技巧和提高程式碼水平。學習過程中將學習心得和值得應用到專案中的程式碼片段記錄下來，供日後查閱。
1，檔案操作
這段程式碼在 System.Private.CoreLib 下，對 System.IO.File 中的程式碼進行精簡，供 CLR 使用。
當使用檔案時，要提前判斷檔案路徑是否存在，日常專案中要使用到檔案的地方應該不少，可以統一一個判斷檔案是否存在的方法：
public static bool Exists(string? path)
{
try
{
// 可以將 string? 改成 string
if (path == null)
return false;
if (path.Length == 0)
return false;
path = Path.GetFullPath(path);
// After normalizing, check whether path ends in directory separator.
// Otherwise, FillAttributeInfo removes it and we may return a false positive.
// GetFullPath should never return null
Debug.Assert(path != null, "File.Exists: GetFullPath returned null");
if (path.Length > 0 && PathInternal.IsDirectorySeparator(path[^1]))
{
return false;
}
return InternalExists(path);
}
catch (ArgumentException) { }
catch (NotSupportedException) { } // Security can throw this on ":"
catch (SecurityException) { }
catch (IOException) { }
catch (UnauthorizedAccessException) { }
return false;
}
建議專案中對路徑進行最終處理的時候，都轉換為絕對路徑：
Path.GetFullPath(path)
當然，相對路徑會被 .NET 正確識別，但是對於運維排查問題和各方面考慮，絕對路徑容易定位具體位置和排錯。
在編寫程式碼時，使用相對路徑，不要寫死，提高靈活性；在執行階段將其轉為絕對路徑；
上面的 NotSupportedException 等異常是操作檔案中可能出現的各種異常情況，對於跨平臺應用來說，這些異常可能都是很常見的，提前將其異常型別識別處理，可以優化檔案處理邏輯以及便於篩查處理錯誤。
2，讀取檔案
這段程式碼在 System.Private.CoreLib 中。
有個讀取檔案轉換為 byte[] 的方法如下：
public static byte[] ReadAllBytes(string path)
{
// bufferSize == 1 used to avoid unnecessary buffer in FileStream
using (FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize: 1))
{
long fileLength = fs.Length;
if (fileLength > int.MaxValue)
throw new IOException(SR.IO_FileTooLong2GB);
int index = 0;
int count = (int)fileLength;
byte[] bytes = new byte[count];
while (count > 0)
{
int n = fs.Read(bytes, index, count);
if (n == 0)
throw Error.GetEndOfFile();
index += n;
count -= n;
}
return bytes;
}
}
可以看到 FileStream 的使用，如果單純是讀取檔案內容，可以參考裡面的程式碼：
FileStream fs = new FileStream(path,
FileMode.Open,
FileAccess.Read,
FileShare.Read,
bufferSize: 1)
上面的程式碼同樣也存在 File.ReadAllBytes 與之對應， File.ReadAllBytes 內部是使用 InternalReadAllBytes 來處理文件讀取：
private static byte[] InternalReadAllBytes(String path, bool checkHost)
{
byte[] bytes;
// 此 FileStream 的建構函式不是 public ，開發者不能使用
using(FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read,
FileStream.DefaultBufferSize, FileOptions.None, Path.GetFileName(path), false, false, checkHost)) {
// Do a blocking read
int index = 0;
long fileLength = fs.Length;
if (fileLength > Int32.MaxValue)
throw new IOException(Environment.GetResourceString("IO.IO_FileTooLong2GB"));
int count = (int) fileLength;
bytes = new byte[count];
while(count > 0) {
int n = fs.Read(bytes, index, count);
if (n == 0)
__Error.EndOfFile();
index += n;
count -= n;
}
}
return bytes;
}
這段說明我們可以放心使用 File 靜態類中的函式，因為裡面已經處理好一些邏輯了，並且自動釋放檔案。
如果我們手動 new FileStream ，則要判斷一些情況，以免使用時報錯，最好參考一下上面的程式碼。
.NET 檔案流快取大小預設是 4096 位元組：
internal const int DefaultBufferSize = 4096;
這段程式碼在 File 類中定義，開發者不能設定快取塊的大小，大多數情況下，4k 是最優的塊大小。
ReadAllBytes 的檔案大小上限是 2 GB。
3，Debug 、Trace類
這兩個類的名稱空間為 System.Diagnostics，Debug 、Trace 提供一組有助於除錯程式碼的方法和屬性。
Debug 中的所有函式都不會在 Release 中有效，並且所有輸出流不會在控制檯顯示，必須註冊偵聽器才能讀取這些流。
Debug 可以列印除錯資訊並使用斷言檢查邏輯，使程式碼更可靠，而不會影響發運產品的效能和程式碼大小。
這類輸出方法有 Write 、WriteLine 、 WriteIf 和 WriteLineIf 等，這裡輸出不會直接列印到控制檯。
如需將除錯資訊列印到控制檯，可以註冊偵聽器：
ConsoleTraceListener console = new ConsoleTraceListener();
Trace.Listeners.Add(console);
注意， .NET Core 2.x 以上 Debug 沒有 Listeners ，因為 Debug 使用的是 Trace 的偵聽器。
我們可以給 Trace.Listeners 註冊偵聽器，這樣相對於 Debug 等效設定偵聽器。
Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
Debug.WriteLine("aa");
.NET Core 中的監聽器都繼承了 TraceListener，如 TextWriterTraceListener、ConsoleTraceListener、DefaultTraceListener。
如果需要輸出到檔案中，可以自行繼承 TextWriterTraceListener ，編寫檔案流輸出，也可以使用 DelimitedListTraceListener。
示例：
TraceListener listener = new DelimitedListTraceListener(@"C:\debugfile.txt");
// Add listener.
Debug.Listeners.Add(listener);
// Write and flush.
Debug.WriteLine("Welcome");
處理上述方法輸出控制檯，也可以使用
ConsoleTraceListener console=...
...Listeners.Add(console);
// 等效於
var console = new TextWriterTraceListener(Console.Out)
為了格式化輸出流，可以使用 一下屬性控制排版：
| 屬性 | 說明 |
|---|---|
| AutoFlush | 獲取或設定一個值，通過該值指示每次寫入後是否應在 Flush() 上呼叫 Listeners。 |
| IndentLevel | 獲取或設定縮排級別。 |
| IndentSize | 獲取或設定縮排的空格數。 |
// 1.
Debug.WriteLine("One");
// Indent and then unindent after writing.
Debug.Indent();
Debug.WriteLine("Two");
Debug.WriteLine("Three");
Debug.Unindent();
// End.
Debug.WriteLine("Four");
// Sleep.
System.Threading.Thread.Sleep(10000);
One
Two
Three
Four
.Assert() 方法對我們除錯程式很有幫助，Assert 向開發人員傳送一個強訊息。在 IDE 中，斷言會中斷程式的正常操作，但不會終止應用程式。
.Assert() 的最直觀效果是輸出程式的斷言位置。
Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
int value = -1;
// A.
// If value is ever -1, then a dialog will be shown.
Debug.Assert(value != -1, "Value must never be -1.");
// B.
// If you want to only write a line, use WriteLineIf.
Debug.WriteLineIf(value == -1, "Value is -1.");
---- DEBUG ASSERTION FAILED ----
---- Assert Short Message ----
Value must never be -1.
---- Assert Long Message ----
at Program.Main(String[] args) in ...Program.cs:line 12
Value is -1.
Debug.Prinf() 也可以輸出資訊，它跟 C 語言的 printf 函式行為一致，將後跟行結束符的訊息寫入，預設行終止符為回車符後跟一個換行符。
在 IDE 中執行程式時，使用 Debug.Assert()、Trace.Assert() 等方法 ，條件為 false 時，IDE 會斷言，這相當於條件斷點。
在非 IDE 環境下，程式會輸出一些資訊，但不會有中斷效果。
Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
Trace.Assert(false);
Process terminated. Assertion Failed
at Program.Main(String[] args) in C:\ConsoleApp4\Program.cs:line 44
個人認為，可以將 Debug、Trace 引入專案中，與日誌元件配合使用。Debug、Trace 用於記錄程式執行的診斷資訊，便於日後排查程式問題；日誌用於記錄業務過程，資料資訊等。
.Assert() 的原理， 在 true 時什麼都不做；在 false 時呼叫 Fail 函式；如果你不註冊偵聽器的話，預設也沒事可做。
.Assert() 唯一可做的事情是等條件為 false 時，執行 Fail 方法，當然我們也可以手動直接呼叫 Fail 方法，Fail 的程式碼如下：
public static void Fail(string message) {
if (UseGlobalLock) {
lock (critSec) {
foreach (TraceListener listener in Listeners) {
listener.Fail(message);
if (AutoFlush) listener.Flush();
}
}
}
else {
foreach (TraceListener listener in Listeners) {
if (!listener.IsThreadSafe) {
lock (listener) {
listener.Fail(message);
if (AutoFlush) listener.Flush();
}
}
else {
listener.Fail(message);
if (AutoFlush) listener.Flush();
}
}
}
}
4，條件編譯
#if 條件編譯會隱藏非條件(#else if)程式碼，我們開發中很可能會忽略掉這部分程式碼，當我們切換條件常量到這部分程式碼時，很可能因為各種原因導致報錯。
如果使用特性進行條件編譯標記，在開發過程中就可以留意到這部分程式碼。
[Conditional("DEBUG")]
例如，當使用修改所有引用-修改一個類成員變數或者靜態變數名稱時，#if 非條件中的程式碼不會被修改，因為這部分程式碼“無效”，而且使用 [Conditional("DEBUG")] 的程式碼則跟條件無關，會被同步修改。
Conditional 特性標記的方法等，在開發過程中保持有效，當在編譯時可能被排除。
程式碼片段只能使用 #if 了，如果是單個方法，則可以使用 Conditional 。
5，MethodImpl 特性
此特性在 System.Runtime.CompilerServices 名稱空間中，指定如何實現方法的詳細資訊。
行內函數使用方法可參考 https://www.whuanle.cn/archives/995
MethodImpl 特性可以影響 JIT 編譯器的行為。
無法使用 MemberInfo.GetCustomAttributes 來獲取此特性的資訊，即不能通過獲取特性的方法獲取跟 MethodImpl 有關的資訊(反射)，只能呼叫 MethodInfo.GetMethodImplementationFlags() 或 ConstructorInfo.GetMethodImplementationFlags () 來檢索。
MethodImpl 可以在方法以及建構函式上使用。
MethodImplOptions 用於設定編譯行為，列舉值可組合使用，其列舉說明如下：
| 列舉 | 列舉值 | 說明 |
|---|---|---|
| AggressiveInlining | 256 | 如可能應將該方法進行內聯。 |
| AggressiveOptimization | 512 | 此方法包含一個熱路徑，且應進行優化。 |
| ForwardRef | 16 | 已宣告該方法，但在其他位置提供實現。 |
| InternalCall | 4096 | 該呼叫為內部呼叫，也就是說它呼叫了在公共語言執行時中實現的方法。 |
| NoInlining | 8 | 該方法不能為內聯方法。 內聯是一種優化方式，通過該方式將方法呼叫替換為方法體。 |
| NoOptimization | 64 | 除錯可能的程式碼生成問題時，該方法不由實時 (JIT) 編譯器或本機程式碼生成優化（請參閱 Ngen.exe）。 |
| PreserveSig | 128 | 完全按照宣告匯出方法簽名。 |
| Synchronized | 32 | 該方法一次性只能在一個執行緒上執行。 靜態方法在型別上鎖定，而例項方法在例項上鎖定。 只有一個執行緒可在任意例項函式中執行，且只有一個執行緒可在任意類的靜態函式中執行。 |
| Unmanaged | 4 | 此方法在非託管的程式碼中實現。 |
Synchronized 修飾的方法可以避免多執行緒中的一些問題，但是不建議對公共型別使用鎖定例項或型別上的鎖定，因為 Synchronized 可以對非自己的程式碼的公共型別和例項進行鎖定。 這可能會導致死鎖或其他同步問題。
意思是說，如果共享的成員已經設定了鎖，那麼不應該再在 Synchronized 方法中使用，這樣雙重鎖定容易導致死鎖以及其他問題。
5，CLSCompliantAttribute
指示程式元素是否符合公共語言規範 (CLS)。
CLS規範可參考：
https://docs.microsoft.com/en-us/dotnet/standard/language-independence
https://www.ecma-international.org/publications/standards/Ecma-335.htm
全域性開啟方法：
程式目錄下新增一個 AssemblyAttribytes.cs 檔案，或者開啟 obj 目錄，找到 AssemblyAttributes.cs 結尾的檔案，如 .NETCoreApp,Version=v3.1.AssemblyAttributes.cs，新增：
using System; // 這行已經有的話不要加
[assembly: CLSCompliant(true)]
之後就可以在程式碼中使用 [CLSCompliant(true)] 特性。
區域性開啟：
也可以放在類等成員上使用：
[assembly: CLSCompliant(true)]
您可以將特性應用於 CLSCompliantAttribute 下列程式元素：程式集、模組、類、結構、列舉、建構函式、方法、屬性、欄位、事件、介面、委託、引數和返回值。 但是，CLS 遵從性的概念僅適用於程式集、模組、型別和型別的成員。
程式編譯時預設不會檢查程式碼是否符合 CLS 要求，但是如果你的可以是公開的(程式碼共享、Nuget 釋出等)，則建議使用使用 [assembly: CLSCompliant(true)] ，指明你的庫符合 CLS 要求。
在團隊開發中以及內部共享程式碼時，高質量的程式碼尤為重要，所以有必要使用工具檢查程式碼，如 roslyn 靜態分析、sonar 掃描等，也可以使用上面的特性，自動使用 CLS 檢查。
CLS 部分要求：
-
無符號型別不應成為該類的公共介面的一部分(私有成員可以使用)，例如 UInt32 這些屬於 C# 的型別，但不是 CLS “標準” 中的。
-
指標等不安全型別不能與公共成員一起使用，就是公有方法中都不應該使用 unsafe 程式碼。(私有成員可以使用)。
-
類名和成員名不應重名。雖然 C# 中區分大小寫，但是 CLS 不建議同名非過載函式，例如 MYTEST 跟 Mytest。
-
只能過載屬性和方法，不應過載運算子。過載運算子容易導致呼叫者不知情時出現程式錯誤，並且過載運算子要排查問題十分困難。
我們可以編譯以下程式碼，嘗試使用 CLSCompliant ：
[assembly: CLSCompliant(true)]
[CLSCompliant(true)]
public class Test
{
public void MyMethod()
{
}
public void MYMETHOD()
{
}
}
IDE 中會警告：warning CS3005: 僅大小寫不同的識別符號“Test.MYMETHOD()”不符合 CLS，編譯時也會提示 Warn。當然，不會阻止編譯，也不會影響程式執行。
總之，如果要標記一個程式集 CLS 規範，可以使用 [assembly: CLSCompliant(true)] 特性。
[CLSCompliant(true)] 特性指示這個元素符合 CLS 規範，這時編譯器或者 IDE 會檢查你的程式碼，檢查是否真的符合規範。
如果偏偏要寫不符合規範的程式碼，則可以使用 [CLSCompliant(false)]。
6，必要時自定義型別別名
C# 也可以定義型別別名。
using intbyte = System.Int32;
using intkb = System.Int32;
using intmb = System.Int32;
using intgb = System.Int32;
using inttb = System.Int32;
byte[] fileByte = File.ReadAllBytes("./666.txt");
intmb size = fileByte.Length / 1024;
一些情況下，使用別名可以提高程式碼可讀性。真實專案不要使用以上程式碼，我只是寫個示例，這並不是合適的應用場景。
今天學習 Runtime 的程式碼就到這裡為止。