变量命名需带业务含义并用下划线全小写,如user_click_log_raw;pd.read_csv()须显式指定dtype和parse_dates;清洗逻辑须封装为单一职责函数;图表代码与分析逻辑必须分离。

变量命名必须带业务含义,不能用 df、data 这类泛称
很多人一上来就写 df = pd.read_csv(...),后续十几处都用 df,等要加第二个数据源时变成 df2、df_temp,很快自己都分不清哪个是清洗后的用户行为日志,哪个是合并了维度表的宽表。可维护性崩塌往往从第一个模糊命名开始。
实操建议:
立即学习“Python免费学习笔记(深入)”;
- 用下划线连接的全小写名词短语,如
user_click_log_raw、product_category_mapping - 后缀体现状态:加
_raw(原始)、_clean(已去重/补缺)、_enriched(已关联维度) - 避免缩写歧义,
usr_df不如user_profile_df明确;agg不如daily_revenue_by_region
pd.read_csv() 必须显式指定 dtype 和 parse_dates
不设 dtype 会导致 Pandas 自动推断列类型出错:手机号变成 float、ID 带前导零被截断、分类字段读成 object 后无法高效 .cat.codes。不设 parse_dates 会让时间列变成字符串,后续 .dt.month 直接报 AttributeError。
实操建议:
立即学习“Python免费学习笔记(深入)”;
- 提前整理字段类型清单,写进字典传给
dtype=,例如:{'user_id': 'string', 'amount': 'float32', 'status': 'category'} - 时间列名直接传列表给
parse_dates=,如['event_time', 'create_date'],别依赖infer_datetime_format=True - 加
low_memory=False避免混合类型警告干扰 CI 流程
所有清洗逻辑必须封装成函数,禁止在主流程里写 5 行以上链式操作
像 df.dropna().fillna(0).astype(int).pipe(lambda x: x[x > 0]) 这种“一行流”看着简洁,实际调试时没法打断点、没法单独测试、出错时堆栈指向 lambda 而不是具体步骤。多人协作时更没人敢改。
实操建议:
立即学习“Python免费学习笔记(深入)”;
- 每个清洗动作独立成函数,命名体现意图,如
drop_invalid_amount_rows(df)、normalize_phone_number(df) - 函数只做一件事,输入输出都是
DataFrame,不修改原对象(inplace=False) - 主流程保持“函数调用序列”,例如:
user_log = user_log_raw.pipe(drop_duplicate_events)\ .pipe(fill_missing_user_ids)\ .pipe(convert_event_time_to_utc)
图表代码和分析逻辑必须分离,禁止在绘图函数里写 groupby 或 agg
把聚合计算塞进 plt.plot(df.groupby('date')['revenue'].sum()) 看似省事,但下次要换指标就得重跑整个流程;想加个置信区间?得拆开再拼。图表应只负责可视化,数据准备由上游函数完成。
实操建议:
立即学习“Python免费学习笔记(深入)”;
- 分析脚本里先生成明确命名的结果表,如
daily_revenue_summary = calc_daily_revenue(user_log_clean) - 绘图函数只接收已聚合好的
DataFrame,参数限定为数据 + 样式,如plot_line_chart(daily_revenue_summary, title="Revenue Trend") - 图表函数内部不做任何
merge、filter、agg,只调plt或seaborn接口
df2 = df1.copy() 没写注释,半年后谁也想不起为什么需要这个副本。规范不是约束,是给未来的自己留的线索。









