前言C# 從 7 版本開始一直到如今的 9 版本，加入了非常多的特性，其中不乏改善性能、增加程序健壯性和代碼簡潔性、可讀性的改進，這里我整理一些使用新版 C# 的時候個人推薦的寫法，可能不適用于所有的人，但是還是希望對你們有所幫助。 注意：本指南適用于 .NET 5 或以上版本。 使用 ref struct 做到 0 GCC# 7 開始引入了一種叫做
使用 in 關鍵字傳遞不可修改的引用當參數(shù)以 在使用大的 使用 stackalloc 在棧上分配連續(xù)內存對于部分性能敏感卻需要使用少量的連續(xù)內存的情況，不必使用數(shù)組，而可以通過
使用 Span
|
| 代碼 | 5 | 6 | 7 | 8 | 9 | 總數(shù) | 平均 |
|---|---|---|---|---|---|---|---|
| 代碼 1 | 1 | 3 | 4 | 4 | 2 | 14 | 2.8 |
| 代碼 2 | 2 | 3 | 2 | 2 | 3 | 12 | 2.4 |
可以看到使用模式匹配時，編譯器選擇了更優(yōu)的比較方案，你在編寫的時候無需考慮如何組織判斷語句，心智負擔降低，并且代碼 2 可讀性和簡潔程度顯然比代碼 1 更好，有哪些條件分支一目了然。
甚至遇到類似以下的情況時：
int Match(int v)
{
return v switch
{
1 => 5,
2 => 6,
3 => 7,
4 => 8,
_ => 9
};
}
編譯器會直接將代碼從條件判斷語句編譯成 switch 語句：
int Match(int v)
{
switch (v)
{
case 1:
return 5;
case 2:
return 6;
case 3:
return 7;
case 4:
return 8;
default:
return 9;
}
}
如此一來所有的判斷都不需要比較（因為 switch 可根據(jù) HashCode 直接跳轉）。
編譯器非常智能地為你選擇了最佳的方案。
那魯棒性從何談起呢?假設你漏掉了一個分支：
int v = 5;
var x = v switch
{
> 3 => 1,
< 3 => 2
};
此時編譯的話，編譯器就會警告你漏掉了 v 可能為 3 的情況，幫助減少程序出錯的可能性。
最后一點，可讀性。
假設你現(xiàn)在有這樣的東西：
abstract class Entry { }
class UserEntry : Entry
{
public int UserId { get; set; }
}
class DataEntry : Entry
{
public int DataId { get; set; }
}
class EventEntry : Entry
{
public int EventId { get; set; }
// 如果 CanRead 為 false 則查詢的時候直接返回空字符串
public bool CanRead { get; set; }
}
現(xiàn)在有接收類型為 Entry 的參數(shù)的一個函數(shù)，該函數(shù)根據(jù)不同類型的 Entry 去數(shù)據(jù)庫查詢對應的 Content，那么只需要寫：
string QueryMessage(Entry entry)
{
return entry switch
{
UserEntry u => dbContext1.User.FirstOrDefault(i => i.Id == u.UserId).Content,
DataEntry d => dbContext1.Data.FirstOrDefault(i => i.Id == d.DataId).Content,
EventEntry { EventId: var eventId, CanRead: true } => dbContext1.Event.FirstOrDefault(i => i.Id == eventId).Content,
EventEntry { CanRead: false } => "",
_ => throw new InvalidArgumentException("無效的參數(shù)")
};
}
更進一步，假如 Entry.Id 分布在了數(shù)據(jù)庫 1 和 2 中，如果在數(shù)據(jù)庫 1 當中找不到則需要去數(shù)據(jù)庫 2 進行查詢，如果 2 也找不到才返回空字符串，由于 C# 的模式匹配支持遞歸模式，因此只需要這樣寫：
string QueryMessage(Entry entry)
{
return entry switch
{
UserEntry u => dbContext1.User.FirstOrDefault(i => i.Id == u.UserId) switch
{
null => dbContext2.User.FirstOrDefault(i => i.Id == u.UserId)?.Content ?? "",
var found => found.Content
},
DataEntry d => dbContext1.Data.FirstOrDefault(i => i.Id == d.DataId) switch
{
null => dbContext2.Data.FirstOrDefault(i => i.Id == u.DataId)?.Content ?? "",
var found => found.Content
},
EventEntry { EventId: var eventId, CanRead: true } => dbContext1.Event.FirstOrDefault(i => i.Id == eventId) switch
{
null => dbContext2.Event.FirstOrDefault(i => i.Id == eventId)?.Content ?? "",
var found => found.Content
},
EventEntry { CanRead: false } => "",
_ => throw new InvalidArgumentException("無效的參數(shù)")
};
}
就全部搞定了，代碼非常簡潔，而且數(shù)據(jù)的流向一眼就能看清楚，就算是沒有接觸過這部分代碼的人看一下模式匹配的過程，也能一眼就立刻掌握各分支的情況，而不需要在一堆的 if-else 當中梳理這段代碼到底干了什么。
record 作為 C# 9 的新工具，配合 init 僅可初始化屬性，為我們帶來了高效的數(shù)據(jù)交互能力和不可變性。
消除可變性意味著無副作用，一個無副作用的函數(shù)無需擔心數(shù)據(jù)同步互斥問題，因此在無鎖的并行編程中非常有用。
record Point(int X, int Y);
簡單的一句話等價于我們寫了如下代碼，幫我們解決了 ToString() 格式化輸出、基于值的 GetHashCode() 和相等判斷等等各種問題：
internal class Point : IEquatable<Point>
{
private readonly int x;
private readonly int y;
protected virtual Type EqualityContract => typeof(Point);
public int X
{
get => x;
set => x = value;
}
public int Y
{
get => y;
set => y = value;
}
public Point(int X, int Y)
{
x = X;
y = Y;
}
public override string ToString()
{
StringBuilder stringBuilder = new StringBuilder();
stringBuilder.Append("Point");
stringBuilder.Append(" { ");
if (PrintMembers(stringBuilder))
{
stringBuilder.Append(" ");
}
stringBuilder.Append("}");
return stringBuilder.ToString();
}
protected virtual bool PrintMembers(StringBuilder builder)
{
builder.Append("X");
builder.Append(" = ");
builder.Append(X.ToString());
builder.Append(", ");
builder.Append("Y");
builder.Append(" = ");
builder.Append(Y.ToString());
return true;
}
public static bool operator !=(Point r1, Point r2)
{
return !(r1 == r2);
}
public static bool operator ==(Point r1, Point r2)
{
if ((object)r1 != r2)
{
if ((object)r1 != null)
{
return r1.Equals(r2);
}
return false;
}
return true;
}
public override int GetHashCode()
{
return (EqualityComparer<Type>.Default.GetHashCode(EqualityContract) * -1521134295 + EqualityComparer<int>.Default.GetHashCode(x)) * -1521134295 + EqualityComparer<int>.Default.GetHashCode(y);
}
public override bool Equals(object obj)
{
return Equals(obj as Point);
}
public virtual bool Equals(Point other)
{
if ((object)other != null && EqualityContract == other.EqualityContract && EqualityComparer<int>.Default.Equals(x, other.x))
{
return EqualityComparer<int>.Default.Equals(y, other.y);
}
return false;
}
public virtual Point Clone()
{
return new Point(this);
}
protected Point(Point original)
{
x = original.x;
y = original.y;
}
public void Deconstruct(out int X, out int Y)
{
X = this.X;
Y = this.Y;
}
}
注意到 x 與 y 都是 readonly 的，因此一旦實例創(chuàng)建了就不可變，如果想要變更可以通過 with 創(chuàng)建一份副本，于是這種方式徹底消除了任何的副作用。
var p1 = new Point(1, 2);
var p2 = p1 with { Y = 3 }; // (1, 3)
當然，你也可以自己使用 init 屬性表示這個屬性只能在初始化時被賦值：
class Point
{
public int X { get; init; }
public int Y { get; init; }
}
這樣一來，一旦 Point 被創(chuàng)建，則 X 和 Y 的值就不會被修改了，可以放心地在并行編程模型中使用，而不需要加鎖。
var p1 = new Point { X = 1, Y = 2 };
p1.Y = 3; // error
var p2 = p1 with { Y = 3 }; //ok
上面說到了不可變性的重要性，當然，struct 也可以是只讀的：
readonly struct Foo
{
public int X { get; set; } // error
}
上面的代碼會報錯，因為違反了 X 只讀的約束。
如果改成：
readonly struct Foo
{
public int X { get; }
}
或
readonly struct Foo
{
public int X { get; init; }
}
則不會存在問題。
Span<T> 本身是一個 readonly ref struct，通過這樣做保證了 Span<T> 里的東西不會被意外的修改，確保不變性和安全。
在使用 Expression<Func<>> 作為參數(shù)的 API 時，使用 lambda 表達式是非常正確的，因為編譯器會把我們寫的 lambda 表達式編譯成 Expression Tree，而非直觀上的函數(shù)委托。
而在單純只是 Func<>、Action<> 時，使用 lambda 表達式恐怕不是一個好的決定，因為這樣做必定會引入一個新的閉包，造成額外的開銷和 GC 壓力。從 C# 8 開始，我們可以使用局部函數(shù)很好的替換掉 lambda：
int SomeMethod(Func<int, int> fun)
{
if (fun(3) > 3) return 3;
else return fun(5);
}
void Caller()
{
int Foo(int v) => v + 1;
var result = SomeMethod(Foo);
Console.WriteLine(result);
}
以上代碼便不會導致一個多余的閉包開銷。
我們在遇到 Task<T> 時，大多數(shù)情況下只是需要簡單的對其進行 await 而已，而并不需要將其保存下來以后再 await，那么 Task<T> 提供的很多的功能則并沒有被使用，反而在高并發(fā)下，由于反復分配 Task 導致 GC 壓力增加。
這種情況下，我們可以使用 ValueTask<T> 代替 Task<T>：
ValueTask<int> Foo()
{
return ValueTask.FromResult(1);
}
async ValueTask Caller()
{
await Foo();
}
由于 ValueTask<T> 是值類型結構，因此該對象本身不會在堆上分配內存，于是可以減輕 GC 壓力。
如果我們想要把一個類型中的數(shù)據(jù)提取出來，我們可以選擇返回一個元組，其中包含我們需要的數(shù)據(jù)：
class Foo
{
private int x;
private int y;
public Foo(int x, int y)
{
this.x = x;
this.y = y;
}
public (int, int) Deconstruct()
{
return (x, y);
}
}
class Program
{
static void Bar(Foo v)
{
var (x, y) = v.Deconstruct();
Console.WriteLine($"X = {x}, Y = {y}");
}
}
上述代碼會導致一個 ValueTuple<int, int> 的開銷，如果我們將代碼改成實現(xiàn)解構方法：
class Foo
{
private int x;
private int y;
public Foo(int x, int y)
{
this.x = x;
this.y = y;
}
public void Deconstruct(out int x, out int y)
{
x = this.x;
y = this.y;
}
}
class Program
{
static void Bar(Foo v)
{
var (x, y) = v;
Console.WriteLine($"X = {x}, Y = {y}");
}
}
則不僅省掉了 Deconstruct() 的調用，同時還沒有任何的額外開銷。你可以看到實現(xiàn) Deconstruct 函數(shù)并不需要讓你的類型實現(xiàn)任何的接口，從根本上杜絕了裝箱的可能性，這是一種 0 開銷抽象。另外，解構函數(shù)還能用于做模式匹配，你可以像使用元組一樣地使用解構函數(shù)（下面代碼的意思是，當 x 為 3 時取 y，否則取 x + y）：
void Bar(Foo v)
{
var result = v switch
{
Foo (3, var y) => y,
Foo (var x, var y) => x + y,
_ => 0
};
Console.WriteLine(result);
}
在項目屬性文件 csproj 中啟用 null 安全后即可對整個項目的代碼啟用 null 安全靜態(tài)分析：
<PropertyGroup>
<Nullable>enable</Nullable>
</PropertyGroup>
這樣便可以在編譯的時候檢查一切潛在的導致 NRE 的問題。例如如下代碼：
var list = new List<Entry>();
var value = list.FirstOrDefault(i => i.Id == 3).Value;
Console.WriteLine(value);
list.FirstOrDefault() 可能返回 null，因此啟用 null 安全之后編譯器將會給出警告，這有助于避免不必要的 NRE 異常發(fā)生。
另外，啟用 null 安全之后，對于可空引用類型，也可以通過在類型后加一個 ? 來表示可為 null：
string? x = null;
在合適的時候使用 C# 的新特性，不但可以提升開發(fā)效率，同時還能兼顧代碼質量和運行效率的提升。
但是切忌濫用。新特性的引入對于我們寫高質量的代碼無疑有很大的幫助，但是如果不分時宜地使用，可能會帶來反效果。
希望本文能對各位開發(fā)者使用新版 C# 時帶來一定的幫助，感謝閱讀。
|
|
