Google C# 代码风格指南解析
styleguide 项目地址: https://gitcode.com/gh_mirrors/st/styleguide
前言
作为技术专家,我认为代码风格指南对于团队协作和代码维护至关重要。Google 的 C# 代码风格指南为开发者提供了一套清晰、一致的编码规范,既考虑了 C# 语言特性,又保持了与 Google 其他语言风格的一致性。
命名规范
基本命名规则
-
PascalCase 使用场景:
- 类名、方法名、枚举类型、公共字段、公共属性和命名空间
- 示例:
MyClass
,CalculateValue
,MyNamespace
-
camelCase 使用场景:
- 局部变量和参数
- 示例:
resultValue
,mulNumber
-
带下划线的 camelCase:
- 私有、受保护、内部和受保护内部字段及属性
- 示例:
_results
,_someTable
-
接口命名:
- 必须以
I
开头 - 示例:
IMyInterface
- 必须以
文件命名
- 文件名和目录名使用 PascalCase
- 理想情况下,文件名应与文件中的主类名一致
- 推荐一个核心类对应一个文件
代码组织
修饰符顺序
遵循严格的修饰符顺序:public protected internal private new abstract virtual override sealed static readonly extern unsafe volatile async
using 声明
using
声明应放在文件顶部,命名空间之前- 导入顺序:
System
相关导入始终在最前面- 其余按字母顺序排列
类成员排序
-
分组顺序:
- 嵌套类、枚举、委托和事件
- 静态、常量和只读字段
- 字段和属性
- 构造函数和析构函数
- 方法
-
每组内部顺序:
- 从公开到私有:public → internal → protected internal → protected → private
格式规范
空格与缩进
-
基础规则:
- 使用 2 个空格缩进,禁止使用制表符
- 每行最多 100 个字符
- 每行最多一个语句
-
大括号规则:
- 左大括号不换行
- 右大括号与
else
之间不换行 - 即使可选也要使用大括号
-
运算符空格:
- 一元运算符与其操作数之间不加空格
- 其他运算符两侧各加一个空格
换行与对齐
-
方法参数换行:
- 首选对齐到第一个参数
- 如果空间不足,使用 4 空格缩进
-
容器初始化:
- 使用 2 空格缩进
- 示例:
private int[] _someTable = { 2, 3, 4, }
最佳实践
常量与只读
- 优先使用
const
- 次选
readonly
- 避免使用魔数
集合接口选择
-
输入参数:
- 优先选择限制性最强的接口
- 如
IReadOnlyCollection
,IReadOnlyList
,IEnumerable
-
输出参数:
- 如果转移所有权,使用
IList
- 否则使用限制性最强的接口
- 如果转移所有权,使用
属性风格
-
单行只读属性:
- 推荐使用表达式体属性 (
=>
)
- 推荐使用表达式体属性 (
-
其他情况:
- 使用传统
{ get; set; }
语法
- 使用传统
结构体与类
-
关键区别:
- 结构体是值类型
- 类是引用类型
-
使用建议:
- 大多数情况下使用类
- 仅在类型小、短生命周期或嵌入其他对象时考虑结构体
Lambda 表达式
-
简单逻辑:
- 可以使用单行 Lambda
-
复杂逻辑:
- 超过 2-3 行应考虑命名方法
- 多处复用的 Lambda 应转为命名方法
高级主题
扩展方法
-
使用场景:
- 无法修改原始类源代码时
- 添加核心通用功能时
-
注意事项:
- 避免仅在部分代码中可用的扩展方法
- 谨慎使用,因其可能降低代码清晰度
ref 和 out 参数
-
out
:- 用于纯输出参数
- 应放在参数列表最后
-
ref
:- 谨慎使用
- 仅当需要修改输入时使用
- 不要用于优化结构体传递
LINQ 使用
-
推荐做法:
- 优先使用单行 LINQ 调用
- 混合命令式代码和复杂 LINQ 链会降低可读性
-
语法选择:
- 优先成员扩展方法而非 SQL 风格关键字
- 例如:
myList.Where(x)
优于myList where x
集合类型选择
-
List<T>
:- 大小可变时首选
- 公共变量、属性和返回类型的推荐选择
-
数组:
- 大小固定时使用
- 多维数组时首选
元组与命名类型
-
返回类型:
- 复杂类型优先使用命名类
- 简单临时数据可考虑
Tuple<>
-
类型别名:
- 避免使用
using
别名长元组类型 - 应考虑定义正式类
- 避免使用
代码示例解析
public class MyClass {
public int Foo = 0; // 公共字段 PascalCase
private Results _results; // 私有字段 _camelCase
public int CalculateValue(int mulNumber) {
var resultValue = Foo * mulNumber; // 局部变量 camelCase
if (resultValue < 0) { // 操作符空格
_results.NumNegativeResults++;
}
return resultValue;
}
// 表达式体属性
public int SomeProperty => _someProperty;
// 多行方法参数对齐
void LongMethodName(int firstParameter,
int secondParameter) {}
}
总结
Google 的 C# 代码风格指南提供了一套全面的编码规范,既考虑了代码一致性,又兼顾了可读性和维护性。作为开发者,理解并遵循这些规范可以帮助我们:
- 编写更清晰、更一致的代码
- 提高团队协作效率
- 减少代码审查时的风格争议
- 建立良好的编码习惯
记住,风格指南不是教条,当有充分理由时,可以适当变通,但团队内部应保持一致性。
styleguide 项目地址: https://gitcode.com/gh_mirrors/st/styleguide
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考