C#代码审查：检查什么以及如何给新手提供反馈

C#代码审查：从何入手及检查什么

代码审查不仅仅是形式，更是提升项目质量和团队成长的强大工具。对于C#初学者来说，审查他人代码的过程常常令人恐惧：“万一我漏掉了bug怎么办？”“如何告诉同事他的代码写得不好？”在本文中，我们将探讨在.NET项目中进行代码审查时应关注什么，以及如何提供反馈，让对方能够接受而非感到被冒犯。

我们不会讨论诸如语法错误之类显而易见的问题——这些由编译器来捕捉。我们的目标是学会发现架构、可读性和性能方面的问题，并正确地表述意见。

1. C#中的架构与SOLID原则

在C#代码中首先要检查的是它是否符合SOLID原则。即使在一个小方法中，也能看到对单一职责原则的违反。

检查内容：

• 方法和类的大小。如果方法超过20-30行，很可能它做了太多事情。建议将其拆分为多个私有方法。
• 依赖反转。类不应通过new来创建其依赖关系。应使用依赖注入（DI）。糟糕代码示例：

// 糟糕：类自行创建依赖public class OrderService{    private readonly EmailSender _sender = new EmailSender();

    public void ProcessOrder(Order order)    {        // 逻辑...        _sender.SendEmail(order.CustomerEmail);    }}

正确做法是通过接口和DI：

// 良好：依赖被注入public class OrderService{    private readonly IEmailSender _sender;

    public OrderService(IEmailSender sender)    {        _sender = sender;    }

    public void ProcessOrder(Order order)    {        // 逻辑...        _sender.SendEmail(order.CustomerEmail);    }}

• 里氏替换原则（LSP）。子类不应破坏基类的行为。例如，如果你有一个带有Fly()方法的Bird类，然后创建了Penguin : Bird——这违反了LSP，因为企鹅不会飞。更好的做法是提取一个IFlyable接口。

2. .NET中的错误处理与异常

C#拥有强大的异常处理系统，但新手常常错误地使用它。在代码审查时，请注意以下几点：

• 空的catch块。像catch (Exception) { }这样的代码是一个定时炸弹。错误被吞掉，你永远无法知道问题所在。始终记录异常或将其重新抛出。
• 过于通用的异常。捕获Exception是不良实践。尽量捕获具体类型：SqlException、InvalidOperationException等。
• 使用异常控制流程。不要用try-catch替代if-else。糟糕代码示例：

// 糟糕：将异常作为逻辑的一部分try{    int.Parse(userInput);}catch (FormatException){    Console.WriteLine("格式无效");}

正确做法是使用int.TryParse()：

// 良好：无异常检查if (int.TryParse(userInput, out int result)){    // 处理result}else{    Console.WriteLine("格式无效");}

3. 性能与内存管理

对于C#初学者来说，性能主题常常被忽略。然而，代码审查是指出低效构造的好时机。

典型问题：

• 过多的