C# 好代碼學習筆記(1)：檔案操作、讀取檔案、Debug/Trace 類、Conditional條件編譯、CLS

• 1，檔案操作
• 2，讀取檔案
• 3，Debug 、Trace類
• 4，條件編譯
• 5，MethodImpl 特性
• 5，CLSCompliantAttribute
• 6，必要時自定義型別別名

目錄：

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)

為了格式化輸出流，可以使用 一下屬性控制排版：

        // 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 = https://www.cnblogs.com/whuanle/p/-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 =https://www.cnblogs.com/whuanle/p/= -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 用于設定編譯行為，列舉值可組合使用，其列舉說明如下：

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 部分要求：

1. 無符號型別不應成為該類的公共介面的一部分(私有成員可以使用)，例如 UInt32 這些屬于 C# 的型別，但不是 CLS “標準” 中的，

2. 指標等不安全型別不能與公共成員一起使用，就是公有方法中都不應該使用 unsafe 代碼，(私有成員可以使用)，

3. 類名和成員名不應重名，雖然 C# 中區分大小寫，但是 CLS 不建議同名非多載函式，例如 MYTEST 跟 Mytest，

4. 只能多載屬性和方法，不應多載運算子，多載運算子容易導致呼叫者不知情時出現程式錯誤，并且多載運算子要排查問題十分困難，

我們可以編譯以下代碼，嘗試使用 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 的代碼就到這里為止，

標籤：C#

上一篇：反射+自定義特性保存資料至本地

下一篇：使用mDNS進行局域網服務發現（.NET Core）