第二章：Python编码规范与静态检查

说实话，我见过太多交易系统因为代码风格混乱而翻车了。有一次，我们团队一个新人写的策略代码，变量名全是a、b、c，缩进混用空格和Tab。结果上线第一天，就因为一个缩进错误导致订单重复提交，亏了十几万。嗯，从那以后，我强制团队所有代码必须过静态检查。

这一章，我们就聊聊Python编码规范那些事儿。说白了，就是让你写的代码像印刷体一样整齐，别人看着舒服，机器跑着也稳。

2.1 PEP8规范精讲

PEP8是Python官方推荐的编码风格指南。我个人的习惯是，把它当成代码界的交通规则——不遵守不会死，但遵守了大家都安全。

2.1.1 缩进与空格

Python用缩进来表示代码块，这大家都知道。但具体怎么缩？我建议统一用4个空格，别用Tab。为什么？因为不同编辑器对Tab的解析不一样，你看着对齐了，换台机器就乱套了。

# 正确写法
def calculate_sma(prices, window):
    if len(prices) < window:
        return None
    return sum(prices[-window:]) / window

# 错误写法（混用Tab和空格）
def calculate_sma(prices, window):
	if len(prices) < window:  # 这里用了Tab
        return None  # 这里用了空格
    return sum(prices[-window:]) / window

2.1.2 行长度与空行

PEP8建议每行不超过79个字符。你可能会觉得这太保守了，现在屏幕都那么宽。但想想看，交易系统的日志文件、代码审查的diff视图，行太长真的很难看。

我一般这样处理长行：

# 长表达式用反斜杠或括号换行
total_value = (position_size * current_price 
               + cash_balance 
               - transaction_fees)

# 函数参数太多时，每个参数单独一行
def place_order(
    symbol,
    side,
    quantity,
    order_type='limit',
    price=None,
    time_in_force='day'
):
    pass

空行方面，我习惯在函数定义之间留两个空行，类方法之间留一个空行。这样代码看起来有呼吸感，不会挤成一团。

2.1.3 命名规范

命名这件事，我吃过不少亏。早期写策略时，变量名随便起，结果三个月后自己都看不懂了。现在我的命名规则很简单：

类型	规范	示例
变量名	小写+下划线	moving_average, order_id
常量	大写+下划线	MAX_POSITION, RISK_FREE_RATE
函数名	小写+下划线	calculate_sharpe(), get_market_data()
类名	驼峰式	OrderManager, RiskController
私有属性	下划线开头	_internal_state, __private_method

2.2 Flake8与Pylint配置实战

光靠人眼检查代码规范，效率太低。我们需要自动化工具。Flake8和Pylint就是干这个的。

2.2.1 Flake8：轻量级检查器

Flake8速度快，适合在开发阶段频繁使用。我一般在每次git commit之前跑一遍。

# 安装
pip install flake8

# 基本使用
flake8 my_trading_system.py

# 输出示例
my_trading_system.py:15:1: E302 expected 2 blank lines, found 1
my_trading_system.py:42:80: E501 line too long (85 > 79 characters)

Flake8的配置我放在项目根目录的.flake8文件里：

[flake8]
max-line-length = 100
ignore = E203, W503
exclude = .git,__pycache__,venv

为什么忽略E203和W503？E203是冒号前的空格问题，W503是二元运算符换行位置。这两个规则在Black格式化后会有冲突，我干脆关掉了。

2.2.2 Pylint：深度代码分析

Pylint比Flake8严格得多，它不光检查格式，还会分析代码逻辑。比如未使用的变量、过于复杂的函数、重复代码等。

# 安装
pip install pylint

# 使用
pylint my_trading_system.py

# 输出示例
C: 15, 0: Unused variable 'temp_data' (unused-variable)
R: 42, 0: Too many local variables (18/15) (too-many-locals)
W: 78, 4: Redefining name 'price' from outer scope (redefined-outer-name)

[MASTER]
load-plugins = pylint.extensions.docparams

[MESSAGES CONTROL]
disable = C0114, C0115, C0116, R0903, R0913

[DESIGN]
max-args = 8
max-locals = 20
max-returns = 6

我禁用了C0114/C0115/C0116（缺少文档字符串），因为交易策略代码中，很多函数一眼就能看懂用途，没必要每行都写注释。R0903（类方法太少）也关了，有些数据类就是纯容器。

2.3 代码格式化工具Black的使用

说实话，手动调整代码格式是最浪费时间的事情。Black的出现拯救了我。它是个「不妥协的代码格式化工具」——你不需要配置，它直接帮你格式化好。

2.3.1 为什么选择Black

我选择Black的原因很简单：它消除了团队中关于代码风格的争论。以前我们团队开会讨论「函数参数要不要换行」「字典里冒号后面要不要空格」，吵了半小时没结果。用了Black之后，这些争论全没了。

# 安装
pip install black

# 格式化单个文件
black my_trading_system.py

# 格式化整个项目
black .

2.3.2 Black的格式化效果

看看Black是怎么工作的：

# 格式化前
def calculate_pnl(entry_price,exit_price,position_size):
    pnl=(exit_price-entry_price)*position_size
    return pnl

# 格式化后
def calculate_pnl(entry_price, exit_price, position_size):
    pnl = (exit_price - entry_price) * position_size
    return pnl

Black会自动处理空格、换行、引号统一。它甚至会把复杂的表达式拆成多行：

# 格式化前
result = some_function(argument1, argument2, argument3, argument4, argument5, argument6)

# 格式化后
result = some_function(
    argument1,
    argument2,
    argument3,
    argument4,
    argument5,
    argument6,
)

2.3.3 集成到工作流

我建议把Black集成到pre-commit钩子里。这样每次提交代码前，Black会自动格式化，保证仓库里的代码永远是干净的。

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/psf/black
    rev: 23.1.0
    hooks:
      - id: black
        language_version: python3.9

知识体系总览

下面这张图，是我对本章知识体系的总结。你可以看到，编码规范、静态检查、格式化工具三者之间的关系：

你看，这三个工具各司其职：PEP8告诉你「应该怎么写」，Flake8检查「你写对了没有」，Black直接帮你「改好」。三者配合，代码质量就有了保障。

好了，这一章的内容就到这里。记住，代码规范不是束缚，而是保护。它保护你不写出低级bug，保护团队协作顺畅，保护交易系统稳定运行。下一章，我们会聊聊单元测试——怎么用代码来测试代码。

---