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)

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

屬性	說明
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 部分要求：

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 的代碼就到這裏爲止。