C# 好程式碼學習筆記(1)：文件操作、讀取文件、Debug/Trace 類、Conditional條件編譯、CLS
目錄：
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 命名空間中，指定如何實現方法的詳細資訊。
內聯函數使用方法可參考 //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規範可參考：
//docs.microsoft.com/en-us/dotnet/standard/language-independence
//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 的程式碼就到這裡為止。
