Files
xxxigcc-proxy/llmdoc/reference/coding-conventions.md
Wang Defa 9afe4a8649
All checks were successful
Build and Release / build-and-test (arm64, alpine) (push) Successful in -13s
Build and Release / build-and-test (amd64, alpine) (push) Successful in -6s
Build and Release / build-and-test (arm64, ubuntu) (push) Successful in -7s
Build and Release / build-and-test (amd64, ubuntu) (push) Successful in 7s
Build and Release / release (push) Successful in 21s
简化 Debian 发布流程并添加项目文档系统
- 将 Debian 包仓库从 bookworm/trixie 双发行版改为通用 stable 仓库
- 新增完整的 llmdoc 文档系统,包含架构、指南和参考文档
- 更新 README.md 和部署指南以反映新的仓库配置
- 添加 .gitignore 文件
2025-12-25 10:18:07 +08:00

1.7 KiB
Raw Blame History

Shell 脚本编码规范

1. 基本原则

1.1 Shell 类型

  • 优先使用 #!/bin/shPOSIX shell
  • 复杂脚本可使用 #!/bin/bash

1.2 安全性与健壮性

  • 始终使用 set -e 在任何错误发生时立即退出脚本
  • 对关键步骤进行错误检查和参数验证

2. 脚本结构

2.1 参数检查

  • 在脚本开始阶段进行参数数量和类型验证
  • 提供清晰的使用说明和示例
  • 对不合法输入给出明确的错误消息并退出

2.2 变量命名

  • 使用全大写字母表示常量和环境变量(如 PRODUCT_NAME
  • 使用小写字母并用下划线分隔表示局部变量(如 build_dir
  • 避免使用单字母变量名

3. 错误处理

3.1 临时文件管理

  • 使用 mktemp 创建安全的临时目录
  • 使用 trap 确保临时文件/目录在脚本结束时被清理

3.2 错误输出

  • 使用 >&2 将错误信息输出到标准错误流
  • 对于错误情况,使用非零退出码

4. 控制流

4.1 条件语句

  • 使用 [ ] 进行条件测试(兼容性更好)
  • 避免复杂的嵌套条件语句,保持代码清晰

4.2 循环和分支

  • case 语句中总是包含 *) 通配分支
  • 对于复杂的条件选择,使用 case 而非过长的 if-elif

5. 注释与文档

5.1 注释风格

  • 使用 # 进行单行注释
  • 为复杂的命令或逻辑块添加简洁的注释说明
  • 在脚本顶部添加简要的脚本用途说明

6. 执行与权限

6.1 文件权限

  • 明确设置脚本和生成文件的执行权限
  • 对于系统服务文件,使用标准权限模式(如 755644

7. 实践建议

  • 保持脚本简洁,单一职责
  • 避免使用晦涩的命令和技巧
  • 优先考虑可读性和可维护性