17370845950

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

变量命名必须带业务含义，不能用 df、data 这类泛称

很多人一上来就写 df = pd.read_csv(...)，后续十几处都用 df，等要加第二个数据源时变成 df2、df_temp，很快自己都分不清哪个是清洗后的用户行为日志，哪个是合并了维度表的宽表。可维护性崩塌往往从第一个模糊命名开始。

实操建议：

• 用下划线连接的全小写名词短语，如 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。

实操建议：

• 提前整理字段类型清单，写进字典传给 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 而不是具体步骤。多人协作时更没人敢改。

实操建议：

• 每个清洗动作独立成函数，命名体现意图，如 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()) 看似省事，但下次要换指标就得重跑整个流程；想加个置信区间？得拆开再拼。图表应只负责可视化，数据准备由上游函数完成。

实操建议：

• 分析脚本里先生成明确命名的结果表，如 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() 没写注释，半年后谁也想不起为什么需要这个副本。规范不是约束，是给未来的自己留的线索。